使用 TiCDC 实时同步 TiDB 数据到备用逃生环境的实践

2022 年 7 月 11 日
本文字数：4161 字
阅读完需：约 14 分钟

作者： leeray 原文来源：https://tidb.net/blog/4f0cbff5

【是否原创】是

【首发渠道】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.90tidb_servers:  - host: 10.3.72.88tikv_servers:  - host: 10.3.72.125  - host: 10.3.72.145  - host: 10.3.72.83monitoring_servers:  - host: 10.3.72.90grafana_servers:  - host: 10.3.72.90alertmanager_servers:  - host: 10.3.72.90cdc_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:       tidbCluster name:       tidb-testCluster version:    v5.0.0Deploy user:        rootSSH type:           builtinDashboard URL:      http://10.3.72.90:2379/dashboardID                 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-909310.3.72.86:8300    cdc           10.3.72.86   8300         linux/x86_64  Up       /tidb-data/cdc-8300           /tidb-deploy/cdc-830010.3.72.87:8300    cdc           10.3.72.87   8300         linux/x86_64  Up       /tidb-data/cdc-8300           /tidb-deploy/cdc-830010.3.72.90:3000    grafana       10.3.72.90   3000         linux/x86_64  Up       -                             /tidb-deploy/grafana-300010.3.72.90:2379    pd            10.3.72.90   2379/2380    linux/x86_64  Up|L|UI  /tidb-data/pd-2379            /tidb-deploy/pd-237910.3.72.90:9090    prometheus    10.3.72.90   9090         linux/x86_64  Up       /tidb-data/prometheus-9090    /tidb-deploy/prometheus-909010.3.72.88:4000    tidb          10.3.72.88   4000/10080   linux/x86_64  Up       -                             /tidb-deploy/tidb-400010.3.72.125:20160  tikv          10.3.72.125  20160/20180  linux/x86_64  Up       /tidb-data/tikv-20160         /tidb-deploy/tikv-2016010.3.72.145:20160  tikv          10.3.72.145  20160/20180  linux/x86_64  Up       /tidb-data/tikv-20160         /tidb-deploy/tikv-2016010.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 库中是否有对应的库表结构出现以及数据是否一致。

## 连接TiDBmysql -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.88mysql-port=4000mysql-user=rootmysql-password=db-driver=mysqlmysql-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 以内完成。这与第一张图其实表达的意思类似。只不过表现形式不同。

以上的这些测试数据都是在指定配置的机器上测试所得，与官方提供的数据可能不太相同。具体最佳性能数据请参考官方提供的数据。

发布于: 刚刚阅读数: 2

原文链接:【http://xie.infoq.cn/article/ffb5e2fe79c44ed129f8f4dad】。文章转载请联系作者。

TiDB 社区干货传送门

关注

TiDB 社区官网:https://tidb.net/ 2021.12.15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目，旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

发布

暂无评论

创作场景

使用 TiCDC 实时同步 TiDB 数据到备用逃生环境的实践

使用 TiCDC 实时同步 TiDB 数据到备用逃生环境的实践

一、引言

二、实验环境

三、操作过程

四、监控数据解读及结果分析

TiDB 社区干货传送门

评论