--1. 下载并安装 TiUP
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
source /root/.bash_profile
---指定 TiDB 版本以及各组件实例个数
tiup playground v5.4.0 --db 2 --pd 3 --kv 3 --monitor
---使用 TiUP 连接 TiDB
tiup client
--使用MySQL客户端进行连接
mysql --host 127.0.0.1 --port 4000 -u root
---清理 TiDB 集群
tiup clean --all
----下载BR工具
wget https://download.pingcap.org/tidb-toolkit-v5.4.0-linux-amd64.tar.gz
tar xvf tidb-toolkit-v5.4.0-linux-amd64.tar.gz
--对 TiDB 集群进行扩容和缩容
编辑扩容文件，内容如下:
# vi scale-out-tikv.yaml
--扩容tikv
tikv_servers:
- host: 172.16.6.157
ssh_port: 22
port: 20160
status_port: 20180
deploy_dir: /tidb-deploy/tikv-20160
data_dir: /tidb-data/tikv-20160
log_dir: /tidb-deploy/tikv-20160/log
--扩容
tiup cluster scale-out tidb-test scale-out-tikv.yaml -uroot -p
--查看集群状态
tiup cluster display tidb-test
--进行缩容操
tiup cluster scale-in tidb-test --node 172.16.6.157:20160
--查询所容后的集群状态，发现 172.16.6.157 节点的 Status 已经变为 Tombstone，代表 节点已经下线,如下所示:
tiup cluster display tidb-test
--执行 tiup cluster prune tidb-test , 清理节点信息，如下: PingCAP Education Copyright@2
tiup cluster prune tidb-test
tiup cluster display tidb-test
----使用 tiup 进行集群名修改
tiup cluster rename tidb-test tidb-prod
--查看集群状态，发现集群名已经改为 tidb-prod,
tiup cluster display tidb-prod
--升级
tiup cluster upgrade tidb_test v5.0.0
tiup cluster display tidb-test
mysql -uroot -p 172.16.6.212 -P 4000
--备份
BR 工具： 热备，物理备份
适合大数据量，只能恢复到Tidb数据库，SST文件, region leader
BR 进行备份恢复的几条限制：
1.BR 恢复到 TiCDC / Drainer 的上游集群时，恢复数据无法由 TiCDC / Drainer 同步到下游。
2.备份集群和恢复集群采用不同的排序规则new_collations_enabled_on_first_bootstrap
BR 只支持在 new_collations_enabled_on_first_bootstrap 开关值相同的集群之间进行操作。这是因为
BR仅备份KV数据。如果备份集群和恢复集群采用不同的排序规则，数据校验会不通过。所以恢复集群时，
你 需 要 确 保 select VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME='new_collation_enabled
'; 语句的开关值查询结果与备份时的查询结果相一致，才可以进行恢复。
3. 某些功能在开启或关闭状态下，会导致 KV 格式发生变化，因此备份和恢复期间如果没有统一开启或关闭，就会带来不兼容的问题
4.BR 内置版本会在执行备份和恢复操作前，对 TiDB 集群版本和自身版本进行对比检查。如果大版本不匹配（比
如 BR v4.x 和 TiDB v5.x 上），BR 会提示退出。如要跳过版本检查，可以通过设置 --check-requirements=false 强
行跳过版本检查。
---------------
br backup full -h 或
br backup full --help 来获取。
---运行 br backup 命令前，请确保以下条件：
1. TiDB 集群中没有正在运行中的 DDL。
2. 用于创建备份的存储设备有足够的空间
--恢复前的准备工作
--使用 BR 进行恢复前的准备工作如下：
运行br restore 命令前，需要检查新集群，确保集群内没有同名的表。
将单表数据备份到网络盘（推荐生产环境使用）
使用 br backup 命令，将单表数据 --db batchmark --table order_line 备份到指定的网络盘路径 local:///br_data 下。
---备份前的准备工作:
1. 配置一台高性能 SSD 硬盘主机为 NFS server 存储数据。其他所有 BR 节点，TiKV 节点和 TiFlash 节点为 NFSclient，
挂载相同的路径（例如 /br_data）到 NFS server 上以访问 NFS server。
2. FS server 和 NFS client 间的数据传输速率至少要达到备份集群的 TiKV 实例数 * 150MB/s。否则网络 I/O有可能成为性能瓶颈。
--注意：
1. 因为备份时候只备份单副本 (leader) 数据，所以即使集群中存在 TiFlash 副本，无需挂载TiFlash 节点 BR 也能完成备份。
2.BR 在恢复数据时，会恢复全部副本的数据。因此在恢复时，TiFlash 节点需要有备份数据的访问权限 BR 才能完成恢复，此时也必须将 TiFlash 节点挂载到 NFS server 上。
--备份操作前，在 TiDB 中使用 ,--命令获得备份目标表:--db batchmark --table order_line 的统计信息
admin checksum table order_line
--全库备份
./br backup full \
--pd "172.16.6.202:2379" \##连接 TiDB 数据库的 PD 节点,最好在 PD 节点 上执行,即连接本节点
--storage "local:///tmp/backup" \##备份文件存储在 TiKV 节点上的位置
--ratelimit 120 \##对于备份所用存储带宽限速
--log-file backupfull.log ##备份日志文件
--全库恢复
./br restore full \
--pd "172.16.6.202:2379" \##连接 TiDB 数据库的 PD 节点,最好在 PD 节点 上执行,即连接本节点
--storage "local:///tmp/backup" \##备份文件存储在 TiKV 节点上的位置
--ratelimit 120 \##对于备份所用存储带宽限速
--log-file backupfull.log ##备份日志文件
--单库备份
./br backup db \
--pd "172.16.6.202:2379" \
--db employees\ ##备份 employees 库下面所有的表
--storage "local:///tmp/employeesbk" \
--ratelimit 120 \
--log-file backupdb.log
---单库恢复
./br restore db \
--pd "172.16.6.202:2379" \
--db "employees" \
--storage "local:///tmp/employeesbk" \
--log-file restoredb.log
--单表备份
./br backup table \
--pd "172.16.6.202:2379" \
--db employees \
--table salaries \##备份 employees 库下面的 salaries 表
--storage "local:///tmp/salariestab" \
--ratelimit 120 \
--log-file backuptable.log
--单表恢复
./br restore table \
--pd "172.16.6.202:2379" \
--db "employees" \
--table "salaries" \
--storage "local:///tmp/salariestab" \
--log-file restoretable.log
--执行 br backup full 命令，并使用 --filter 或 -f 来指定表库过滤规则。
--将所有db*.tbl*形式的表格数据备份到每个TiKV节点上的/tmp/backup路径，并将backupmeta文件写入该路径。
br backup full \
--pd "${PDIP}:2379" \
--filter 'db*.tbl*' \
--storage "local:///tmp/backup" \
--ratelimit 128 \ ##选项限制了每个 TiKV 执行备份任务的速度上限（单位 MiB/s）。
--log-file backupfull.log
br restore full \
--pd "${PDIP}:2379" \
--filter 'db*.tbl*' \
--storage "local:///tmp/backup" \
--ratelimit 128 \ ##选项限制了每个 TiKV 执行恢复任务的速度上限（单位 MiB/s）。
--log-file backupfull.log
--增量备份
如果想要备份增量，只需要在备份的时候指定上一次的备份时间戳 --lastbackupts 即可。
注意增量备份有以下限制：
增量备份需要与前一次全量备份在不同的路径下
GC safepoint 必须在 lastbackupts 之前
br backup full \
--pd ${PDIP}:2379 \
--ratelimit 128 \
-s local:///home/tidb/backupdata/incr \
--lastbackupts ${LAST_BACKUP_TS}
以上命令会备份 (LAST_BACKUP_TS, current PD timestamp] 之间的增量数据。
--你可以使用 validate 指令获取上一次备份的时间戳，示例如下：
LAST_BACKUP_TS=`br validate decode --field="end-version" -s local:///home/tidb/backupdata | tail -n1`
---br 实例
在所有的 TiKV 节点创建文件夹 /tmp/backup,用来存储本节点的备份文件(SST 文件) 并将文件夹的权限设置为可以读写 首先登录到 TiKV 节点,之后执行:
[root@copy-of-vm-ee-centos76-v1 ~]# mkdir /tmp/backup
[root@copy-of-vm-ee-centos76-v1 ~]# chmod 777 /tmp/backup
---
cd tidb-toolkit-v5.0.1-linux-amd64/bin/
./br backup full \
--pd "172.16.6.202:2379" \##连接 TiDB 数据库的 PD 节点,最好在 PD 节点 上执行,即连接本节点
--storage "local:///tmp/backup" \##备份文件存储在 TiKV 节点上的位置
--ratelimit 120 \##对于备份所用存储带宽限速
--log-file backupfull.log ##备份日志文件
[root@rac1 ~]# cd tidb-toolkit-v5.0.1-linux-amd64/
[root@rac1 tidb-toolkit-v5.0.1-linux-amd64]# ls
bin
[root@rac1 tidb-toolkit-v5.0.1-linux-amd64]# cd bin
[root@rac1 bin]# ls
br mydumper sync_diff_inspector tidb-lightning-ctl
dumpling pd-tso-bench tidb-lightning tikv-importer
示例备份的增量数据记录 (LAST_BACKUP_TS, current PD timestamp] 之间的数据变更，以及这段时间内的
DDL。在恢复的时候，BR 会先把所有 DDL 恢复，而后才会恢复数据。
Dumpling: 热、温备份，逻辑备份
复制： 热备，逻辑备份
----------------------------------------------------------
Waiting for tiflash instances ready
127.0.0.1:3930 ... Error
CLUSTER START SUCCESSFULLY, Enjoy it ^-^
To connect TiDB: mysql --comments --host 127.0.0.1 --port 4001 -u root -p (no password)
To view the dashboard: http://127.0.0.1:2379/dashboard
PD client endpoints: [127.0.0.1:2379 127.0.0.1:2382 127.0.0.1:2384]
To view the Prometheus: http://127.0.0.1:9090
To view the Grafana: http://127.0.0.1:3000
--------使用 Dumpling 从 TiDB 数据库中导出数据----
--------从 TiDB 集群中导出数据库 world 中的表 city
./dumpling -uroot -ptidb -P4000 -h 172.16.6.212 \
--filetype sql \
-t 8 \ #并行8线程
-o /tmp/city \
-r 200000 \
-F 256MiB \
-T world.city \##导出表
./dumpling -uroot -ptidb -P4000 -h 172.16.6.212 \
--filetype csv \
-t 8 \ #并行8线程
-o /tmp/city \
-r 200000 \
-F 256MiB \
--where "id <100"
./dumpling -uroot -ptidb -P4000 -h 172.16.6.212 \
--filetype sql \
-t 8 \ #并行8线程
-o /tmp/city \
-r 200000 \
-F 256MiB \
--filter "employee.*"
-uroot -P4000 -h 172.16.6.212 :用户名为 root,端口号为4000,主机IP 为172.16.6.212;
--filetype sql :导出文件类型为 SQL 文件 -t 8 :采用 8 线程同时导出
-o /tmp/city :导出文件保存在 /tmp/city 中
-r 200000 :每个导出文件最大容纳 200000 行数据
-F 256MiB :每个导出文件最大 256 MiB
-------从 TiDB 集群中导出数据库 employees
./dumpling -uroot -ptidb -P4000 -h 172.16.6.212 \
--filetype sql \
-t 8 \ #并行8线程
-o /tmp/city \
-r 200000 \
-F 256MiB \
-B employees ##导出数据库 world
导出会生成4个文件：
metadata，包含开始结束时间
建库语句文件，: {schema}.schema-create.sql
建表语句文件，: {schema}.{table}-schema.sql
数据文件 ： {schema}.{table}.{0001}.csv|sql
导出数据异质性 ： --consistency <consistency level>
./dumpling --snapshot
./dumpling --flush ##全库锁定
1. flush 2.snapshot 3. lock 4. none 5. auto
----------使用 Dumpling 工具将 3306 端口的 MySQL 数据库的employees 库导出
./dumpling -uroot -P3306 -h '127.0.0.1' -p'Pingcap!@3' --filetype sql -t 8 -o /tmp/employees -r 200000-F 256MiB -B employees
-------------使用 TiDB Lightning 工具将数据导入到TiDB数据库
1. 编辑 TiDB Lightning 工具的配置文件
使用 TiDB Lightning 工具将数据导入到TiDB数据库
编辑 TiDB Lightning 工具的配置文件,如下所示:
注意如下:
(1) backend = "local”:表示直接导入到 TiKV-Server 中
(2) pd-addr = "172.16.6.202:2379”:选择任意一个 PD 节点的 IP 和输入端口号
# vi tidb-lightning.toml
[lightning]
# 日志
level = "info"
file = "tidb-lightning.log"
[tikv-importer]
# 选择使用的 local 后端
backend = "local" # 设置排序的键值对的临时存放地址，目标路径需要是一个空目录
sorted-kv-dir = "/tmp"
[mydumper]
# 源数据目录。
data-source-dir = "/tmp/employees/"
[tidb]
# 目标集群的信息
host = "172.16.6.212"
port = 4000
user = "root" # 表架构信息在从 TiDB 的“状态端口”获取。 status-port = 10080
# 集群 pd 的地址
pd-addr = "172.16.6.202:2379"
2. .连接到TiDB,检查导入数据前的 TiDB 数据库
mysql -h172.16.6.212 -P4000 -uroot -p
3. 开始使用 TiDB Lightning 工具进行数据导入
! /bin/bash
[root@centos76_vm bin]# nohup ./tidb-lightning -config tidb-lightning.toml > nohup.out &
[1] 31276
tail -f nohup.out
[root@centos76_vm bin]# nohup: ignoring input and redirecting stderr to stdout
（这里请注意：此时屏幕光标会悬停在最后一行，我们可以点击回车键“Enter”，来使nohup 的 tidb-lighting 在后台工作。）
4. 进入到 TiDB 数据库,查看数据导入情况
mysql -h172.16.6.212 -P4000 -uroot -p
mysql > show databases;
use employees;
show tables;
select count(*) from salaries;
5. 可以从 nohup.out 中监控 tidb-lightning 工具是否退出:
6. 可以从 tidb-lightning 工具的详细日志中查看 tidb-lightning 的详细内容:
# vi tidb-lightning.log
=---------Data Migration(DM)的部署
1.通过 tiup 安装 dm 组件,如下:
tiup install dm
2. 通过 tiup 更新 dm 组件到最新版本,如下:
tiup update --self && tiup update dm
3. 生成一个初始化配置文件,并准备编辑,如下:
tiup dm template > topology.yaml
4. 编辑 topology.yaml 文件,加入 master_servers,worker_servers, monitoring_servers,grafana_servers 和 alertmanager_servers
vi topology.yaml
内容为：
# The topology template is used deploy a minimal DM cluster, which suitable
# for scenarios with only three machinescontains. The minimal cluster contains
# - 3 master nodes # - 3 worker nodes
# You can change the hosts according your environment
---
global:
user: "tidb"
ssh_port: 22
deploy_dir: "/home/tidb/dm/deploy"
data_dir: "/home/tidb/dm/data"
# arch: "amd64"
master_servers:
- host: 172.16.6.157
- host: 172.16.6.202
- host: 172.16.6.210
worker_servers:
- host: 172.16.6.157
- host: 172.16.6.210
monitoring_servers:
- host: 172.16.6.157
grafana_servers:
- host: 172.16.6.157
alertmanager_servers:
- host: 172.16.6.157
5. 查看当前可用的 Data Migration(DM) 最新版本,或者其他可用版本
tiup list dm-master
Available versions for dm-master:
Version Installed Release Platforms
------- --------- ------- ---------
nightly -> v5.0.0-nightly-20210531 2021-05-31T21:55:15+08:00 linux/amd64,linux/arm64 v2.0.0-rc 2020-08-21T17:49:08+08:00 linux/amd64,linux/arm64 v2.0.0-rc.2 2020-09-01T20:51:29+08:00 linux/amd64,linux/arm64 v2.0.0 2020-10-30T16:10:58+08:00 linux/amd64,linux/arm64 v2.0.1 2020-12-25T13:22:29+08:00 linux/amd64,linux/arm64 v2.0.3 2021-05-11T22:14:31+08:00 linux/amd64,linux/arm64 v5.0.0-nightly-20210531 2021-05-31T21:55:15+08:00 linux/amd64,linux/arm64
6. 部署 Data Migration(DM) 集群,集群名称为 集群 dm-test
tiup dm deploy dm-test v5.0.0-nightly-20210531 ./topology.yaml --user root -p
7. 查看 TiUP 管理的 DM 集群情况,如下
tiup dm list
8. 检查部署的集群 dm-test 的状态
# tiup dm display dm-test
9. 启动集群 dm-test
tiup dm start dm-test
10..获取集群控制工具 dmctl
# tiup dmctl:v5.0.0-nightly-20210531
-------从 MySQL 同步数据到 TiDB
为 MySQL 数据库开通用户权限,并初始化数据,分别连接到端口号 3306 和 3307 的 MySQL 数据库,创建
'root'@'172.16.6.157' ,'root'@'172.16.6.210' 和 'root'@'172.16.6.202' ,并赋予allprivileges 权限(更详细权限请参考文档),
这 3 个用户用于 dm-worker 连接MySQL 数据库进行全量和增量数据的读取
mysql> create user 'root'@'172.16.6.157' identified by 'mysql'
mysql> grant all privileges on *.* to 'root'@'172.16.6.157';
mysql> create user 'root'@'172.16.6.210' identified by 'mysql'
mysql> grant all privileges on *.* to 'root'@'172.16.6.210';
mysql> create user 'root'@'172.16.6.202' identified by 'mysql'
mysql> grant all privileges on *.* to 'root'@'172.16.6.202';
. 分别连接到端口号 3306 和 3307 的 MySQL 数据库,导入数据库user,store,log,salesdb
mysql -uroot -pmysql -S /data/mydb3306/mysql.sock < 3306db.sql
mysql -uroot -pmysql -S /data/mydb3307/mysql.sock < 3307db.sql
1.编辑上游数据源配置文件
vi mysql-source-conf1.yaml
source-id: "mysql-replica-01"
from:
host: "172.16.6.212"
user: "root"
password: "F1GJCYzuWx/8H4EJHRDWwkBJCrN+4A=="
port: 3306
注意:password: "F1GJCYzuWx/8H4EJHRDWwkBJCrN+4A==" 表示隐藏掉明文的密码,
我们可以 按照如下方法生成:
tiup dmctl -encrypt 'mysql'
2. 将数据源配置文件加载到 DM 中
tiup dmctl --master-addr=172.16.6.202:8261 operate-source create mysql-source-conf1.yaml
##:--master-addr=172.16.6.202:8261 为 DM 集群中的任意一个 master 节点
2.1 查看已经加载的数据源
tiup dmctl --master-addr=172.16.6.202:8261 get-config source mysql-replica-01
2.2 查看数据源和 dm-worker 的对应关系
tiup dmctl --master-addr=172.16.6.202:8261 operate-source show
2.3## 任务配置
编辑任务配置文件 task.yaml：
# 任务名，多个同时运行的任务不能重名。
name: "test"
# 全量+增量 (all) 迁移模式。
task-mode: "all"
# 下游 TiDB 配置信息。
target-database:
host: "172.16.10.83"
port: 4000
user: "root"
password: ""
# 当前数据迁移任务需要的全部上游 MySQL 实例配置。
mysql-instances:
-
# 上游实例或者复制组 ID，参考 `inventory.ini` 的 `source_id` 或者 `dm-master.toml` 的 `source-id 配置`。
source-id: "mysql-replica-01"
# 需要迁移的库名或表名的黑白名单的配置项名称，用于引用全局的黑白名单配置，全局配置见下面的 `block-allow-list` 的配置。
block-allow-list: "global" # 如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list。
# dump 处理单元的配置项名称，用于引用全局的 dump 处理单元配置。
mydumper-config-name: "global"
-
source-id: "mysql-replica-02"
block-allow-list: "global" # 如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list。
mydumper-config-name: "global"
# 黑白名单全局配置，各实例通过配置项名引用。
block-allow-list: # 如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list。
global:
do-tables: # 需要迁移的上游表的白名单。
- db-name: "test_db" # 需要迁移的表的库名。
tbl-name: "test_table" # 需要迁移的表的名称。
# dump 处理单元全局配置，各实例通过配置项名引用。
mydumpers:
global:
extra-args: ""
######################3
name: "dm-taskX"
task-mode: all
ignore-checking-items: ["auto_increment_ID"]
任务名:dm-taskX,（X 代表任意字符）
复制方式:all(全量 + 增量),
gnore-checking-items: ["auto_increment_ID”]:忽略自增主键检测
##目标 TiDB 数据库配置信息
target-database:
host: "172.16.6.212"
port: 4000
user: "root"
password: "tidb"
数据库地址:172.16.6.212,端口为:4000,用户名:root,密码:tidb
mysql-instances:
-
source-id: "mysql-replica-01"
route-rules: ["instance-1-user-rule","sale-route-rule"]
filter-rules: ["trace-filter-rule", "user-filter-rule" , "store-filter-rule"]
block-allow-list: "log-ignored" ##定义数据源迁移表的过滤规则
mydumper-config-name: "global"
loader-config-name: "global"
syncer-config-name: "global"
-
source-id: "mysql-replica-02"
route-rules: ["instance-2-user-rule", "instance-2-store-rule","sale-route-rule"]
filter-rules: ["trace-filter-rule", "user-filter-rule" , "store-filter-rule"]
block-allow-list: "log-ignored"
mydumper-config-name: "global"
loader-config-name: "global"
syncer-config-name: "global"
# 黑白名单全局配置，各实例通过配置项名引用。
block-allow-list: # 如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list。
global:
do-tables: # 需要迁移的上游表的白名单。
- db-name: "test_db" # 需要迁移的表的库名。
tbl-name: "test_table" # 需要迁移的表的名称。
##log 库不会参与复制
block-allow-list:
log-ignored:
ignore-dbs: ["log"]
##
block-allow-list:
bw-rule-1: ##规则名称
do-dbs:["user"] ##迁移库
ignore-dbs: ["log"] ##忽略库
do-tables: # 需要迁移的上游表的白名单。
- db-name: "test_db" # 需要迁移的表的库名。
tbl-name: "test_table" # 需要迁移的表的名称。
filters: #上游数据库匹配的 binlog event filter规则
filter-rule-1: ##配置的名称
#user 库中的 trace 表不会复制 truncate ，drop 和 delete 操作
schema-pattern: "user" ##库名匹配规则，支持* 和？
table-pattern: "trace" ##表名匹配规则，支持* 和？
events: ["truncate table", "drop table", "delete"] ##匹配哪些操作
action: Ignore ##对与不匹配的binlog是迁移还是忽略
filter-rule-2:
# MySQL 数据库实例 3306 和 3307 中的 user 库不会复制删除操作
schema-pattern: "user"
events: ["drop database"]
action: Ignore
routes:
instance-1-user-rule: ##配置名称
schema-pattern: "user" ##库名匹配规则，支持* 和？
table-pattern: "test*" ##表名匹配规则，支持* 和？
target-schema: "user _north" #目标库名称
target-table: "test1" ##目标库的表名称
###
filters:
trace-filter-rule:
# user 库中的 trace 表不会复制 truncate ，drop 和 delete 操作
schema-pattern: "user"
table-pattern: "trace"
events: ["truncate table", "drop table", "delete"]
action: Ignore
user-filter-rule:
# MySQL 数据库实例 3306 和 3307 中的 user 库不会复制删除操作
schema-pattern: "user"
events: ["drop database"]
action: Ignore
store-filter-rule:
# store 库不会复制删除操作，store 库的表不会复制 truncate ，drop 和
delete 操作
schema-pattern: "store"
events: ["drop database", "truncate table", "drop table", "delete"]
action: Ignore
#########
filters:
trace-filter-rule:
# user 库中的 trace 表不会复制 truncate ，drop 和 delete 操作
schema-pattern: "user"
table-pattern: "trace"
events: ["truncate table", "drop table", "delete"]
action: Ignore
user-filter-rule:
# MySQL 数据库实例 3306 和 3307 中的 user 库不会复制删除操作
schema-pattern: "user"
events: ["drop database"]
action: Ignore
store-filter-rule:
# store 库不会复制删除操作，store 库的表不会复制 truncate ，drop 和 delete 操作
schema-pattern: "store"
events: ["drop database", "truncate table", "drop table", "delete"]
action: Ignore
###############
routes:
instance-1-user-rule:
schema-pattern: "user"
target-schema: "user _north"
instance-2-user-rule:
schema-pattern: "user"
target-schema: "user _east"
instance-2-store-rule:
schema-pattern: "store"
table-pattern: "store_sz"
target-schema: "store"
target-table: "store_suzhou
3.启动任务
为了提前发现数据迁移任务的一些配置错误，DM 中增加了前置检查功能：
启动数据迁移任务时，DM 自动检查相应的权限和配置。
也可使用 check-task 命令手动前置检查上游的 MySQL 实例配置是否符合 DM 的配置要求。
注意
第一次启动数据迁移任务时，必须确保上游数据库已配置。否则，启动任务时会报错。
使用 tiup dmctl 执行以下命令启动数据迁移任务。其中，task.yaml 是之前编辑的配置文件。
##任务配置文件 task.yaml：
tiup dmctl --master-addr=172.16.10.71:8261 start-task dm-task.yaml
###检查
##对于上游 MySQL 源数据库进行检查,得到期待结果,如下:
tiup dmctl --master-addr=172.16.6.202:8261 check-task dm-task.yaml
tiup dmctl --master-addr=172.16.10.71:8261 check-task dm-task.yaml
tiup dmctl --master-addr=172.16.10.71:8261 pause-task dm-task.yaml##暂停
tiup dmctl --master-addr=172.16.10.71:8261 resume-task dm-task.yaml ##恢复
tiup dmctl --master-addr=172.16.10.71:8261 stop-task dm-task.yaml
tiup dmctl --master-addr=172.16.6.202:8261 query-status dm-task.yaml
如果执行该命令后返回的结果如下，则表明任务已成功启动。
{
"result": true,
"msg": "",
"workers": [
{
"result": true,
"worker": "172.16.10.72:8262",
"msg": ""
},
{
"result": true,
"worker": "172.16.10.73:8262",
"msg": ""
}
]
}
如果任务启动失败，可根据返回结果的提示进行配置变更后执行 start-task task.yaml 命令重新启动任务。
4.查询任务
如需了解 DM 集群中是否存在正在运行的迁移任务及任务状态等信息，可使用 tiup dmctl 执行以下命令进行查询：
tiup dmctl --master-addr 172.16.10.71:8261 query-status
5停止任务
如果不再需要进行数据迁移，可以使用 tiup dmctl 执行以下命令停止迁移任务：
tiup dmctl --master-addr 172.16.10.71:8261 stop-task test
其中的 test 是 task.yaml 配置文件中 name 配置项设置的任务名。
第 8 步：监控任务与查看日志
如果使用 TiUP 部署 DM 集群时，正确部署了 Prometheus、Alertmanager 与 Grafana，且其地址均为 172.16.10.71。可在浏览器中打开 http://172.16.10.71:9093 进入 Alertmanager 查看 DM 告警信息；可在浏览器中打开 http://172.16.10.71:3000 进入 Grafana，选择 DM 的 dashboard 查看 DM 相关监控项。
DM 在运行过程中，DM-worker, DM-master 及 dmctl 都会通过日志输出相关信息。各组件的日志目录如下：
DM-master 日志目录：通过 DM-master 进程参数 --log-file 设置。如果使用 TiUP 部署 DM，则日志目录位于 {log_dir}。
DM-worker 日志目录：通过 DM-worker 进程参数 --log-file 设置。如果使用 TiUP 部署 DM，则日志目录位于 {log_dir}。
DM 配置优化
本文档介绍如何对迁移任务的配置进行优化，从而提高 DM 的数据迁移性能。
全量导出
全量导出相关的配置项为 mydumpers，下面介绍和性能相关的参数如何配置。
rows
设置 rows 选项可以开启单表多线程并发导出，值为导出的每个 chunk 包含的最大行数。开启后，DM 会在 MySQL 的单表并发导出时，优先选出一列做拆分基准，选择的优先级为主键 > 唯一索引 > 普通索引，选出目标列后需保证该列为整数类型（如 INT、MEDIUMINT、BIGINT 等）。
rows 的值可以设置为 10000，具体设置的值可以根据表中包含数据的总行数以及数据库的性能做调整。另外也需要设置 threads 来控制并发线程数量，默认值为 4，可以适当做些调整。
chunk-filesize
DM 全量备份时会根据 chunk-filesize 参数的值把每个表的数据划分成多个 chunk，每个 chunk 保存到一个文件中，大小约为 chunk-filesize。根据这个参数把数据切分到多个文件中，这样就可以利用 DM Load 处理单元的并行处理逻辑提高导入速度。该参数默认值为 64（单位为 MB），正常情况下不需要设置，也可以根据全量数据的大小做适当的调整。
注意
mydumpers 的参数值不支持在迁移任务创建后更新，所以需要在创建任务前确定好各个参数的值。如果需要更新，则需要使用 dmctl stop 任务后更新配置文件，然后再重新创建任务。
mydumpers.threads 可以使用配置项 mydumper-thread 替代来简化配置。
如果设置了 rows，DM 会忽略 chunk-filesize 的值。
全量导入
全量导入相关的配置项为 loaders，下面介绍和性能相关的参数如何配置。
pool-size
pool-size 为 DM Load 阶段线程数量的设置，默认值为 16，正常情况下不需要设置，也可以根据全量数据的大小以及数据库的性能做适当的调整。
注意
loaders 的参数值不支持在迁移任务创建后更新，所以需要在创建任务前确定好各个参数的值。如果需要更新，则需要使用 dmctl stop 任务后更新配置文件，然后再重新创建任务。
loaders.pool-size 可以使用配置项 loader-thread 替代来简化配置。
增量复制
增量复制相关的配置为 syncers，下面介绍和性能相关的参数如何配置。
worker-count
worker-count 为 DM Sync 阶段并发迁移 DML 的线程数量设置，默认值为 16，如果对迁移速度有较高的要求，可以适当调高改参数的值。
batch
batch 为 DM Sync 阶段迁移数据到下游数据库时，每个事务包含的 DML 的数量，默认值为 100，正常情况下不需要调整。
注意
syncers 的参数值不支持在迁移任务创建后更新，所以需要在创建任务前确定好各个参数的值。如果需要更新，则需要使用 dmctl stop 任务后更新配置文件，然后再重新创建任务。
syncers.worker-count 可以使用配置项 syncer-thread 替代来简化配置。
worker-count 和 batch 的设置需要根据实际的场景进行调整，例如：DM 到下游数据库的网络延迟较高，可以适当调高 worker-count，调低 batch。
-----------处理不兼容的DDL语句
handle-error
handle-error 命令用于处理错误的 DDL 语句。
---使用 handle-error <task-name> skip 命令跳过该 DDL 语句以恢复迁移任务
tiup dmctl --master-addr=172.16.10.71:8261 handle-error test skip
handle-error -h
Usage:
dmctl handle-error <task-name | task-file> [-s source ...] [-b binlog-pos] <skip/replace/revert> [replace-sql1;replace-sql2;] [flags]
Flags:
-b, --binlog-pos string position used to match binlog event if matched the handler-error operation will be applied. The format like "mysql-bin|000001.000003:3270"
-h, --help help for handle-error
Global Flags:
-s, --source strings MySQL Source ID
参数解释
task-name：
非 flag 参数，string，必选；
指定预设的操作将生效的任务。
source：
flag 参数，string，--source；
source 指定预设操作将生效的 MySQL 实例。
skip：跳过该错误
replace：替代错误的 DDL 语句
revert：重置该错误先前的 skip/replace 操作, 仅在先前的操作没有最终生效前执行
binlog-pos：
flag 参数，string，--binlog-pos；
若不指定，DM 会自动处理当前出错的 DDL 语句
在指定时表示操作将在 binlog-pos 与 binlog event 的 position 匹配时生效，格式为 binlog-filename:binlog-pos，如 mysql-bin|000001.000003:3270。
在迁移执行出错后，binlog position 可直接从 query-status 返回的 startLocation 中的 position 获得；在迁移执行出错前，binlog position 可在上游 MySQL 中使用 SHOW BINLOG EVENTS 获得。
TiDB Data Migration 日常巡检
本文总结了 TiDB Data Migration (DM) 工具日常巡检的方法：
方法一：执行 query-status 命令查看任务运行状态以及相关错误输出。详见查询状态。
方法二：如果使用 TiUP 部署 DM 集群时正确部署了 Prometheus 与 Grafana，如 Grafana 的地址为 172.16.10.71，可在浏览器中打开 http://172.16.10.71:3000 进入 Grafana，选择 DM 的 Dashboard 即可查看 DM 相关监控项。具体监控指标参照监控与告警设置。
方法三：通过日志文件查看 DM 运行状态和相关错误。
DM-master 日志目录：通过 DM-master 进程参数 --log-file 设置。如果使用 TiUP 部署 DM，则日志目录位于 {log_dir}。
DM-worker 日志目录：通过 DM-worker 进程参数 --log-file 设置。如果使用 TiUP 部署 DM，则日志目录位于 {log_dir}。
----TiDB Binlog 是一个用于收集 TiDB 的 binlog，并提供准实时备份和同步功能的商业工具。
tidb 的binlog是按照事务的提交时间有序记录
未提交的事务不会出现在binlog
tidb 的binlog 与MYSQLd的ROW格式类似
tidb 的binlog 默认是关闭的。
tidb 的binlog 是异步复制。
tidb 的binlog 可以同步数据到mysql
TiDB Binlog 支持以下功能场景：
数据同步：同步 TiDB 集群数据到其他数据库
实时备份和恢复：备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复
注意：
TiDB Binlog 与 TiDB v5.0 版本开始引入的一些特性不兼容，无法一起使用，详情参照注意事项。
建议使用TiCDC 替代 TiDB Binlog
TiDB Binlog 集群主要分为 Pump 和 Drainer 两个组件，以及 binlogctl 工具：
10.10.1.1.1 Pump
Pump 用于实时记录 TiDB 产生的 Binlog，并将 Binlog 按照事务的提交时间进行排序，再提供给 Drainer 进行消费。
10.10.1.1.2 Drainer
Drainer 从各个 Pump 中收集 Binlog 进行归并，再将 Binlog 转化成 SQL 或者指定格式的数据，最终同步到下游。
10.10.1.1.3 binlogctl 工具
binlogctl 是一个 TiDB Binlog 配套的运维工具，具有如下功能：
获取 TiDB 集群当前的 TSO
查看 Pump/Drainer 状态
修改 Pump/Drainer 状态
暂停/下线 Pump/Drainer
10.10.1.2 主要特性
多个 Pump 形成一个集群，可以水平扩容。
TiDB 通过内置的 Pump Client 将 Binlog 分发到各个 Pump。
Pump 负责存储 Binlog，并将 Binlog 按顺序提供给 Drainer。
Drainer 负责读取各个 Pump 的 Binlog，归并排序后发送到下游。
Drainer 支持relay log 功能，通过 relay log 保证下游集群的一致性状态。
架构
TiDB Binlog 集群由 Pump 和 Drainer 两个组件组成。一个 Pump 集群中有若干个 Pump 节点。TiDB 实例连接到各个
Pump 节点并发送 binlog 数据到 Pump 节点。Pump 集群连接到 Drainer 节点，Drainer 将接收到的更新数据转换到
某个特定下游（例如 Kafka、另一个 TiDB 集群或 MySQL 或 MariaDB Server）指定的正确格式。
Pump 的集群架构能确保 TiDB 或 Pump 集群中有新的实例加入或退出时更新数据不会丢失。
安装
由于 RHEL/CentOS 7 的默认包装库中包括 MariaDB Server，本示例选择的是 MariaDB Server。后续除了安装服务器，
也需要安装客户端。安装指令如下：
sudo yum install -y mariadb-server
curl -LO https://download.pingcap.org/tidb-latest-linux-amd64.tar.gz | tar xzf - && cd tidb-latest-linux-amd64
通过执行以下步骤配置一个 TiDB 集群，该集群包括 pd-server、tikv-server 和 tidb-server 各组件的单个实
例。
1. 填充配置文件：
printf > pd.toml %s\\n 'log-file="pd.log"' 'data-dir="pd.data"' &&
printf > tikv.toml %s\\n 'log-file="tikv.log"' '[storage]' 'data-dir="tikv.data"' '[pd]' 'endpoints=["127.0.0.1:2379"]' '[rocksdb]' max-open-files=1024 '[raftdb]' max-open-files=1024 &&
printf > pump.toml %s\\n 'log-file="pump.log"' 'data-dir="pump.data"' 'addr="127.0.0.1:8250" ,' 'advertise-addr="127.0.0.1:8250"' 'pd-urls="http://127.0.0.1:2379"' &&
printf > tidb.toml %s\\n 'store="tikv"' 'path="127.0.0.1:2379"' '[log.file]' 'filename="tidb.log"' '[binlog]' 'enable=true' &&
printf > drainer.toml %s\\n 'log-file="drainer.log"' '[syncer]' 'db-type="mysql"' '[syncer.to]' 'host="127.0.0.1"' 'user="root"' 'password=""' 'port=3306'
2. 查看配置细节：
for f in *.toml; do echo "$f:"; cat "$f"; echo; done
预期输出：
drainer.toml:
addr="127.0.0.1:8250" ## drainer 提供服务的地址
data-dir="drainer.data"##drainer数据存储位置
pd-urls="http://127.0.0.1:2379" ##pd集群节点的地址 ，英文逗号分隔，中间不加空格
log-file="drainer.log"
[syncer]
db-type="mysql" ##drainer下游服务类型 ：mysql,tidb,file,kafka
[syncer.to]
host="127.0.0.1"
user="root"
password=""
port=3306
pd.toml:
log-file="pd.log"
data-dir="pd.data"
pump.toml:
log-file="pump.log"
data-dir="pump.data"
addr="127.0.0.1:8250"
advertise-addr="127.0.0.1:8250"
pd-urls="http://127.0.0.1:2379" ##pd集群节点的地址 ，英文逗号分隔，中间不加空格
gc=7 #保留天数
heartbeat-interval =2 ##向pd发送心跳的间隔
tidb.toml:
store="tikv"
path="127.0.0.1:2379"
[log.file]
filename="tidb.log"
[binlog]
enable=true
tikv.toml:
log-file="tikv.log"
[storage]
data-dir="tikv.data"
[pd]
endpoints=["127.0.0.1:2379"]
[rocksdb]
max-open-files=1024
[raftdb]
max-open-files=1024
##查看pump ,rainer状态
./bin/binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=pumps &&
./bin/binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=drainers &&
##用binlogctl 暂停drainer，
./bin/binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=pause-drainer --node-id=localhost.localdomain:8249
./bin/binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=offline-drainer --node-id=localhost.localdomain:8249
##用binlogctl 暂停pump
./bin/binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=pause-pump --node-id=localhost.localdomain:8249
./bin/binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=offline-pump --node-id=localhost.localdomain:8249
10.10.2.5 启动程序
现在可启动各个组件。推荐启动顺序依次为 Placement Driver (PD)、TiKV、Pump（TiDB 发送 binlog 日志必须连接Pump 服务）、TiDB。
1. 启动所有服务：
./bin/pd-server --config=pd.toml &>pd.out &
./bin/tikv-server --config=tikv.toml &>tikv.out &
./bin/pump --config=pump.toml &>pump.out &
sleep 3 &&
./bin/tidb-server --config=tidb.toml &>tidb.out &
2. 如果执行 jobs，可以看到后台正在运行的程序，列表如下：
jobs
连接
按以上步骤操作后，TiDB 的 4 个组件开始运行。接下来可以使用以下 MariaDB 或 MySQL 命令行客户端，通过
4000 端口连接到 TiDB 服务：
mysql -h 127.0.0.1 -P 4000 -u root -e 'select tidb_version();'
连接后 TiDB 集群已开始运行，pump 读取集群中的 binlog 数据，并在其数据目录中将 binlog 数据存储为 relay log。
下一步是启动一个可供 drainer 写入的 MariaDB Server。
1. 启动 drainer：
sudo systemctl start mariadb &&
./bin/drainer --config=drainer.toml &>drainer.out &
./bin/drainer --config=drainer.toml -initial-commit-st {-initial-commit-ts}
如果你的操作系统更易于安装 MySQL，只需保证监听 3306 端口。另外，可使用密码为空的 “root” 用户
连接到 MySQL，或调整 drainer.toml 连接到 MySQL。
mysql -h 127.0.0.1 -P 3306 -u root
如下表格是包含 checkpoint 表格的 tidb_binlog 数据库。drainer 使用 checkpoint 表格，记录 TiDB 集群
中的 binlog 已经更新到了哪个位置。
use tidb_binlog;
Database changed
select * from checkpoint;
打开另一个连接到 TiDB 的客户端，创建一个表格并插入几行数据。建议在 GNU Screen 软件中操作，从而
同时打开多个客户端。
mysql -h 127.0.0.1 -P 4000 --prompt='TiDB [\d]> ' -u root
create database tidbtest;
use tidbtest;
create table t1 (id int unsigned not null AUTO_INCREMENT primary key);
切换回 MariaDB 客户端可看到新的数据库、新的表格和最近插入的行数据。
use tidbtest;
show tables;
可看到查询 MariaDB 时插入到 TiDB 相同的行数据，表明 TiDB Binlog 安装成功
binlogctl
加入到集群的 Pump 和 Drainer 的数据存储在 Placement Driver (PD) 中。binlogctl 可用于查询和修改状态信息。更多
信息请参考binlogctl guide。
使用 binlogctl 查看集群中 Pump 和 Drainer 的当前状态：
./bin/binlogctl -cmd drainers
./bin/binlogctl -cmd pumps
如果结束 Drainer 进程，集群会改进程设置 “已暂停（即集群等待 Drainer 重新加入）” 的状态。
pkill drainer &&
./bin/binlog
使用 binlogctl 的 “NodeIDs” 可控制单个对应节点。在该情况下，Drainer 的节点 ID 是 “localhost.localdomain:8249”，
Pump 的节点 ID 是 “localhost.localdomain:8250”。
本文档中的 binlogctl 主要用于集群重启。如果在 TiDB 集群中终止并尝试重启所有的进程，由于 Pump 无法连
接 Drainer 且认为 Drainer 依旧 “在线”，Pump 会拒绝启动。这里的进程并不包括下游的 MySQL 或 MariaDB 或
Drainer。
以下有三个方案可解决上述问题：
使用 binlogctl 停止 Drainer，而不是结束进程：
./bin/binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=drainers &&
./bin/binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=pause-drainer --node-id=localhost.localdomain:8249
在启动 Pump 之前先启动 Drainer。 在启动 PD 之后但在启动 Drainer 和 Pump 之前，使用 binlogctl 更新已暂定 Drainer 的状态。
./bin/binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=update-drainer --node-id=localhost.localdomain:8249 --state=paused
清理
在 shell 终端里可启动创建集群的所有进程（pd-server 、tikv-server、pump、tidb-server、drainer）。可通
过在 shell 终端中执行 pkill -P $$ 停止 TiDB 集群服务和 TiDB Binlog 进程。按一定的顺序停止这些进程有利于
留出足够的时间彻底关闭每个组件。
for p in tidb-server drainer pump tikv-server pd-server; do pkill "$p"; sleep 1; done
如果需要所有服务退出后重启集群，可以使用一开始启动服务的命令。如以上binlogctl 部分所述，需要先
启动 Drainer 再启动 Pump，最后启动 tidb-server。
./bin/pd-server --config=pd.toml &>pd.out &
./bin/tikv-server --config=tikv.toml &>tikv.out &
./bin/drainer --config=drainer.toml &>drainer.out &
sleep 3
./bin/pump --config=pump.toml &>pump.out &
sleep 3
./bin/tidb-server --config=tidb.toml &>tidb.out &
######部署 TiDB Binlog
编辑扩容文件,如下（注意：在 mysql 数据库中需要创建用户）:
create user 'root'@'172.16.6.212' identified by 'mysql';
> grant all privileges on *.* to 'root'@'172.16.6.212';
1.
vi scale-out-binlog.yaml
pump_servers:
- host: 172.16.6.202
drainer_servers:
- host: 172.16.6.212
config:
syncer.db-type: "mysql"
syncer.to.host: "172.16.6.212"
syncer.to.user: "root"
syncer.to.password: "mysql"
syncer.to.port: 3306
pump_servers:
- host: 172.16.6.202
代表 pump 节点为 172.16.6.202
drainer_servers:
- host: 172.16.6.212
config:
syncer.db-type: "mysql"
syncer.to.host: "172.16.6.212"
syncer.to.user: "root"
syncer.to.password: "mysql"
syncer.to.port: 3306
代表 drainer 节点为172.16.6.212,同时配置目标数据库(下游)的 MySQL 数据源的 IP 为
172.16.6.212 ,端口为 3306,MySQL 的复制用户为 root,密码为 mysql
2. 使用 tiup 组件对现有 tidb 数据库进行扩容,增加 pump 和 drainer 节点,
tiup cluster scale-out tidb-test scale-out-binlog.yaml -uroot -p
3. 扩容结束后,查看 TiDB 数据库集群,
# tiup cluster display tidb-test
4. 启动 pump 节点和 drainer 节点后,我们需要开启 TiDB 数据库的 binlog 日志,我们使用 tiup cluster edit-config 命令来编辑系统变量 binlog.enable: true 和 binlog.ignore-error: true,
tiup cluster edit-config tidb-test
server_configs:
tidb:
binlog.enable: true
binlog.ignore-error: true
5. 使用命令 tiup cluster reload 来载入新的配置
tiup cluster reload tidb-test
6. 登录到 TiDB 数据库,查看 binlog 是否已经开启
show variables like "log_bin";
登录到 TiDB 数据库,查看 pump 节点和 drainer 节点是否正常
show pump status;
show drainer status;
##使用 TiDB Binlog 进行 TiDB 数据库到 MySQL 数据库的同步复制
管理 TiDB Binlog 复制
1. 使用 binlogctl 来管理 TiDB Binlog 的复制,所以需要预先下载安装 binlogctl 工 具,方法如下 1.1. 下载 idb-v5.0.0-linux-amd64.tar.gz 安装包,binlogctl 工具在里面
wget https://download.pingcap.org/tidb-v5.0.0-linux-amd64.tar.gz
2.解压 idb-v5.0.0-linux-amd64.tar.gz,获取二进制文件,
# tar xvf tidb-v5.0.0-linux-amd64.tar.gz
3.检查 binlogctl 是否存在,
cd tidb-v5.0.0-linux-amd64/bin/
ls
arbiter binlogctl drainer etcdctl pd-ctl pd-recover pd-server pump reparo tidb-ctl tidb-server tikv-ctl tikv-server
4.查看 pump 节点的状态
./binlogctl -pd-urls=http://172.16.6.202:2379 -cmd pumps
5.查看 drainer 节点的状态
./binlogctl -pd-urls=http://172.16.6.202:2379 -cmd drainers
6.暂停 drainer 节点
./binlogctl -pd-urls=http://172.16.6.202:2379 -cmd pause-drainer -node-id 172.16.6.212:8249
7.确认暂停的 drainer 节点状态,
./binlogctl -pd-urls=http://172.16.6.202:2379 -cmd drainers
8.确认复制是否还可以继续
登录到 TiDB 数据库,向 test 库的表 T 中插入一行数据
mysql> insert into T values(6,'Andy');
Query OK, 1 row affected (0.01 sec)
select * from T;
| id | name |
+----+----------+
| 1 | Tom |
| 2 | Jack
|
| 3 | Frank |
| 4 | Tony |
| 6 | Andy |
+----+----------+
5 rows in set (0.00 sec)
登录到 MySQL 数据库,查询 test 库的表 T
select * from T;
| id | name |
+----+----------+
| 1 | Tom |
| 2 | Jack |
| 3 | Frank |
| 4 | Tony |
+----+----------+
4 rows in set (0.00 sec)
从结果上看,drainer 节点停止后,复制已经停止了
9. 重新启动 drainer 节点
cd /tidb-deploy/drainer-8249/bin/
./drainer -pd-urls=http://172.16.6.202:2379 -config ../conf/drainer.toml
10. 查看 MySQL 数据库,查看复制是否继续
select * from T;
##缩容 TiDB Binlog 节点
1. 先关闭 tidb 数据库的 binlog 功能
使用 tiup cluster edit-config 设置 binlog.enable 和 binlog.ignore-error 为 false,如
tiup cluster edit-config tidb-test
使用命令 tiup cluster reload 来载入新的配置
tiup cluster reload tidb-test
......
server_configs:
tidb:
binlog.enable: false
binlog.ignore-error: false {}
......
2. 查看缩容 drainer 和 pump 节点后的 TiDB 数据库集群状态
tiup cluster display tidb-test
172.16.6.212:8249 drainer 172.16.6.212 8249 linux/x86_64 Down /tidb-data/drainer-8249 /tidb-deploy/drainer-8249
3. 缩容当前集群中的 drainer 节点 172.16.6.212 8249
tiup cluster scale-in tidb-test --node 172.16.6.212:8249
4. 查看缩容后的集群状态
tiup cluster display tidb-test
5. 缩容当前集群中的 pump 节点 172.16.6.202 8250
tiup cluster scale-in tidb-test --node 172.16.6.202:8250
6.查看缩容 drainer 和 pump 节点后的 TiDB 数据库集群状态
tiup cluster display tidb-test
7.使用 tiup cluster prune 命令清理节点:
tiup cluster prune tidb-test
8. 查看集群状态,发现 pump 和 drainer 节点已经下线成功
tiup cluster display tidb-test
########################Pump Drainer 命令行参数说明##########################################################
Pump 命令行参数说明（以在 “192.168.0.11” 上部署为例）
Usage of Pump:
-L string
日志输出信息等级设置：debug，info，warn，error，fatal (默认 "info")
-V
打印版本信息
-addr string
Pump 提供服务的 RPC 地址(-addr="192.168.0.11:8250")
-advertise-addr string
Pump 对外提供服务的 RPC 地址(-advertise-addr="192.168.0.11:8250")
-config string
配置文件路径，如果你指定了配置文件，Pump 会首先读取配置文件的配置;
如果对应的配置在命令行参数里面也存在，Pump
, → 就会使用命令行参数的配置来覆盖配置文件里的配置。
-data-dir string
Pump 数据存储位置路径
-gc int
Pump 只保留多少天以内的数据 (默认 7)
-heartbeat-interval int
Pump 向 PD 发送心跳间隔 (单位 秒)
-log-file string
log 文件路径
-log-rotate string
log 文件切换频率，hour/day
-metrics-addr string
Prometheus Pushgateway 地址，不设置则禁止上报监控信息
-metrics-interval int
监控信息上报频率 (默认 15，单位 秒)
-node-id string
Pump 节点的唯一识别 ID，如果不指定，程序会根据主机名和监听端口自动生成
-pd-urls string
PD 集群节点的地址 (-pd-urls="http://192.168.0.16:2379,http://192.168.0.15:2379,http
, → ://192.168.0.14:2379")
-fake-binlog-interval int
Pump 节点生成 fake binlog 的频率 (默认 3，单位 秒)
# Pump Configuration
# Pump 绑定的地址
addr = "192.168.0.11:8250"
# Pump 对外提供服务的地址
advertise-addr = "192.168.0.11:8250"
# Pump 只保留多少天以内的数据 (默认 7)
gc = 7
# Pump 数据存储位置路径
data-dir = "data.pump"
# Pump 向 PD 发送心跳的间隔 (单位 秒)
heartbeat-interval = 2
# PD 集群节点的地址 (英文逗号分割，中间不加空格)
pd-urls = "http://192.168.0.16:2379,http://192.168.0.15:2379,http://192.168.0.14:2379"
# [security]
# 如无特殊安全设置需要，该部分一般都注解掉
# 包含与集群连接的受信任 SSL CA 列表的文件路径
# ssl-ca = "/path/to/ca.pem"
# 包含与集群连接的 PEM 形式的 X509 certificate 的路径
# ssl-cert = "/path/to/drainer.pem"
# 包含与集群链接的 PEM 形式的 X509 key 的路径
# ssl-key = "/path/to/drainer-key.pem"
# [storage]
# 设置为 true（默认值）来保证可靠性，确保 binlog 数据刷新到磁盘
# sync-log = true
# 当可用磁盘容量小于该设置值时，Pump 将停止写入数据
# 42 MB -> 42000000, 42 mib -> 44040192
# default: 10 gib
# stop-write-at-available-space = "10 gib"
# Pump 内嵌的 LSM DB 设置，除非对该部分很了解，否则一般注解掉
# [storage.kv]
# block-cache-capacity = 8388608
# block-restart-interval = 16
# block-size = 4096
# compaction-L0-trigger = 8
# compaction-table-size = 67108864
# compaction-total-size = 536870912
# compaction-total-size-multiplier = 8.0
# write-buffer = 67108864
# write-L0-pause-trigger = 24
# write-L0-slowdown-trigger = 17
启动示例
./bin/pump -config pump.toml
使用 binary 部署 Drainer
Drainer 命令行参数说明（以在 “192.168.0.13” 上部署为例）
Usage of Drainer
-L string
日志输出信息等级设置：debug，info，warn，error，fatal (默认 "info")
-V
打印版本信息
-addr string
Drainer 提供服务的地址(-addr="192.168.0.13:8249")
-c int
同步下游的并发数，该值设置越高同步的吞吐性能越好 (default 1)
-cache-binlog-count int
缓存中的 binlog 数目限制（默认 8）
如果上游的单个 binlog 较大导致 Drainer 出现 OOM 时，可尝试调小该值减少内存使用
-config string
配置文件路径，Drainer 会首先读取配置文件的配置；
如果对应的配置在命令行参数里面也存在，Drainer
, → 就会使用命令行参数的配置来覆盖配置文件里面的配置
-data-dir string
Drainer 数据存储位置路径 (默认 "data.drainer")
-dest-db-type string
Drainer 下游服务类型 (默认为 mysql，支持 tidb、kafka、file)
-detect-interval int
向 PD 查询在线 Pump 的时间间隔 (默认 10，单位 秒)
-disable-detect
是否禁用冲突监测
-disable-dispatch
是否禁用拆分单个 binlog 的 SQL 的功能，如果设置为 true，则每个 binlog
按顺序依次还原成单个事务进行同步（下游服务类型为 MySQL，该项设置为 False）
-ignore-schemas string
db 过滤列表 (默认 "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql,test")，
不支持对 ignore schemas 的 table 进行 rename DDL 操作
-initial-commit-ts（默认为 `-1`）
如果 Drainer 没有相关的断点信息，可以通过该项来设置相关的断点信息
该参数值为 `-1` 时，Drainer 会自动从 PD 获取一个最新的时间戳
-log-file string
log 文件路径
-log-rotate string
log 文件切换频率，hour/day
-metrics-addr string
Prometheus Pushgateway 地址，不设置则禁止上报监控信息
-metrics-interval int
监控信息上报频率（默认 15，单位：秒）
-node-id string
drainer 节点的唯一识别 ID，如果不指定，程序会根据主机名和监听端口自动生成
-pd-urls string
PD 集群节点的地址 (-pd-urls="http://192.168.0.16:2379,http://192.168.0.15:2379,http
, → ://192.168.0.14:2379")
-safe-mode
是否开启安全模式使得下游 MySQL/TiDB 可被重复写入
即将 insert 语句换为 replace 语句，将 update 语句拆分为 delete + replace 语句
-txn-batch int
输出到下游数据库一个事务的 SQL 数量（默认 1）
# Drainer Configuration.
# Drainer 提供服务的地址("192.168.0.13:8249")
addr = "192.168.0.13:8249"
# Drainer 对外提供服务的地址
advertise-addr = "192.168.0.13:8249"
# 向 PD 查询在线 Pump 的时间间隔 (默认 10，单位 秒)
detect-interval = 10
# Drainer 数据存储位置路径 (默认 "data.drainer")
data-dir = "data.drainer"
# PD 集群节点的地址 (英文逗号分割，中间不加空格)
pd-urls = "http://192.168.0.16:2379,http://192.168.0.15:2379,http://192.168.0.14:2379"
# log 文件路径
log-file = "drainer.log"
# Drainer 从 Pump 获取 binlog 时对数据进行压缩，值可以为 "gzip"，如果不配置则不进行压缩
# compressor = "gzip"
# [security]
# 如无特殊安全设置需要，该部分一般都注解掉
# 包含与集群连接的受信任 SSL CA 列表的文件路径
# ssl-ca = "/path/to/ca.pem"
# 包含与集群连接的 PEM 形式的 X509 certificate 的路径
# ssl-cert = "/path/to/pump.pem"
# 包含与集群链接的 PEM 形式的 X509 key 的路径
# ssl-key = "/path/to/pump-key.pem"
# Syncer Configuration
[syncer]
# 如果设置了该项，会使用该 sql-mode 解析 DDL 语句，此时如果下游是 MySQL 或 TiDB 则
# 下游的 sql-mode 也会被设置为该值
# sql-mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
# 输出到下游数据库一个事务的 SQL 语句数量 (默认 20)
txn-batch = 20
# 同步下游的并发数，该值设置越高同步的吞吐性能越好 (默认 16)
worker-count = 16
851# 是否禁用拆分单个 binlog 的 SQL 的功能，如果设置为 true，则按照每个 binlog
# 顺序依次还原成单个事务进行同步（下游服务类型为 MySQL, 该项设置为 False）
disable-dispatch = false
# safe mode 会使写下游 MySQL/TiDB 可被重复写入
# 会用 replace 替换 insert 语句，用 delete + replace 替换 update 语句
safe-mode = false
# Drainer 下游服务类型（默认为 mysql）
# 参数有效值为 "mysql"，"tidb"，"file"，"kafka"
db-type = "mysql"
# 事务的 commit ts 若在该列表中，则该事务将被过滤，不会同步至下游
ignore-txn-commit-ts = []
# db 过滤列表 (默认 "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql,test")，
# 不支持对 ignore schemas 的 table 进行 rename DDL 操作
ignore-schemas = "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql"
# replicate-do-db 配置的优先级高于 replicate-do-table。如果配置了相同的库名，
, → 支持使用正则表达式进行配置。
# 以 '~' 开始声明使用正则表达式
# replicate-do-db = ["~^b.*","s1"]
# [syncer.relay]
# 保存 relay log 的目录，空值表示不开启。
# 只有下游是 TiDB 或 MySQL 时该配置才生效。
# log-dir = ""
# 每个文件的大小上限
# max-file-size = 10485760
# [[syncer.replicate-do-table]]
# db-name ="test"
# tbl-name = "log"
# [[syncer.replicate-do-table]]
# db-name ="test"
# tbl-name = "~^a.*"
# 忽略同步某些表
# [[syncer.ignore-table]]
# db-name = "test"
# tbl-name = "log"
852# db-type 设置为 mysql 时，下游数据库服务器参数
[syncer.to]
host = "192.168.0.13"
user = "root"
# 如果你不想在配置文件中写明文密码，则可以使用 `./binlogctl -cmd encrypt -text string`
, → 生成加密的密码
# 如果配置了 encrypted_password 且非空，那么配置的 password 不生效。encrypted_password
, → 和 password 无法同时生效。
password = ""
encrypted_password = ""
port = 3306
[syncer.to.checkpoint]
# 当 checkpoint type 是 mysql 或 tidb 时可以开启该选项，以改变保存 checkpoint 的数据库
# schema = "tidb_binlog"
# 目前只支持 mysql 或者 tidb 类型。可以去掉注释来控制 checkpoint 保存的位置。
# db-type 默认的 checkpoint 保存方式是:
# mysql/tidb -> 对应的下游 mysql/tidb
# file/kafka -> file in `data-dir`
# type = "mysql"
# host = "127.0.0.1"
# user = "root"
# password = ""
# 使用 `./binlogctl -cmd encrypt -text string` 加密的密码
# encrypted_password 非空时 password 会被忽略
# encrypted_password = ""
# port = 3306
# db-type 设置为 file 时，存放 binlog 文件的目录
# [syncer.to]
# dir = "data.drainer"
# db-type 设置为 kafka 时，Kafka 相关配置
# [syncer.to]
# kafka-addrs 和 zookeeper-addrs 只需要一个，两者都有时程序会优先用 zookeeper 中的
, → kafka 地址
# zookeeper-addrs = "127.0.0.1:2181"
# kafka-addrs = "127.0.0.1:9092"
# kafka-version = "0.8.2.0"
# 配置单条 broker request 中的最大 message 数（即 binlog 数），不配置或配置小于等于 0
, → 时会使用默认值 1024
# kafka-max-messages = 1024
# 配置单条 broker request 的最大 size（单位为 Byte），默认为 1 GiB，最大可配置为 2 GiB
# kafka-max-message-size = 1073741824
853# 保存 binlog 数据的 Kafka 集群的 topic 名称，默认值为 <cluster-id>_obinlog
# 如果运行多个 Drainer 同步数据到同一个 Kafka 集群，每个 Drainer 的 topic-name
, → 需要设置不同的名称
# topic-name = ""
启动示例
注意：
如果下游为 MySQL/TiDB，为了保证数据的完整性，在 Drainer 初次启动前需要获取
initial-commit-ts 的值，并进行全量数据的备份与恢复。
初次启动时使用参数 initial-commit-ts，命令如下：
./bin/drainer -config drainer.toml -initial-commit-ts {initial-commit-ts}
如果命令行参数与配置文件中的参数重合，则使用命令行设置的参数的值。
注意：
在运行 TiDB 时，需要保证至少一个 Pump 正常运行。
通过给 TiDB 增加启动参数 enable-binlog 来开启 binlog 服务。尽量保证同一集群的所有
TiDB 都开启了 binlog 服务，否则在同步数据时可能会导致上下游数据不一致。如果要临时
运行一个不开启 binlog 服务的 TiDB 实例，需要在 TiDB 的配置文件中设置 run_ddl= false。
Drainer 不支持对 ignore schemas（在过滤列表中的 schemas）的 table 进行 rename DDL 操作。
在已有的 TiDB 集群中启动 Drainer，一般需要全量备份并且获取快照时间戳，然后导入全
量备份，最后启动 Drainer 从对应的快照时间戳开始同步增量数据。
下游使用 MySQL 或 TiDB 时应当保证上下游数据库的 sql_mode 具有一致性，即下游数据库
同步每条 SQL 语句时的 sql_mode 应当与上游数据库执行该条 SQL 语句时的 sql_mode 保持
一致。可以在上下游分别执行 select @@sql_mode; 进行查询和比对。
如果存在上游 TiDB 能运行但下游 MySQL 不支持的 DDL 语句时（例如下游 MySQL 使用
InnoDB 引擎时同步语句 CREATE TABLE t1(a INT)ROW_FORMAT=FIXED;），Drainer 也会同步
失败，此时可以在 Drainer 配置中跳过该事务，同时在下游手动执行兼容的语句，详见跳
过事务。
10.10.4 TiDB Binlog 集群运维
本文首先介绍 Pump 和 Drainer 的状态及启动、退出的内部处理流程，然后说明如何通过 binlogctl 工具或者直接
在 TiDB 执行 SQL 操作来管理 binlog 集群，最后的 FAQ 部分会介绍一些常见问题以及处理方法。
10.10.4.1 Pump/Drainer 的状态
Pump/Drainer 中状态的定义：
854 online：正常运行中
pausing：暂停中
paused：已暂停
closing：下线中
offline：已下线
这些状态由 Pump/Drainer 服务自身进行维护，并定时将状态信息更新到 PD 中。
10.10.4.2 Pump/Drainer 的启动、退出流程
10.10.4.2.1 Pump
启动：Pump 启动时会通知所有 online 状态的 Drainer，如果通知成功，则 Pump 将状态设置为 online，否
则 Pump 将报错，然后将状态设置为 paused 并退出进程。
退出：Pump 进程正常退出前要选择进入暂停或者下线状态；非正常退出（kill -9、进程 panic、宕机）都
依然保持 online 状态。
– 暂停：使用 kill（非 kill -9）、Ctrl+C 或者使用 binlogctl 的 pause-pump 命令都可以暂停 Pump。接收到暂
停指令后，Pump 会变更状态为 pausing，并停止接受 binlog 的写请求，也停止向 Drainer 提供 binlog
数据。安全退出所有线程后，更新状态为 paused 然后退出进程。
– 下线：仅在使用 binlogctl 的 offline-pump 命令的情况下才会下线 Pump。接收到下线指令后，Pump 会
变更状态为 closing，并停止接受 binlog 的写请求。Pump 继续向 Drainer 提供 binlog，等待所有 binlog
数据都被 Drainer 消费后再将状态设置为 offline 并退出进程。
10.10.4.2.2 Drainer
启动：Drainer 启动时将状态设置为 online，并尝试从所有非 offline 状态的 Pump 获取 binlog，如果获取
binlog 失败，会不断尝试重新获取。
退出：Drainer 进程正常退出前要选择进入暂停或者下线状态；非正常退出（kill -9 、进程 panic、宕机）
都依然保持 online 状态。
– 暂停：使用 kill（非 kill -9）、Ctrl+C 或者使用 binlogctl 的 pause-drainer 命令都可以暂停 Drainer。接收到
指令后，Drainer 会变更状态为 pausing，并停止从 Pump 获取 binlog。安全退出所有线程后，更新状
态为 paused 然后退出进程。
– 下线：仅在使用 binlogctl 的 offline-drainer 命令的情况下才会下线 Drainer。接收到下线指令后，Drainer
变更状态为 closing，并停止从 Pump 获取 binlog。安全退出所有线程后，更新状态为 offline 然后退出
进程。
关于 Pump/Drainer 暂停、下线、状态查询、状态修改等具体的操作方法，参考如下 binlogctl 工具的使用方法介
绍。
85510.10.4.3 使用 binlogctl 工具管理 Pump/Drainer
binlogctl 支持如下这些功能：
查看 Pump/Drainer 状态
暂停/下线 Pump/Drainer
Pump/Drainer 异常状态处理
详细的介绍和使用方法请参考binlogctl 工具。
10.10.4.4 使用 TiDB SQL 管理 Pump/Drainer
要查看和管理 binlog 相关的状态，可在 TiDB 中执行相应的 SQL 语句。
查看 TiDB 是否开启 binlog，0 代表关闭，1 代表开启
show variables like "log_bin";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin
| 0 |
+---------------+-------+
查看 Pump/Drainer 状态
show pump status;
+--------|----------------|--------|--------------------|---------------------|
| NodeID |
Address | State | Max_Commit_Ts | Update_Time
|
+--------|----------------|--------|--------------------|---------------------|
| pump1 | 127.0.0.1:8250 | Online | 408553768673342237 | 2019-05-01 00:00:01 |
+--------|----------------|--------|--------------------|---------------------|
| pump2 | 127.0.0.2:8250 | Online | 408553768673342335 | 2019-05-01 00:00:02 |
+--------|----------------|--------|--------------------|---------------------|
show drainer status;
+----------|----------------|--------|--------------------|---------------------|
| NodeID |
Address | State | Max_Commit_Ts | Update_Time
|
+----------|----------------|--------|--------------------|---------------------|
| drainer1 | 127.0.0.3:8249 | Online | 408553768673342532 | 2019-05-01 00:00:03 |
+----------|----------------|--------|--------------------|---------------------|
| drainer2 | 127.0.0.4:8249 | Online | 408553768673345531 | 2019-05-01 00:00:04 |
+----------|----------------|--------|--------------------|---------------------|
856 异常情况下修改 Pump/Drainer 状态
change pump to node_state ='paused' for node_id 'pump1';
Query OK, 0 rows affected (0.01 sec)
change drainer to node_state ='paused' for node_id 'drainer1';
Query OK, 0 rows affected (0.01 sec)
该 SQL 的功能和 binlogctl 中的 update-pump 和 update-drainer 命令的功能一样，因此也只有在 Pump/Drainer
异常的情况下使用。
注意：
1. 查看 binlog 开启状态以及 Pump/Drainer 状态的功能在 TiDB v2.1.7 及以上版本中支持。
2. 修改 Pump/Drainer 状态的功能在 TiDB v3.0.0-rc.1 及以上版本中支持。该功能只修改 PD 中存
储的 Pump/Drainer 状态，如果需要暂停/下线节点，仍然需要使用 binlogctl。
################################################################################
###############################TiCDC 简介
TiCDC 是一款通过拉取 TiKV 变更日志实现的 TiDB 增量数据同步工具，具有将数据还原到与上游任意 TSO 一致状
态的能力，同时提供开放数据协议 (TiCDC Open Protocol)，支持其他系统订阅数据变更。
1 TiCDC 架构
TiCDC 运行时是一种无状态节点，通过 PD 内部的 etcd 实现高可用。TiCDC 集群支持创建多个同步任务，向多个
不同的下游进行数据同步
• TiKV CDC 组件：只输出 key-value (KV) change log。
– 内部逻辑拼装 KV change log。
– 提供输出 KV change log 的接口，发送数据包括实时 change log 和增量扫的 change log。
• capture：TiCDC 运行进程，多个 capture 组成一个 TiCDC 集群，负责 KV change log 的同步。
– 每个 capture 负责拉取一部分 KV change log。
– 对拉取的一个或多个 KV change log 进行排序。
– 向下游还原事务或按照 TiCDC Open Protocol 进行输出。
目前 TiCDC sink 模块支持同步数据到以下下游：
• MySQL 协议兼容的数据库，提供最终一致性支持。
• 以 TiCDC Open Protocol 输出到 Kafka，可实现行级别有序、最终一致性或严格事务一致性三种一致性保证。
目前 TiCDC 暂不支持的场景如下：
• 暂不支持单独使用 RawKV 的 TiKV 集群。
• 暂不支持在 TiDB 中创建 SEQUENCE 的 DDL 操作和SEQUENCE 函数。在上游 TiDB 使用 SEQUENCE 时，TiCDC 将
会忽略掉上游执行的 SEQUENCE DDL 操作/函数，但是使用 SEQUENCE 函数的 DML 操作可以正确地同步。
• 对上游存在较大事务的场景提供部分支持，详
TiCDC 安装部署
1. 在使用 TiUP 部署全新 TiDB 集群时，支持同时部署 TiCDC 组件。只需在 TiUP 启动 TiDB 集群时的配置文件中加入
TiCDC 部分即可，详细操作参考编辑初始化配置文件，具体可配置字段参考通过 TiUP 配置 cdc_servers。
初始化集群拓扑文件 ：
tiup cluster template > topology.yaml
vi topology.yaml
global:
user: "tidb"
ssh_port: 22
deploy_dir: "/tidb-deploy"
data_dir: "/tidb-data"
server_configs: {}
pd_servers:
- host: 10.0.1.4
- host: 10.0.1.5
- host: 10.0.1.6
tidb_servers:
- host: 10.0.1.7
- host: 10.0.1.8
- host: 10.0.1.9
tikv_servers:
- host: 10.0.1.1
- host: 10.0.1.2
- host: 10.0.1.3
monitoring_servers:
- host: 10.0.1.4
grafana_servers:
- host: 10.0.1.4
alertmanager_servers:
- host: 10.0.1.4
cdc_servers:
- host: 172.16.6.212
port: 8300
deploy_dir: "/tidb-deploy/cdc-8300"
log_dir: "/tidb-deploy/cdc-8300/log"
tiup cluster deploy <cluster-name> v5.0.0 ./topology.yaml
混合部署场景也可以使用
tiup cluster template --full > topology.yaml 生成的建议拓扑
模板，跨机房部署场景可以使用
tiup cluster template --multi-dc > topology.yaml
生成 的建议拓扑模板
2. 扩容 TiCDC 节点
编写 scale-out.yaml 文件：
cdc_servers:
- host: 10.0.1.3
gc-ttl: 86400
data_dir: /data/deploy/install/data/cdc-8300
- host: 10.0.1.4
gc-ttl: 86400
data_dir: /data/deploy/install/data/cdc-8300
5.2.1.3.2 2. 运行扩容命令
vi scale-out.yaml
tiup cluster scale-out <cluster-name> scale-out.yaml
tiup cluster scale-out tidb-test scale-out.yaml -uroot -p
扩容完毕后,检查 TiDB 数据库集群状态,检查 TiCDC 集群状态
tiup cluster display tidb-test
使用 tiup ctl:v5.0.0 cdc 检查 TiCDC 的状态,如下
tiup ctl:v5.0.0 cdc capture list --pd=http://172.16.6.202:2379
注意:
1. 命令中 --pd=http://172.16.6.202:2379,可以是任何一个 PD 节点
2. "is-owner": true 代表当 TiCDC 节点为 owner 节点｡
管理 TiCDC 服务进程 (capture)
• 查询 capture 列表：
cdc cli capture list --pd=http://10.0.10.25:2379
– id：服务进程的 ID。
– is-owner：表示该服务进程是否为 owner 节点。
– address：该服务进程对外提供接口的地址
管理同步任务 (changefeed)
同步任务状态流转
同步任务状态标识了同步任务的运行情况。在 TiCDC 运行过程中，同步任务可能会运行出错、手动暂停、恢
复，或达到指定的 TargetTs，这些行为都可以导致同步任务状态发生变化。本节描述 TiCDC 同步任务的各状
态以及状态之间的流转关系。
创建同步任务
使用以下命令来创建同步任务：
tiup cdc cli changefeed create --pd=http://10.0.10.25:2379 --sink-uri="mysql://root:1@127.0.0.1:3306/" --changefeed-id="simple-replication-task" --sort-engine="unified"
--changefeed-id：同步任务的 ID，格式需要符合正则表达式 ^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$。如果
不指定该 ID，TiCDC 会自动生成一个 UUID（version 4 格式）作为 ID。
• --sink-uri：同步任务下游的地址，需要按照以下格式进行配置，目前 scheme 支持 mysql/tidb/kafka
• --start-ts：指定 changefeed 的开始 TSO。TiCDC 集群将从这个 TSO 开始拉取数据。默认为当前时间。
• --target-ts：指定 changefeed 的目标 TSO。TiCDC 集群拉取数据直到这个 TSO 停止。默认为空，即 TiCDC 不 会自动停止。
• --sort-engine：指定 changefeed 使用的排序引擎。因 TiDB 和 TiKV 使用分布式架构，TiCDC 需要对数据变
更记录进行排序后才能输出。该项支持 unified（默认）/memory/file：
– unified：优先使用内存排序，内存不足时则自动使用硬盘暂存数据。该选项默认开启。
– memory：在内存中进行排序。不建议使用，同步大量数据时易引发 OOM。
– file：完全使用磁盘暂存数据。已经弃用，不建议在任何情况使用。
• --config：指定 changefeed 配置文件。
• --sort-dir: 用于指定排序器使用的临时文件目录。自 TiDB v4.0.13, v5.0.3 和 v5.1.0 起已经无效，请不要使
用。
Sink URI 配置 mysql/tidb
配置样例如下所示：
--sink-uri="mysql://root:123456@127.0.0.1:3306/?worker-count=16&max-txn-row=5000";
参数
解析
root 下游数据库的用户名
123456 下游数据库密码
127.0.0.1 下游数据库的 IP
3306 下游数据的连接端口
worker-count 向下游执行 SQL 的并发度（可选，默认值为 16）
max-txn-row 向下游执行 SQL 的 batch 大小（可选，默认值为 256）
ssl-ca 连接下游 MySQL 实例所需的 CA 证书文件路径（可选）
ssl-cert 连接下游 MySQL 实例所需的证书文件路径（可选）
ssl-key 连接下游 MySQL 实例所需的证书密钥文件路径（可选）
time-zone 连接下游 MySQL 实例时使用的时区名称，从 v4.0.8 开始生
效。（可选。如果不指定该参数，使用 TiCDC 服务进程的时区；如
果指定该参数但使用空值，则表示连接 MySQL 时不指定时区，
使用下游默认时区）
查询特定同步任务
使用 changefeed query 命令可以查询特定同步任务（对应某个同步任务的信息和状态），指定 --simple 或 -s
参数会简化输出，提供最基本的同步状态和 checkpoint 信息。不指定该参数会输出详细的任务配置、同步状
态和同步表信息。
cdc cli changefeed query -s --pd=http://10.0.10.25:2379 --changefeed-id=simple-replication-task
{
"state": "normal",
"tso": 419035700154597378,
"checkpoint": "2020-08-27 10:12:19.579",
"error": null
}
• state 代表当前 changefeed 的同步状态，各个状态必须和 changefeed list 中的状态相同。
• tso 代表当前 changefeed 中已经成功写入下游的最大事务 TSO。
• checkpoint 代表当前 changefeed 中已经成功写入下游的最大事务 TSO 对应的时间。
• error 记录当前 changefeed 是否有错误发生。
cdc cli changefeed query --pd=http://10.0.10.25:2379 --changefeed-id=simple-replication-task
Sink URI 配置 kafka
配置样例如下所示：
--sink-uri="kafka://127.0.0.1:9092/topic-name?kafka-version=2.4.0&partition-num=6&max-message-bytes=67108864&replication-factor=1"
;
URI 中可配置的的参数如下：
参数
解析
127.0.0.1
下游 Kafka 对外提供服务的 IP
9092
下游 Kafka 的连接端口
topic-name
变量，使用的 Kafka topic 名字
kafka-version
下游 Kafka 版本号。可选，默认值 2.4.0，目前支持的最低版本为 0.11.0.2，
最高版本为 2.7.0。该值需要与下游 Kafka 的实际版本保持一致。
kafka-client-id
指定同步任务的 Kafka 客户端的 ID。可选，默认值为
TiCDC_sarama_producer_同步任务的 ID。
partition-num
下游 Kafka partition 数量。可选，不能大于实际 partition 数量。如果不填，会自
动获取 partition 数量。
max-message-bytes
每次向 Kafka broker 发送消息的最大数据量（可选，默认值 64MB）
replication-factor
kafka 消息保存副本数（可选，默认值 1）
protocol
输出到 kafka 消息协议，可选值有 default、canal、avro、maxwell（默认值为
default）
max-batch-size
从 v4.0.9 引入。如果消息协议支持将多条变更记录输出到一条 kafka 消息，该
参数指定一条 kafka 消息中变更记录的最多数量，目前仅对 Kafka 的 protocol
为 default 时有效（可选，默认值为 16）
ca
连接下游 Kafka 实例所需的 CA 证书文件路径（可选）
cert
连接下游 Kafka 实例所需的证书文件路径（可选）
key
连接下游 Kafka 实例所需的证书密钥文件路径（可选）
停止同步任务
使用以下命令来停止同步任务：
tiup cdc cli changefeed pause --pd=http://10.0.10.25:2379 --changefeed-id simple-replication-task
以上命令中：
• --changefeed-id=uuid 为需要操作的 changefeed ID。
10.11.3.4.4 恢复同步任务
使用以下命令恢复同步任务：
tiup cdc cli changefeed resume --pd=http://10.0.10.25:2379 --changefeed-id simple-replication-task
以上命令中：
• --changefeed-id=uuid 为需要操作的 changefeed ID。
10.11.3.4.5 删除同步任务
使用以下命令删除同步任务：
tiup cdc cli changefeed remove --pd=http://10.0.10.25:2379 --changefeed-id simple-replication-task
• --changefeed-id=uuid 为需要操作的 changefeed ID。
更新同步任务配置
TiCDC 从 4.0.4 开始支持非动态修改同步任务配置，修改 changefeed 配置需要按照 暂停任务 -> 修改配置 -> 恢复任务 的流程。
tiup cdc cli changefeed pause -c test-cf --pd=http://10.0.10.25:2379
tiup cdc cli changefeed update -c test-cf --pd=http://10.0.10.25:2379 --sink-uri="mysql://127.0.0.1:3306/?max-txn-row=20&worker-number=8" --config=changefeed.toml;
tiup cdc cli changefeed resume -c test-cf --pd=http://10.0.10.25:2379
当前支持修改的配置包括：
• changefeed 的 sink-uri
• changefeed 配置文件及文件内所有配置
• changefeed 是否使用文件排序和排序目录
• changefeed 的 target-ts
10.11.3.4.7 管理同步子任务处理单元 (processor)
• 查询 processor 列表：
cdc cli processor list --pd=http://10.0.10.25:2379
[
{
"id": "9f84ff74-abf9-407f-a6e2-56aa35b33888",
"capture-id": "b293999a-4168-4988-a4f4-35d9589b226b",
"changefeed-id": "simple-replication-task"
}
]
• 查询特定 processor，对应于某个节点处理的同步子任务信息和状态：
cdc cli processor query --pd=http://10.0.10.25:2379 --changefeed-id=simple-replication-task --capture-id=b293999a-4168-4988-a4f4-35d9589b226b
{
"status": {
"tables": {
"56": { # 56 表示同步表 id，对应 TiDB 中表的 tidb_table_id
"start-ts": 417474117955485702
}
},
"operation": null,
"admin-job-type": 0
},
920"position": {
"checkpoint-ts": 417474143881789441,
"resolved-ts": 417474143881789441,
"count": 0
}
}
以上命令中：
• status.tables 中每一个作为 key 的数字代表同步表的 id，对应 TiDB 中表的 tidb_table_id。
• resolved-ts 代表当前 processor 中已经排序数据的最大 TSO。
• checkpoint-ts 代表当前 processor 已经成功写入下游的事务的最大 TSO。
10.11.3.5 同步任务配置文件描述
本部分详细介绍了同步任务的配置。
### 指定配置文件中涉及的库名、表名是否为大小写敏感
### 该配置会同时影响 filter 和 sink 相关配置，默认为 true
case-sensitive = true
### 是否输出 old value，从 v4.0.5 开始支持，从 v5.0 开始默认为 true
enable-old-value = true
[filter]
### 忽略指定 start_ts 的事务
ignore-txn-start-ts = [1, 2]
### 过滤器规则
### 过滤规则语法：https://docs.pingcap.com/zh/tidb/stable/table-filter#表库过滤语法
rules = ['*.*', '!test.*']
[mounter]
### mounter 线程数，用于解码 TiKV 输出的数据
worker-num = 16
[sink]
### 对于 MQ 类的 Sink，可以通过 dispatchers 配置 event 分发器
### 支持 default、ts、rowid、table 四种分发器，分发规则如下：
### - default：有多个唯一索引（包括主键）时按照 table 模式分发；只有一个唯一索引（或主键）按照
, → rowid 模式分发；如果开启了 old value 特性，按照 table 分发
### - ts：以行变更的 commitTs 做 Hash 计算并进行 event 分发
### - rowid：以所选的 HandleKey 列名和列值做 Hash 计算并进行 event 分发
### - table：以表的 schema 名和 table 名做 Hash 计算并进行 event 分发
### matcher 的匹配语法和过滤器规则语法相同
921dispatchers = [
{matcher = ['test1.*', 'test2.*'], dispatcher = "ts"},
{matcher = ['test3.*', 'test4.*'], dispatcher = "rowid"},
]
### 对于 MQ 类的 Sink，可以指定消息的协议格式
### 目前支持 default、canal、avro 和 maxwell 四种协议。default 为 TiCDC Open Protocol
protocol = "default"
10.11.3.5.1 配置文件兼容性的注意事项
• TiCDC v4.0.0 中移除了 ignore-txn-commit-ts，添加了 ignore-txn-start-ts，使用 start_ts 过滤事务。
• TiCDC v4.0.2 中移除了 db-dbs/db-tables/ignore-dbs/ignore-tables，添加了 rules，使用新版的数据库和
数据表过滤规则，详细语法参考表库过滤。
10.11.3.6 输出行变更的历史值从 v4.0.5 版本开始引入
警告：
目前输出行变更历史值属于实验特性，尚未经过完备的测试，不建议在生产环境中使用该功
能。
在默认配置下同步任务输出的 TiCDC Open Protocol 行变更数据只包含变更后的值，不包含变更前行的值，因此
该输出数据不支持 TiDB 4.0 新的 Collation 框架，也不满足 TiCDC Open Protocol 的消费端使用行变更历史值的需求。
从 v4.0.5 开始，TiCDC 支持输出行变更数据的历史值。若要开启该特性，需要在 changefeed 的配置文件的根级
别指定以下配置：
enable-old-value = true
开启该特性后，TiCDC Open Protocol 的输出格式参考TiCDC 开放数据协议 - Row Changed Event，使用 MySQL sink 时也
会自动支持的 TiDB 4.0 新 Collation 特性。
10.11.3.7 同步没有有效索引的表
从 v4.0.8 开始，TiCDC 支持通过修改任务配置来同步没有有效索引的表。若要开启该特性，需要在 changefeed
配置文件的根级别进行如下指定：
enable-old-value = true
force-replicate = true
922警告：
对于没有有效索引的表，INSERT 和 REPLACE 等操作不具备可重入性，因此会有数据冗余的
风险。TiCDC 在同步过程中只保证数据至少分发一次，因此开启该特性同步没有有效索引的
表，一定会导致数据冗余出现。如果不能接受数据冗余，建议增加有效索引，譬如增加具有
AUTO RANDOM 属性的主键列。
10.11.3.8 Unified Sorter 功能
Unified Sorter 是 TiCDC 中的排序引擎功能，用于缓解以下场景造成的内存溢出问题：
• 如果 TiCDC 数据订阅任务的暂停中断时间长，其间积累了大量的增量更新数据需要同步。
• 从较早的时间点启动数据订阅任务，业务写入量大，积累了大量的更新数据需要同步。
对v4.0.13版本之后的cdc cli创建的changefeed，默认开启Unified Sorter。对v4.0.13版本前已经存在的changefeed，
则使用之前的配置。
要确定一个 changefeed 上是否开启了 Unified Sorter 功能，可执行以下示例命令查看（假设 PD 实例的 IP 地址为
http://10.0.10.25:2379）：
cdc cli --pd="http://10.0.10.25:2379" changefeed query --changefeed-id=simple-replication-task |
, → grep 'sort-engine'
以上命令的返回结果中，如果 sort-engine 的值为 “unified”，则说明 Unified Sorter 已在该 changefeed 上开启。
注意：
• 如果服务器使用机械硬盘或其他有延迟或吞吐有瓶颈的存储设备，请谨慎开启 Unified
Sorter。
• Unified Sorter 默认使用 data_dir 储存临时文件。建议保证硬盘的空闲容量大于等于 500
GiB。对于生产环境，建议保证每个节点上的磁盘可用空间大于（业务允许的最大）
checkpoint-ts 延迟 * 业务高峰上游写入流量。此外，如果在 changefeed 创建后预期需
要同步大量历史数据，请确保每个节点的空闲容量大于等于要追赶的同步数据。
• Unified Sorter 默认开启，如果您的服务器不符合以上条件，并希望关闭 Unified Sorter，请
手动将 changefeed 的 sort-engine 设为 memory。
• 如需在已使用 memory 排序的 changefeed 上开启 Unified Sorter，参见同步任务中断，尝试再
次启动后 TiCDC 发生 OOM，如何处理回答中提供的方法。
10.11.3.9 灾难场景的最终一致性复制
从 v5.3.0 版本开始，TiCDC 开始提供灾难场景下的最终一致性复制能力。具体解决的场景是，当生产集群（即
TiCDC 同步的上游集群）发生灾难、且短时间内无法恢复对外提供服务，TiCDC 需要具备保证从集群数据一致
性的能力，并允许业务快速的将流量切换至从集群，避免数据库长时间不可用而对业务造成影响。
923该功能支持 TiCDC 将 TiDB 集群的增量数据复制到备用关系型数据库 TiDB/Aurora/MySQL/MariaDB，在 TiCDC 正常同
步没有延迟的情况下，上游发生灾难后，可以在 5 分钟内将下游集群恢复到上游的某个 snapshot 状态，并且
允许丢失的数据小于 30 分钟。即 RTO <= 5min，RPO <= 30min。
10.11.3.9.1 使用前提
• 准备好具有高可用的 S3 存储或 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 的间隔，单位毫秒，默认 1000，建议范围 500-2000。
flush-interval = 1000
### 存储 redo log 的形式，包括 nfs（NFS 目录），S3（上传至S3）
storage = "s3://logbucket/test-changefeed?endpoint=http://$S3_ENDPOINT/"
10.11.3.9.2 灾难恢复
当上游发生灾难后，需要通过 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 增量数据备份文件的地址，为 S3 或者 NFS 目录。
• sink-uri ：恢复数据到的下游地址。scheme 仅支持 mysql。
92410.11.4 TiCDC 常见问题和故障处理
本文档总结了在使用 TiCDC 过程中经常遇到的问题，给出合适的运维方法。本文档还总结了常见的运行故障，
并给出相对应的解决方案。
注意：
本文档 cdc cli 命令中指定 PD 地址为 --pd=http://10.0.10.25:2379，用户在使用时需根据
实际地址进行替换。
10.11.4.1 TiCDC 创建任务时如何选择 start-ts？
首先需要理解同步任务的 start-ts 对应于上游 TiDB 集群的一个 TSO，同步任务会从这个 TSO 开始请求数据。
所以同步任务的 start-ts 需要满足以下两个条件：
• start-ts 的值需要大于 TiDB 集群当前的 tikv_gc_safe_point，否则创建任务时会报错。
• 启动任务时，需要保证下游已经具有 start-ts 之前的所有数据。对于同步到消息队列等场景，如果不
需要保证上下游数据的一致，可根据业务场景放宽此要求。
如果不指定 start-ts 或者指定 start-ts=0，在启动任务的时候会去 PD 获取一个当前 TSO，并从该 TSO 开始同
步。
10.11.4.2 为什么 TiCDC 创建任务时提示部分表不能同步？
在使用 cdc cli changefeed create 创建同步任务时会检查上游表是否符合同步限制。如果存在表不满足同
步限制，会提示 some tables are not eligible to replicate 并列出这些不满足的表。用户选择 Y 或 y 则会
继续创建同步任务，并且同步过程中自动忽略这些表的所有更新。用户选择其他输入，则不会创建同步任务。
10.11.4.3 如何查看 TiCDC 同步任务的状态？
可以使用 cdc cli 查询同步任务的状态。例如：
cdc cli changefeed list --pd=http://10.0.10.25:2379
上述命令输出如下：
[{
"id": "4e24dde6-53c1-40b6-badf-63620e4940dc",
"summary": {
"state": "normal",
"tso": 417886179132964865,
"checkpoint": "2020-07-07 16:07:44.881",
"error": null
}
}]
925• checkpoint：即为 TiCDC 已经将该时间点前的数据同步到了下游。
• state 为该同步任务的状态：
– normal：正常同步。
– stopped：停止同步（手动暂停或出错）。
– removed：已删除任务。
注意：
该功能在 TiCDC 4.0.3 版本引入。
10.11.4.4 TiCDC 同步任务出现中断
10.11.4.4.1 如何判断 TiCDC 同步任务出现中断？
• 通过 Grafana 检查同步任务的 changefeed checkpoint 监控项。注意选择正确的 changefeed id。如果该
值不发生变化或者查看 checkpoint lag 是否不断增大，可能同步任务出现中断。
• 通过 Grafana 检查 exit error count 监控项，该监控项大于 0 代表同步任务出现错误。
• 通过 cdc cli changefeed list 和 cdc cli changefeed query 命令查看同步任务的状态信息。任务状态
为 stopped 代表同步中断，error 项会包含具体的错误信息。任务出错后可以在 TiCDC server 日志中搜索
error on running processor 查看错误堆栈，帮助进一步排查问题。
• 部分极端异常情况下 TiCDC 出现服务重启，可以在 TiCDC server 日志中搜索 FATAL 级别的日志排查问题。
10.11.4.4.2 如何查看 TiCDC 同步任务是否被人为终止？
可以使用 cdc cli 查询同步任务是否被人为终止。例如：
cdc cli changefeed query --pd=http://10.0.10.25:2379 --changefeed-id 28c43ffc-2316-4f4f-a70b-
, → d1a7c59ba79f
上述命令的输出中 admin-job-type 标志这个同步的任务的状态：
• 0: 任务进行中，没有被人为停止。
• 1: 任务暂停，停止任务后所有同步 processor 会结束退出，同步任务的配置和同步状态都会保留，可以
从 checkpoint-ts 恢复任务。
• 2: 任务恢复，同步任务从 checkpoint-ts 继续同步。
• 3: 任务已删除，接口请求后会结束所有同步 processor，并清理同步任务配置信息。同步状态保留，只
提供查询，没有其他实际功能。
10.11.4.4.3 如何处理 TiCDC 同步任务的中断？
目前已知可能发生的同步中断包括以下场景：
• 下游持续异常，TiCDC 多次重试后仍然失败。
926– 该场景下 TiCDC 会保存任务信息，由于 TiCDC 已经在 PD 中设置的 service GC safepoint，在 gc-ttl 的有
效期内，同步任务 checkpoint 之后的数据不会被 TiKV GC 清理掉。
– 处理方法：用户可以在下游恢复正常后，通过 HTTP 接口恢复同步任务。
• 因下游存在不兼容的 SQL 语句，导致同步不能继续。
– 该场景下 TiCDC 会保存任务信息，由于 TiCDC 已经在 PD 中设置的 service GC safepoint，在 gc-ttl 的有
效期内，同步任务 checkpoint 之后的数据不会被 TiKV GC 清理掉。
– 处理方法：
1. 用户需先通过 cdc cli changefeed query 查询同步任务状态信息，记录 checkpoint-ts 值。
2. 使用新的任务配置文件，增加ignore-txn-start-ts 参数跳过指定 start-ts 对应的事务。
3. 通过 HTTP API 停止旧的同步任务，使用 cdc cli changefeed create ，指定新的任务配置文件，
指定 start-ts 为刚才记录的 checkpoint-ts，启动新的同步任务恢复同步。
• 在 v4.0.13 及之前的版本中 TiCDC 同步分区表存在问题，导致同步停止。
– 该场景下 TiCDC 会保存任务信息，由于 TiCDC 已经在 PD 中设置的 service GC safepoint，在 gc-ttl 的有
效期内，同步任务 checkpoint 之后的数据不会被 TiKV GC 清理掉。
– 处理方法：
1. 通过 cdc cli changefeed pause -c <changefeed-id> 暂停同步。
2. 等待约一分钟后，通过 cdc cli changefeed resume -c <changefeed-id> 恢复同步。
10.11.4.4.4 同步任务中断，尝试再次启动后 TiCDC 发生 OOM，应该如何处理？
升级 TiDB 集群和 TiCDC 集群到最新版本。该 OOM 问题在 v4.0.14 及之后的 v4.0 版本，v5.0.2 及之后的 v5.0 版本，
更新的版本上已得到缓解。
在这些版本上，可以开启 Unified Sorter 排序功能，该功能会在系统内存不足时使用磁盘进行排序。启用的方
式是创建同步任务时在 cdc cli 内传入 --sort-engine=unified，使用示例如下：
cdc cli changefeed update -c <changefeed-id> --sort-engine="unified" --pd=http://10.0.10.25:2379
如果无法升级到上述版本，需要在之前的版本上开启 Unified Sorter，可以在创建同步任务时在 cdc cli 内传入
--sort-engine=unified 和 --sort-dir=/path/to/sort_dir，使用示例如下：
cdc cli changefeed update -c <changefeed-id> --sort-engine="unified" --sort-dir="/data/cdc/sort"
, → --pd=http://10.0.10.25:2379
注意：
• TiCDC 从 4.0.9 版本起支持 Unified Sorter 排序引擎。
• TiCDC（4.0 发布版本）还不支持动态修改排序引擎。在修改排序引擎设置前，请务必确
保 changefeed 已经停止 (stopped)。
• sort-dir 在不同版本之间有不同的行为，请参考sort-dir 及 data-dir 配置项的兼容性
说明，谨慎配置。
927• 目前 Unified Sorter 排序引擎为实验特性，在数据表较多 (>= 100) 时可能出现性能问题，影
响同步速度，故不建议在生产环境中使用。开启 Unified Sorter 前请保证各 TiCDC 节点机器
上有足够硬盘空间。如果积攒的数据总量有可能超过 1 TB，则不建议使用 TiCDC 进行同
步。
10.11.4.5 TiCDC 的 gc-ttl 是什么？
从 TiDB v4.0.0-rc.1 版本起，PD 支持外部服务设置服务级别 GC safepoint。任何一个服务可以注册更新自己服务的
GC safepoint。PD 会保证任何晚于该 GC safepoint 的 KV 数据不会在 TiKV 中被 GC 清理掉。
在 TiCDC 中启用了这一功能，用来保证 TiCDC 在不可用、或同步任务中断情况下，可以在 TiKV 内保留 TiCDC 需
要消费的数据不被 GC 清理掉。
启动 TiCDC server 时可以通过 gc-ttl 指定 GC safepoint 的 TTL，也可以通过 TiUP 修改 TiCDC 的 gc-ttl，默认值为
24 小时。在 TiCDC 中这个值有如下两重含义：
• 当 TiCDC 服务全部停止后，由 TiCDC 在 PD 所设置的 GC safepoint 保存的最长时间。
• TiCDC 中某个同步任务中断或者被手动停止时所能停滞的最长时间，若同步任务停滞时间超过 gc-ttl 所
设置的值，那么该同步任务就会进入 failed 状态，无法被恢复，并且不会继续影响 GC safepoint 的推进。
以上第二种行为是在 TiCDC v4.0.13 版本及之后版本中新增的。目的是为了防止 TiCDC 中某个同步任务停滞时间
过长，导致上游 TiKV 集群的 GC safepoint 长时间不推进，保留的旧数据版本过多，进而影响上游集群性能。
注意在某些应用场景中，比如使用 Dumpling/BR 全量同步后使用 TiCDC 接增量同步时，默认
的 gc-ttl 为 24 小时可能无法满足需求。此时应该根据实际情况，在启动 TiCDC server 时指定
gc-ttl 的值。
10.11.4.6 TiCDC GC safepoint 的完整行为是什么
TiCDC 服务启动后，如果有任务开始同步，TiCDC owner 会根据所有同步任务最小的 checkpoint-ts 更新到 PD service
GC safepoint，service GC safepoint 可以保证该时间点及之后的数据不被 GC 清理掉。如果 TiCDC 中某个同步任务中
断、或者被用户主动停止，则该任务的 checkpoint-ts 不会再改变，PD 对应的 service GC safepoint 最终会停滞在该
任务的 checkpoint-ts 处不再更新。
如果该同步任务停滞的时间超过了 gc-ttl 指定的时长，那么该同步任务就会进入 failed 状态，并且无法被
恢复，PD 对应的 service GC safepoint 就会继续推进。
TiCDC 为 service GC safepoint 设置的存活有效期为 24 小时，即 TiCDC 服务中断 24 小时内恢复能保证数据不因 GC
而丢失。
10.11.4.7 如何处理 TiCDC 创建同步任务或同步到 MySQL 时遇到 Error 1298: Unknown or incorrect time
zone: 'UTC' 错误？
928这是因为下游 MySQL 没有加载时区，可以通过 mysql_tzinfo_to_sql 命令加载时区，加载后就可以正常创建任务
或同步任务。
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql -p
显示类似于下面的输出则表示导入已经成功：
Enter password:
Warning: Unable to load '/usr/share/zoneinfo/iso3166.tab' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/leap-seconds.list' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/zone.tab' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/zone1970.tab' as time zone. Skipping it.
如果下游是特殊的 MySQL 环境（某种公有云 RDS 或某些 MySQL 衍生版本等），使用上述方式导入时区失败，就
需要通过 sink-uri 中的 time-zone 参数指定下游的 MySQL 时区。可以首先在 MySQL 中查询其使用的时区：
show variables like '%time_zone%';
+------------------+--------+
| Variable_name | Value |
+------------------+--------+
| system_time_zone | CST |
| time_zone
| SYSTEM |
+------------------+--------+
然后在创建同步任务和创建 TiCDC 服务时使用该时区：
cdc cli changefeed create --sink-uri="mysql://root@127.0.0.1:3306/?time-zone=CST" --pd=http
, → ://10.0.10.25:2379
注意：
CST 可能是以下四个不同时区的缩写：
• 美国中部时间：Central Standard Time (USA) UT-6:00
• 澳大利亚中部时间：Central Standard Time (Australia) UT+9:30
• 中国标准时间：China Standard Time UT+8:00
• 古巴标准时间：Cuba Standard Time UT-4:00
在中国，CST 通常表示中国标准时间，使用时请注意甄别。
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
