同步数据到 MySQL 兼容数据库

本文介绍如何使用 TiCDC 创建一个将增量数据复制到下游 TiDB 数据库,或其他兼容 MySQL 协议数据库的 Changefeed。同时介绍了如何使用 TiCDC 灾难场景的最终一致性复制功能。

创建同步任务,复制增量数据到 MySQL 兼容数据库

使用以下命令来创建同步任务:

cdc cli changefeed create \ --server=http://10.0.10.25:8300 \ --sink-uri="mysql://root:123456@127.0.0.1:3306/" \ --changefeed-id="simple-replication-task"
Create changefeed successfully! ID: simple-replication-task Info: {"sink-uri":"mysql://root:123456@127.0.0.1:3306/","opts":{},"create-time":"2023-11-28T22:04:08.103600025+08:00","start-ts":415241823337054209,"target-ts":0,"admin-job-type":0,"sort-engine":"unified","sort-dir":".","config":{"case-sensitive":false,"filter":{"rules":["*.*"],"ignore-txn-start-ts":null,"ddl-allow-list":null},"mounter":{"worker-num":16},"sink":{"dispatchers":null},"scheduler":{"type":"table-number","polling-time":-1}},"state":"normal","history":null,"error":null}
  • --server:TiCDC 集群中任意一个 TiCDC 服务器的地址。
  • --changefeed-id:同步任务的 ID,格式需要符合正则表达式 ^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$。如果不指定该 ID,TiCDC 会自动生成一个 UUID(version 4 格式)作为 ID。
  • --sink-uri:同步任务下游的地址,详见 Sink URI 配置 mysql/tidb
  • --start-ts:指定 changefeed 的开始 TSO。TiCDC 集群将从这个 TSO 开始拉取数据。默认为当前时间。
  • --target-ts:指定 changefeed 的目标 TSO。TiCDC 集群拉取数据直到这个 TSO 停止。默认为空,即 TiCDC 不会自动停止。
  • --config:指定 changefeed 配置文件,详见:TiCDC Changefeed 配置参数

Sink URI 配置 mysql/tidb

Sink URI 用于指定 TiCDC 目标系统的连接信息,遵循以下格式:

[scheme]://[userinfo@][host]:[port][/path]?[query_parameters]

一个通用的配置样例如下所示:

--sink-uri="mysql://root:123456@127.0.0.1:3306"

URI 中可配置的参数如下:

参数描述
root下游数据库的用户名。
123456下游数据库密码。(可采用 Base64 进行编码)
127.0.0.1下游数据库的 IP。
3306下游数据的连接端口。
worker-count向下游执行 SQL 的并发度(可选,默认值为 16)。
cache-prep-stmts向下游执行 SQL 时是否使用 prepared statement 并且开启客户端的 prepared statement 缓存(可选,默认值为 true)。
max-txn-row向下游执行 SQL 的 batch 大小(可选,默认值为 256)。
ssl-ca连接下游 MySQL 实例所需的 CA 证书文件路径(可选)。
ssl-cert连接下游 MySQL 实例所需的证书文件路径(可选)。
ssl-key连接下游 MySQL 实例所需的证书密钥文件路径(可选)。
time-zone连接下游 MySQL 实例时使用的时区名称,从 v4.0.8 开始生效。(可选。如果不指定该参数,使用 TiCDC 服务进程的时区;如果指定该参数但使用空值,例如:time-zone="",则表示连接 MySQL 时不指定时区,使用下游默认时区)。
transaction-atomicity指定事务的原子性级别(可选,默认值为 none)。当该值为 table 时 TiCDC 保证单表事务的原子性,当该值为 none 时 TiCDC 会拆分单表事务。

若需要对 Sink URI 中的数据库密码使用 Base64 进行编码,可以参考如下命令:

echo -n '123456' | base64 # 假设待编码的密码为 123456

编码后的密码如下:

MTIzNDU2

灾难场景的最终一致性复制

从 v6.1.1 版本开始,容灾场景下的最终一致性复制功能 GA。从 v5.3.0 开始,TiCDC 支持将上游 TiDB 的增量数据备份到下游集群的对象存储或 NFS 文件系统。当上游集群出现了灾难,完全无法使用时,TiCDC 可以将下游集群恢复到最近的一致状态,即提供灾备场景的最终一致性复制能力,确保应用可以快速切换到下游集群,避免数据库长时间不可用,提高业务连续性。

目前,TiCDC 支持将 TiDB 集群的增量数据复制到 TiDB 或兼容 MySQL 的数据库系统(包括 Aurora、MySQL 和 MariaDB)。如果 TiCDC 在上游发生灾难前正常运行,且上游 TiDB 集群没有出现数据复制延迟大幅度增加的情况,灾难发生后,下游集群可以在 5 分钟之内恢复集群,并且最多丢失出现问题前 10 秒钟的数据,即 RTO <= 5 min,P95 RPO <= 10s。

当上游 TiDB 集群出现以下情况时,会导致 TiCDC 延迟上升,进而影响 RPO:

  • TPS 短时间内大幅度上升
  • 上游出现大事务或者长事务
  • Reload 或 Upgrade 上游 TiKV 集群或 TiCDC 集群
  • 执行耗时很长的 DDL 语句,例如:add index
  • 使用过于激进的 PD 调度策略,导致频繁 region leader 迁移或 region merge/split

使用前提

  • 准备高可用的对象存储或 NFS 系统,用于存储 TiCDC 的实时增量数据备份文件,在上游发生灾难情况下,该文件存储可以访问。
  • TiCDC 对需要具备灾难场景最终一致性的 changefeed 开启该功能,开启方式是在 changefeed 配置文件中增加以下配置:
[consistent] # 一致性级别,选项有: # - none: 默认值,非灾难场景,只有在任务指定 finished-ts 情况下保证最终一致性。 # - eventual: 使用 redo log,提供上游灾难情况下的最终一致性。 level = "eventual" # 单个 redo log 文件大小,单位 MiB,默认值 64,建议该值不超过 128。 max-log-size = 64 # 刷新或上传 redo log 至 S3 的间隔,单位毫秒,建议该参数 >= 2000。 flush-interval = 2000 # redo log 备份文件的地址,支持的 scheme 包括 nfs(NFS 目录)和 Amazon S3、GCS 和 Azure(上传至对象存储)。 storage = "$SCHEME://logbucket/test-changefeed?endpoint=http://$ENDPOINT/"

灾难恢复

当上游发生灾难后,需要通过 cdc redo 命令在下游手动恢复。恢复流程如下:

  1. 确保 TiCDC 进程已经退出,防止在数据恢复过程中上游恢复服务,TiCDC 重新开始同步数据。
  2. 使用 cdc binary 进行数据恢复,具体命令如下:
cdc redo apply --tmp-dir="/tmp/cdc/redo/apply" \ --storage="s3://logbucket/test-changefeed?endpoint=http://10.0.10.25:24927/" \ --sink-uri="mysql://normal:123456@10.0.10.55:3306/"

以上命令中:

  • tmp-dir:指定用于下载 TiCDC 增量数据备份文件的临时目录。
  • storage:指定存储 TiCDC 增量数据备份文件的地址,为对象存储 URI 或者 NFS 目录。
  • sink-uri:数据恢复的目标地址。scheme 仅支持 mysql

文档内容是否有帮助?