【是否原创】是
【首发渠道】TiDB 社区
【正文】
使用 TiCDC 实时同步 TiDB 数据到备用逃生环境的实践
一、引言
TiDB 的实施过程并不像一般人所想的那样，做好数据迁移之后完全启用新库，抛弃旧库。新库对上层系统的兼容性需要长时间的测试以及实际生产过程来证明。过程中一旦发生问题，想要恢复将会遇到大问题。所以我们在 TiDB 实施案例中最常听到的单词就是平滑迁移。
何谓平滑迁移？也就是说并不在迁移阶段初始阶段就全部启用 TiDB。而是首先做好数据迁移，数据同步操作。接着将上层系统的读流量接入 TiDB，经过一段时间发现 TiDB 可以胜任读库任务，然后就在此基础上接入写流量。期间使用运维工具将 TiDB 的数据反向同步到 MySQL 以保证万一 TiDB 出现问题无法支持上层业务系统时，能够快速切换到该 MySQL 环境。我们称这个 MySQL 为逃生环境。
迁移 TiDB 数据到 MySQL 有多种方式。早期 TiDB Binlog 作为主流迁移工具，在实际生产中获得大量的实践应用。但是随着TiDB版本更迭，TiDB Binlog已无法完全兼容最新的 TiDB 版本。具体兼容性问题可以查看官方文档（https://docs.pingcap.com/zh/tidb/stable/tidb-binlog-overview）
今天向大家介绍的是另外一种迁移工具：TiCDC。TiCDC 是一款通过拉取 TiKV 变更日志实现的 TiDB 增量数据同步工具，具有将数据还原到与上游任意 TSO 一致状态的能力，同时提供开放数据协议 (TiCDC Open Protocol)，支持其他系统订阅数据变更。
二、实验环境
实验中使用9台虚拟机，每台虚拟机配置及节点分配如下；
| IP | 部署节点 | OS | 网卡 | CPU | 内存 | 存储 |
|---|---|---|---|---|---|---|
| 10.3.72.90 | PD，监控 | Centos7 | 千兆 | 4核 | 16G | 120g |
| 10.3.72.88 | TiDB | Centos7 | 千兆 | 4核 | 16G | 120g |
| 10.3.72.83 | TiKV | Centos7 | 千兆 | 4核 | 16G | 120g |
| 10.3.72.125 | TiKV | Centos7 | 千兆 | 4核 | 16G | 120g |
| 10.3.72.145 | TiKV | Centos7 | 千兆 | 4核 | 16G | 120g |
| 10.3.72.86 | TiCDC | Centos7 | 千兆 | 4核 | 16G | 120g |
| 10.3.72.87 | TiCDC | Centos7 | 千兆 | 4核 | 16G | 120g |
| 10.3.72.112 | sysbench压测 | Centos7 | 千兆 | 4核 | 16G | 120g |
| 10.3.72.80 | 下游MySQL | Centos7 | 千兆 | 4核 | 16G | 120g |
软件环境：
TiDB v5.0.0
Sysbench v1.0.20
集群架构如下
实验环境中部署一个PD与一个TiDB以及三个TiKV。TiCDC则部署两个。以上这些组件均使用tiup部署，MySQL部署在10.3.72.80这台机器上。Sysbench作为压测工具，负责向TiDB写入数据。以此触发CDC同步任务。
三、操作过程
1、部署标准集群。
集群内包含PD、TiDB、TiKV、TiCDC、Grafana，Prometheus和Alertmanager组件。
部署配置文件实例如下：
global:
user: "root"
ssh_port: 22
deploy_dir: "/tidb-deploy"
data_dir: "/tidb-data"
server_configs: {}
pd_servers:
- host: 10.3.72.90
tidb_servers:
- host: 10.3.72.88
tikv_servers:
- host: 10.3.72.125
- host: 10.3.72.145
- host: 10.3.72.83
monitoring_servers:
- host: 10.3.72.90
grafana_servers:
- host: 10.3.72.90
alertmanager_servers:
- host: 10.3.72.90
cdc_servers:
- host: 10.3.72.86
- host: 10.3.72.87
将该配置信息写入配置文件topology.yaml中，并使用tiup发布并启动集群。（主控机与其他机器配置好免密）
## 发布集群，若主控没有与其他机器配置免密登录，则需要到下面命令结尾加上 -p 命令。回车后将提醒输入各机器的登录密码。
tiup cluster deploy tidb-test v5.0.0 topology.yaml --user root
## 启动集群
tiup cluster start tidb-test
启动集群之后验证集群的状态
tiup cluster display tidb-test
报告集群状况如下，所有组件状态均为 “UP” 说明当前集群状态良好。
Cluster type: tidb
Cluster name: tidb-test
Cluster version: v5.0.0
Deploy user: root
SSH type: builtin
Dashboard URL: http://10.3.72.90:2379/dashboard
ID Role Host Ports OS/Arch Status Data Dir Deploy Dir
-- ---- ---- ----- ------- ------ -------- ----------
10.3.72.90:9093 alertmanager 10.3.72.90 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093
10.3.72.86:8300 cdc 10.3.72.86 8300 linux/x86_64 Up /tidb-data/cdc-8300 /tidb-deploy/cdc-8300
10.3.72.87:8300 cdc 10.3.72.87 8300 linux/x86_64 Up /tidb-data/cdc-8300 /tidb-deploy/cdc-8300
10.3.72.90:3000 grafana 10.3.72.90 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000
10.3.72.90:2379 pd 10.3.72.90 2379/2380 linux/x86_64 Up|L|UI /tidb-data/pd-2379 /tidb-deploy/pd-2379
10.3.72.90:9090 prometheus 10.3.72.90 9090 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090
10.3.72.88:4000 tidb 10.3.72.88 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000
10.3.72.125:20160 tikv 10.3.72.125 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
10.3.72.145:20160 tikv 10.3.72.145 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
10.3.72.83:20160 tikv 10.3.72.83 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
2、使用tiup创建 cdc 同步任务。
首先查看cdc capture list。
tiup ctl:v5.0.0 cdc capture list --pd=http://10.3.72.90:2379
结果如下，一共有两个节点，其中10.3.72.86为owner节点，10.3.72.87为从节点。
[
{
"id": "8c5d97f3-c64a-4538-9217-eb76d55ab8ed",
"is-owner": false,
"address": "10.3.72.87:8300"
},
{
"id": "fbb9e9ce-45be-4ca6-9b97-2c00c3156192",
"is-owner": true,
"address": "10.3.72.86:8300"
}
]
接着创建cdc同步任务。
tiup ctl:v5.0.0 cdc changefeed create --pd=http://10.3.72.90:2379 --sink-uri="mysql://root:123456@10.3.72.80:3306/" --changefeed-id="task1" --sort-engine="unified"
接下来可以验证cdc同步任务是否起作用。连接 TiDB server并做建库床表查数据等操作，手动检查MySQL库中是否有对应的库表结构出现以及数据是否一致。
## 连接TiDB
mysql -h10.3.72.88 -uroot -P4000
## SQL操作
create database base;
use base;
create table t1(id int primary key, name varchar(50));
insert into t1 values(1, 'tom'), (2, 'jack');
在手动验证阶段，由于数据量十分小，同步任务的延迟也十分低，可以登录 grafana 查看TiCDC的面板，观察到刚才的操作时延只有2ms -4ms。
接着我们使用 Sysbench 运行 oltp_write_only脚本。将表数量设置为10，每张表10w行数据，并发数量为100，模拟较大压力下cdc同步的时延情况。
## 初始化库表结构以及数据
sysbench oltp_write_only --config-file=tidb-config --tables=10 --table-size=100000 --report-interval=10 --threads=100 --time=500 prepare
## 运行只写脚本，触发cdc同步任务。
sysbench oltp_write_only --config-file=tidb-config --tables=10 --table-size=100000 --report-interval=10 --threads=100 --time=500 run
##清理数据
sysbench oltp_write_only --config-file=tidb-config --tables=10 --table-size=100000 --report-interval=10 --threads=100 --time=500 cleanup
tidb-config 是提前编写好的配置文件，使用 --config-file 指定即可。如果不指定也可以在命令行中直接指定。如：–mysql-user=root。配置文件内容如下：
mysql-host=10.3.72.88
mysql-port=4000
mysql-user=root
mysql-password=
db-driver=mysql
mysql-db=base=
经过一段时间的运行，再次打开Grafana的TiCDC监控面板。可以看到 sink write duratiion指标值有了明显的提高。
四、监控数据解读及结果分析
TiCDC 的监控指标解读可以参考官方文档（https://docs.pingcap.com/zh/tidb/stable/monitor-ticdc）
在这里我们对两个指标进行一个解读。
- Sink write duration：TiCDC 将一个事务的更改写到下游的耗时直方图
- Sink write duration percentile：每秒钟中 95%、99% 和 99.9% 的情况下，TiCDC 将一个事务的更改写到下游所花费的时间
两个指标的截图如下图。
Sink write duration
Sink write duration percentile
对于第一张图，主要组成为不同颜色的方块，左侧方块群为 Sysbench prepare阶段也就是创表，创索引，插数据的阶段。这一阶段耗时偏高一点是主要是因为创建索引耗费时间较高。
通过TiDB Dashboard也可以查看慢查询列表中居前几位的都是创建索引。
右侧方块群是 Sysbench 向 TiDB 中写入数据，从而触发 CDC 同步任务。其中小方块的颜色代表该时间段内同步时延落在该范围的数量多少。颜色越深，数量越多。可以观察到大部分分同步任务时延都在 128ms 以内，在这样的集群配置情况下还是比较可观的。
再看第二张图，p95、p99、p999分别代表这同步任务中的前%95、99%、99.9%能在指标值内完成。我们发现最坏情况99.9%的同步任务完成也在1s以内，大部分都在250ms以内完成。这与第一张图其实表达的意思类似。只不过表现形式不同。
以上的这些测试数据都是在指定配置的机器上测试所得，与官方提供的数据可能不太相同。具体最佳性能数据请参考官方提供的数据。