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

【是否原创】是
【首发渠道】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。

image-20210701133646094

接着我们使用 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也可以查看慢查询列表中居前几位的都是创建索引。

image-20210701141200401

右侧方块群是 Sysbench 向 TiDB 中写入数据,从而触发 CDC 同步任务。其中小方块的颜色代表该时间段内同步时延落在该范围的数量多少。颜色越深,数量越多。可以观察到大部分分同步任务时延都在 128ms 以内,在这样的集群配置情况下还是比较可观的。

再看第二张图,p95、p99、p999分别代表这同步任务中的前%95、99%、99.9%能在指标值内完成。我们发现最坏情况99.9%的同步任务完成也在1s以内,大部分都在250ms以内完成。这与第一张图其实表达的意思类似。只不过表现形式不同。

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

2赞

前排支持!

1赞

前排支持!

1赞

前排支持!

1赞

感谢分享!

另外想问下,你们会考虑 ticdc 同步至 灾备 MySQL 库的时候,启用 old value 模式吗?

cdc 默认情况下会把上游的 update/insert 转为 replace into,那下游 MySQL 的 binlog 记录的都是 replace into 形式的语句,如果遇到上游机房故障,想去下游MySQL里抓取故障期间的 binlog 会有问题。

所以我们会考虑开启 old value 模式,不知道你们有没有这方面的实践。

TiDB 5,0默认开启old value 模式
https://docs.pingcap.com/zh/tidb/stable/troubleshoot-ticdc#创建同步任务时如果不指定---config-配置文件ticdc-的默认的行为是什么
对于故障期间的错误排查,不仅可以在下游抓取binlog。在集群内各节点也会有日志,如果监控还能用的话也可以通过监控排查。对于再次将MySQL数据恢复到TiDB,可以用DM。