第六部分 数据备份及数据迁移
一、TiDB Data Migration (DM)安装部署
TiDB Data Migration (DM) 是一款便捷的数据迁移工具，支持从与 MySQL 协议兼容的数据库（MySQL、MariaDB、Aurora MySQL）到 TiDB 的全量数据迁移和增量数据同步。
1.解压DM包
在TOOLS的文件夹中，找到dm-master-v6.5.2-linux-amd64.tar.gz包，解压到本地
# tar zxvf dm-master-v6.5.2-linux-amd64.tar.gz
2.配置文件
编写安装配置拓扑文件
# vim dmtopo.yaml
编辑如下内容，注意格式，这里测试时只用单节点来部署。
注意事项：要和TIDB的数据库拓扑IP区分开，否则会造成TIDB集群的granafa和dashboard监控因IP冲突而导致访问失效。
---
global:
user: "tidb"
ssh_port: 22
deploy_dir: "/home/tidb/dm/deploy"
data_dir: "/home/tidb/dm/data"
# arch: "amd64"
master_servers:
- host: 21.72.124.42
worker_servers:
- host: 21.72.124.42
monitoring_servers:
- host: 21.72.124.42
grafana_servers:
- host: 21.72.124.42
alertmanager_servers:
- host: 21.72.124.42
3.安装
安装DM组件
# tiup dm deploy dm-test v6.5.2 ./dmtopo.yaml --user tidb
4.查看状态
# tiup dm display dm-test
二、DM任务设置
1.配置数据源
（1）加密数据源密码
# tiup dmctl encrypt 'abc!@#123'
（2）编写数据源配置文件
source-id: "mysql-01" # 数据源 ID，在数据迁移任务配置和 dmctl 命令行中引用该 source-id 可以关联到对应的数据源
from:
host: "127.0.0.1"
port: 3306
user: "root"
password: "MKxn0Qo3m3XOyjCnhEMtsUCm83EhGQDZ/T4=" # 推荐使用 dmctl 对上游数据源的用户密码加密之后的密码
security: # 上游数据源 TLS 相关配置。如果没有需要则可以删除
ssl-ca: "/path/to/ca.pem"
ssl-cert: "/path/to/cert.pem"
ssl-key: "/path/to/key.pem"
2.创建数据源
# tiup dmctl --master-addr 21.72.124.42:8261 operate-source create
source-mysql-01.yaml
3.配置任务
# vim dm-task.yaml
#注意文件格式
name: testdm
task-mode: all
target-database:
host: "127.0.0.1"
port: 4000
user: "root"
password: "" # 如果密码不为空，则推荐使用经过 dmctl 加密的密文
# 填写一个或多个所需同步的数据源信息
mysql-instances:
- source-id: "mysql-01"
block-allow-list: "ba-rule1"
block-allow-list:
ba-rule1:
do-dbs: ["testdm"]
任务配置文件分为以下几部分：
# 全局配置
## 基本信息配置
## 功能配置集
# 实例配置
完整配置文件实例请参考https://docs.pingcap.com/zh/tidb/v6.5/task-configuration-file-full
4.创建数据迁移任务
# tiup dmctl --master-addr 127.0.0.1:8261 start-task testdm-task.yaml
结果如下：
tiup is checking updates for component dmctl ...
Starting component `dmctl`: /root/.tiup/components/dmctl/v7.3.0/dmctl/dmctl --master-addr 127.0.0.1:8261 start-task testdm-task.yaml
{
"result": true,
"msg": "",
"sources": [
{
"result": true,
"msg": "",
"source": "mysql-01",
"worker": "dm-192.168.80.201-8262"
}
],
"checkResult": "pre-check is passed. "
}
5.任务相关
（1）查询状态
query-status
示例：
# tiup dmctl --master-addr 127.0.0.1:8261 query-status testdm
（2）暂停任务
pause-task [-s "mysql-replica-01"] task-name
示例：
# tiup dmctl --master-addr 127.0.0.1:8261 pause-task testdm
（3）恢复任务
resume-task [-s "mysql-replica-01"] task-name
示例：
# tiup dmctl --master-addr 127.0.0.1:8261 resume-task testdm
（4）停止任务
stop-task [-s "mysql-replica-01"] task-name
示例：
# tiup dmctl --master-addr 127.0.0.1:8261 stop-task testdm
6.非常规数据迁移
（1）分库分表数据迁移
（2）上下游列数量不一致
（3）增量数据校验、迁移
三、Dumpling数据导出工具
使用数据导出工具 Dumpling，你可以把存储在 TiDB 或 MySQL 中的数据导出为 SQL 或 CSV 格式，用于逻辑全量备份。
1.安装Dumpling
[tidb@localhost] #cd /home/tidb_install/tidb-enterprise-server-v6.5.2-linux-amd64
[tidb@localhost] #tar -zxvf dumpling-v6.5.2-linux-amd64.tar.gz
会解压出一个dumpling文件
2.导出数据
导出某库到本地文件夹语句如下：
[tidb@localhost]#tiup dumpling -uroot -P13390 -h21.72.124.42 -o /home/dump -B P6ODS
参数解释：
-u 导出数据库的用户名
-P 导出数据库的端口号
-h 导出数据库的IP地址
-o 要导入的文件夹，需有相应权限
-B 导出的数据库名称schema
3.Dumpling 主要选项表
-V 或 --version |
输出 Dumpling 版本并直接退出 |
-B 或 --database |
导出指定数据库 |
-T 或 --tables-list |
导出指定数据表 |
-f 或 --filter |
导出能匹配模式的表，语法可参考 table-filter |
--case-sensitive |
table-filter 是否大小写敏感 |
-h 或 --host |
连接的数据库主机的地址 |
-t 或 --threads |
备份并发线程数 |
-r 或 --rows |
用于开启表内并发加速导出。默认值是 0，表示不开启。取值大于 0 表示开启，取值是 INT 类型。当数据源为 TiDB 时，设置 -r 参数大于 0 表示使用 TiDB region 信息划分区间，同时减少内存使用。具体取值不影响划分算法。对数据源为 MySQL 且表的主键是 INT 的场景，该参数也有表内并发效果。 |
-L 或 --logfile |
日志输出地址，为空时会输出到控制台 |
--loglevel |
日志级别 {debug,info,warn,error,dpanic,panic,fatal} |
--logfmt |
日志输出格式 {text,json} |
-d 或 --no-data |
不导出数据，适用于只导出 schema 场景 |
--no-header |
导出 csv 格式的 table 数据，不生成 header |
-W 或 --no-views |
不导出 view |
-m 或 --no-schemas |
不导出 schema，只导出数据 |
-s 或--statement-size |
控制 INSERT SQL 语句的大小，单位 bytes |
-F 或 --filesize |
将 table 数据划分出来的文件大小，需指明单位（如 128B, 64KiB, 32MiB, 1.5GiB） |
--filetype |
导出文件类型（csv/sql） |
-o 或 --output |
导出本地文件路径或外部存储 URL 格式 |
-S 或 --sql |
根据指定的 sql 导出数据，该选项不支持并发导出 |
--consistency |
flush: dump 前用 FTWRLsnapshot: 通过 TSO 来指定 dump 某个快照时间点的 TiDB 数据lock: 对需要 dump 的所有表执行 lock tables read 命令none: 不加锁 dump，无法保证一致性auto: 对 MySQL 使用 --consistency flush；对 TiDB 使用 --consistency snapshot |
--snapshot |
snapshot tso，只在 consistency=snapshot 下生效 |
--where |
对备份的数据表通过 where 条件指定范围 |
-p 或 --password |
连接的数据库主机的密码 |
-P 或 --port |
连接的数据库主机的端口 |
-u 或 --user |
连接的数据库主机的用户名 |
--dump-empty-database |
导出空数据库的建库语句 |
--ca |
用于 TLS 连接的 certificate authority 文件的地址 |
--cert |
用于 TLS 连接的 client certificate 文件的地址 |
--key |
用于 TLS 连接的 client private key 文件的地址 |
--csv-delimiter |
csv 文件中字符类型变量的定界符 |
--csv-separator |
csv 文件中各值的分隔符，如果数据中可能有逗号，建议源文件导出时分隔符使用非常见组合字符 |
--csv-null-value |
csv 文件空值的表示 |
--escape-backslash |
使用反斜杠 (\) 来转义导出文件中的特殊字符 |
--output-filename-template |
以 golang template 格式表示的数据文件名格式支持 {{.DB}}、{{.Table}}、{{.Index}} 三个参数分别表示数据文件的库名、表名、分块 ID |
--status-addr |
Dumpling 的服务地址，包含了 Prometheus 拉取 metrics 信息及 pprof 调试的地址 |
--tidb-mem-quota-query |
单条 dumpling 命令导出 SQL 语句的内存限制，单位为 byte。对于 v4.0.10 或以上版本，若不设置该参数，默认使用 TiDB 中的 mem-quota-query 配置项值作为内存限制值。对于 v4.0.10 以下版本，该参数值默认为 32 GB |
--params |
为需导出的数据库连接指定 session 变量，可接受的格式: "character_set_client=latin1,character_set_connection=latin1" |
-c 或 --compress |
压缩 Dumpling 导出的 CSV、SQL 数据与表结构文件为指定格式，支持 "gzip"、"snappy" 和 "zstd" 压缩算法 |
四、TiDB Lightning数据导入工具
TiDB Lightning 是用于从静态文件导入 TB 级数据到 TiDB 集群的工具，常用于 TiDB 集群的初始化数据导入。
1.安装部署
下载 TiDB Lightning 安装包
解压 Lightning 压缩包即可获得 tidb-lightning 可执行文件。
tar -zxvf tidb-lightning-${version}-linux-amd64.tar.gz
chmod +x tidb-lightning
2.导入前准备
（1）检查目标数据库
|
特性 |
作用域 |
所需权限 |
备注 |
必需 |
基本功能 |
目标 table |
CREATE,SELECT,INSERT,UPDATE,DELETE,DROP,ALTER |
DROP 仅 tidb-lightning-ctl 在执行 checkpoint-destroy-all 时需要 |
目标 database |
CREATE |
|
||
必需 |
Logical Import Mode |
information_schema.columns |
SELECT |
|
Physical Import Mode |
mysql.tidb |
SELECT |
|
|
- |
SUPER |
|
||
- |
RESTRICTED_VARIABLES_ADMIN,RESTRICTED_TABLES_ADMIN |
当目标 TiDB 开启 SEM |
||
推荐 |
冲突检测，max-error |
lightning.task-info-schema-name 配置的 schema |
SELECT,INSERT,UPDATE,DELETE,CREATE,DROP |
如不需要，该值必须设为"" |
可选 |
并行导入 |
lightning.meta-schema-name 配置的 schema |
SELECT,INSERT,UPDATE,DELETE,CREATE,DROP |
如不需要，该值必须设为"" |
可选 |
checkpoint.driver = "mysql" |
checkpoint.schema 设置 |
SELECT,INSERT,UPDATE,DELETE,CREATE,DROP |
使用数据库而非文件形式存放 checkpoint 信息时需要 |
（2）目标数据库所需空间
目标 TiKV 集群必须有足够空间接收新导入的数据。除了标准硬件配置以外，目标 TiKV 集群的总存储空间必须大于 数据源大小 × 副本数量 × 2。例如集群默认使用 3 副本，那么总存储空间需为数据源大小的 6 倍以上。公式中的 2 倍可能难以理解，其依据是以下因素的估算空间占用：
索引会占据额外的空间
RocksDB 的空间放大效应
目前无法精确计算 Dumpling 从 MySQL 导出的数据大小，但你可以用下面 SQL 语句统计信息表的 data_length 字段估算数据量：
统计所有 schema 大小，单位 MiB，注意修改 ${schema_name}
SELECT table_schema, SUM(data_length)/1024/1024 AS data_length, SUM(index_length)/1024/1024 AS index_length, SUM(data_length+index_length)/1024/1024 AS sum FROM information_schema.tables WHERE table_schema = "${schema_name}" GROUP BY table_schema;
统计最大单表，单位 MiB，注意修改 ${schema_name}
SELECT table_name, table_schema, SUM(data_length)/1024/1024 AS data_length, SUM(index_length)/1024/1024 AS index_length, SUM(data_length+index_length)/1024/1024 AS sum FROM information_schema.tables WHERE table_schema = "${schema_name}" GROUP BY table_name,table_schema ORDER BY sum DESC LIMIT 5;
3.数据源
TiDB Lightning 支持从多种类型的文件导入数据到 TiDB 集群。
通过以下配置为 TiDB Lightning 指定数据文件所在位置。
[mydumper]
# 本地源数据目录或 S3 等外部存储 URL
data-source-dir = "/data/my_database"
TiDB Lightning 运行时将查找 data-source-dir 中所有符合命令规则的文件。
数据源命名规则如下：
${db_name}.${table_name}-schema.sql
${db_name}-schema-create.sql
${db_name}.${table_name}.${csv|sql|parquet}
${db_name}.${table_name}.001.${csv|sql|parquet}
${db_name}.${table_name}.${csv|sql|parquet}.{compress}
CSV格式的数据
CSV 格式可在 tidb-lightning.toml 文件中 [mydumper.csv] 下配置。大部分设置项在 MySQL [LOAD DATA] 语句中都有对应的项目。
SQL格式的数据
TiDB Lightning 在处理 SQL 文件时，由于无法对单个文件进行快速分割，因此无法通过增加并发提高单个文件的导入速度。鉴于此，导出数据为 SQL 文件时应尽量避免单个 SQL 文件过大，通常单文件在 256MiB 左右可以达到最佳性能。
4.导入模式
（1）Physical Import Mode
Physical Import Mode 不经过 SQL 接口，而是直接将数据以键值对的形式插入 TiKV 节点，是一种高效、快速的导入模式。使用 Physical Import Mode 时，单个 Lightning 实例可导入的数据量为 10 TiB
Physical Import Mode 对应的后端模式为 local。
使用限制：
▪TiDB Lightning 不支持导入数据到已有业务写入的数据表；
▪请勿直接使用 Physical Import Mode 向已经投入生产的 TiDB 集群导入数据，这将对在线业务产生严重影响；
▪不应同时启动多个 TiDB Lightning 实例向同一 TiDB 集群导入数据，而应考虑使用并行导入特性。
▪不可同时使用 Physical Import Mode 和 Logical Import Mode 导入同一 TiDB 集群。
▪导入数据的过程中，请勿在目标表进行 DDL 和 DML 操作，否则会导致导入失败或数据不一致。
▪单个 TiDB Lightning 进程导入单表不应超过 10 TB。
（2）Logical Import Mode
在 Logical Import Mode 下，TiDB Lightning 先将数据编码成 SQL，然后直接运行这些 SQL 语句进行数据导入。对于已有数据、对外提供服务的 TiDB 集群，推荐使用 Logical Import Mode 导入数据。Logical Import Mode 的行为与正常执行 SQL 并无差异，可保证 ACID。
Logical Import Mode 对应的后端模式为 tidb。
使用限制：
▪不可同时使用 Physical Import Mode 和 Logical Import Mode 导入同一 TiDB 集群。
5.配置文件
（1）使用 Physical Import Mode的配置文件示例如下：
[lightning]
# 日志
level = "info"
file = "tidb-lightning.log"
max-size = 128 # MB
max-days = 28
max-backups = 14
# 启动之前检查集群是否满足最低需求。
check-requirements = true
[mydumper]
# 本地源数据目录或外部存储 URL
data-source-dir = "/data/my_database"
[tikv-importer]
# 导入模式配置，设为 local 即使用 Physical Import Mode
backend = "local"
# 冲突数据处理方式
duplicate-resolution = 'remove'
# 本地进行 KV 排序的路径。
sorted-kv-dir = "./some-dir"
# 限制 TiDB Lightning 向每个 TiKV 节点写入的带宽大小，默认为 0，表示不限制。
# store-write-bwlimit = "128MiB"
[tidb]
# 目标集群的信息。tidb-server 的地址，填一个即可。
host = "172.16.31.1"
port = 4000
user = "root"
# 设置连接 TiDB 的密码，可为明文或 Base64 编码。
password = ""
# 必须配置。表结构信息从 TiDB 的“status-port”获取。
status-port = 10080
# 必须配置。pd-server 的地址，填一个即可。
pd-addr = "172.16.31.4:2379"
# tidb-lightning 引用了 TiDB 库，并生成产生一些日志。
# 设置 TiDB 库的日志等级。
log-level = "error"
# 注意：
# 1. Checksum 对比失败通常表示导入异常（数据丢失或数据不一致），因此建议总是开启 Checksum。
# 2. 考虑到与旧版本的兼容性，依然可以在本配置项设置 `true` 和 `false` 两个布尔值，其效果与 `required` 和 `off` 相同。
checksum = "required"
# 配置是否在 CHECKSUM 结束后对所有表逐个执行 `ANALYZE TABLE <table>` 操作。
# 此配置的可选配置项与 `checksum` 相同，但默认值为 "optional"。
analyze = "optional"
（2）使用 Logical Import Mode的配置文件示例如下：
[lightning]
# 日志
level = "info"
file = "tidb-lightning.log"
max-size = 128 # MB
max-days = 28
max-backups = 14
# 启动之前检查集群是否满足最低需求。
check-requirements = true
[mydumper]
data-source-dir = "/data/my_database"
[tikv-importer]
# 导入模式配置，设为 tidb 即使用 Logical Import Mode
backend = "tidb"
# Logical Import Mode 插入重复数据时执行的操作。
# - replace：新数据替代已有数据
# - ignore：保留已有数据，忽略新数据
# - error：中止导入并报错
on-duplicate = "replace"
[tidb]
# 目标集群的信息。tidb-server 的地址，填一个即可。
host = "172.16.31.1"
port = 4000
user = "root"
# 设置连接 TiDB 的密码，可为明文或 Base64 编码。
password = ""
# tidb-lightning 引用了 TiDB 库，并生成产生一些日志。
# 设置 TiDB 库的日志等级。
log-level = "error"
6.其他功能
（1）断点续传
[checkpoint]
# 启用断点续传。
# 导入时，TiDB Lightning 会记录当前进度。
# 若 TiDB Lightning 或其他组件异常退出，在重启时可以避免重复再导入已完成的数据。
enable = true
# 存储断点的方式
# - file：存放在本地文件系统（要求 v2.1.1 或以上）
# - mysql：存放在兼容 MySQL 的数据库服务器
driver = "file"
# 存储断点的架构名称（数据库名称）
# 仅在 driver = "mysql" 时生效
# schema = "tidb_lightning_checkpoint"
# 断点的存放位置
# 若 driver = "file"，此参数为断点信息存放的文件路径。
# 如果不设置该参数则默认为 `/tmp/CHECKPOINT_SCHEMA.pb`
# 若 driver = "mysql"，此参数为数据库连接参数 (DSN)，格式为“用户:密码@tcp(地址:端口)/”。
# 默认会重用 [tidb] 设置目标数据库来存储断点。
# 为避免加重目标集群的压力，建议另外使用一个兼容 MySQL 的数据库服务器。
# dsn = "/tmp/tidb_lightning_checkpoint.pb"
# 导入成功后是否保留断点。默认为删除。
# 保留断点可用于调试，但有可能泄漏数据源的元数据。
# keep-after-success = false
（2）断点续传的控制
--checkpoint-error-destroy
该命令会让失败的表从头开始整个导入过程.
示例：tidb-lightning-ctl --checkpoint-error-destroy='`schema`.`table`'
tidb-lightning-ctl --checkpoint-error-destroy=all
--checkpoint-error-ignore
这条命令会清除出错状态
示例：tidb-lightning-ctl --checkpoint-error-ignore='`schema`.`table`'
tidb-lightning-ctl --checkpoint-error-ignore=all
--checkpoint-remove
无论是否有出错，把表的断点清除。
示例：tidb-lightning-ctl --checkpoint-remove='`schema`.`table`'
tidb-lightning-ctl --checkpoint-remove=all
--checkpoint-dump
将所有断点备份到传入的文件夹，主要用于技术支持。此选项仅于 driver = "mysql" 时有效。
示例：tidb-lightning-ctl --checkpoint-dump=output/directory
（3）并行导入
通过支持同步启动多个实例，并行导入不同的单表或多表的不同数据，使 TiDB Lightning 具备水平扩展的能力，可大大降低导入大量数据所需的时间。
注意
▪并行导入只支持初始化 TiDB 的空表，不支持导入数据到已有业务写入的数据表，否则可能会导致数据不一致的情况。
▪并行导入一般用于Physical Import模式，需要设置 incremental-import = true
▪并行导入一般用于Physical Import模式；虽然也能用于 Logical Import 模式，但是一般不会带来明显的性能提升。
使用 TiDB Lightning 并行导入需要设置 incremental-import = true。TiDB Lightning 在启动时，会在下游 TiDB 中注册元信息，并自动检测是否有其他实例向目标集群导入数据。如果有，则自动进入并行导入模式。
使用限制
TiDB Lightning 在运行时，需要独占部分资源，因此如果需要在单台机器上面部署多个 TiDB Lightning 实例(不建议生产环境使用)或多台机器共享磁盘存储时，需要注意如下使用限制：
每个 TiDB Lightning 实例的 tikv-importer.sorted-kv-dir 必须设置为不同的路径。多个实例共享相同的路径会导致非预期的行为，可能导致导入失败或数据出错。
每个 TiDB Lightning 的 checkpoint 需要分开存储。checkpoint 的详细配置见 TiDB Lightning 断点续传。
如果设置 checkpoint.driver = "file"（默认值），需要确保每个实例设置的 checkpoint 的路径不同。
如果设置 checkpoint.driver = "mysql"，需要为每个实例设置不同的 schema。
每个 TiDB Lightning 的 log 文件应该设置为不同的路径。共享同一个 log 文件将不利于日志的查询和排查问题。
如果开启Web 界面或 Debug API，需要为每个实例的lightning.status-addr设置不同地址，否则，TiDB Lightning 进程会由于端口冲突无法启动。
五、TICDC
TiCDC 是一款 TiDB 增量数据同步工具，通过拉取上游 TiKV 的数据变更日志，TiCDC 可以将数据解析为有序的行级变更数据输出到下游。
1.部署
在使用 TiUP 部署全新 TiDB 集群时，支持同时部署 TiCDC 组件。你需要在 TiUP 启动 TiDB 集群时的配置文件中加入 TiCDC 相关的部分，以下是一个示例：
cdc_servers:
- host: 10.0.1.20
gc-ttl: 86400
data_dir: "/cdc-data"
- host: 10.0.1.21
gc-ttl: 86400
data_dir: "/cdc-data"
2.命令
使用 TiUP 可以方便地终止和启动 TiCDC 节点，命令如下：
终止 TiCDC 节点：tiup cluster stop -R cdc
启动 TiCDC 节点：tiup cluster start -R cdc
重启 TiCDC 节点：tiup cluster restart -R cdc
查看cdc集群运行状态
tiup ctl:v<CLUSTER_VERSION> cdc capture list --server=http://10.0.10.25:8300
3.同步任务
使用以下命令来创建同步任务：
cdc cli changefeed create \
--server=http://10.0.10.25:8300 \
--sink-uri="s3://logbucket/storage_test?protocol=canal-json" \
--changefeed-id="simple-replication-task"
参数解释：
--server：TiCDC 集群中任意一个 TiCDC 服务器的地址。
--changefeed-id：同步任务的 ID。格式需要符合正则表达式 ^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$。如果不指定该 ID，TiCDC 会自动生成一个 UUID（version 4 格式）作为 ID。
--sink-uri：同步任务下游的地址。具体可参考配置 Sink URI。
--start-ts：指定 changefeed 的开始 TSO。TiCDC 集群将从这个 TSO 开始拉取数据。默认为当前时间。
--target-ts：指定 changefeed 的目标 TSO。TiCDC 集群拉取数据直到这个 TSO 停止。默认为空，即 TiCDC 不会自动停止。
--config：指定 changefeed 配置文件
NFS 配置样例如下：
--sink-uri="file:///my-directory/prefix?protocol=canal-json"
六、TiDB Binlog
1.组件概念
TiDB Binlog 是一个用于收集 TiDB 的 binlog，并提供准实时备份和同步功能的商业工具。
TiDB Binlog 支持以下功能场景：
数据同步：同步 TiDB 集群数据到其他数据库
实时备份和恢复：备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复
TiDB Binlog 集群主要分为 Pump 和 Drainer 两个组件，以及 binlogctl 工具：
Pump
Pump 用于实时记录 TiDB 产生的 Binlog，并将 Binlog 按照事务的提交时间进行排序，再提供给 Drainer 进行消费。
Drainer
Drainer 从各个 Pump 中收集 Binlog 进行归并，再将 Binlog 转化成 SQL 或者指定格式的数据，最终同步到下游。
binlogctl 工具
binlogctl 是一个 TiDB Binlog 配套的运维工具，具有如下功能：
获取 TiDB 集群当前的 TSO
查看 Pump/Drainer 状态
修改 Pump/Drainer 状态
暂停/下线 Pump/Drainer
2.安装部署
（1）工具包
TiDB Binlog 安装包位于 TiDB 离线工具包中。解压后使用
pump-v6.5.2-linux-amd64.tar.gz
drainer-v6.5.2-linux-amd64.tar.gz
tar -zxvf pump-v6.5.2-linux-amd64.tar.gz
tar -zxvf drainer-v6.5.2-linux-amd64.tar.gz
（2）使用TIUP部署：
在TIDB的配置文件中，配置BINLOG
场景 |
配置任务 |
配置文件模板 |
拓扑说明 |
使用 TiDB Binlog 进行增量同步 |
简单 TiDB Binlog 配置模板（下游为 MySQL）简单 TiDB Binlog 配置模板（下游为 file）详细 TiDB Binlog 配置模板 |
在最小拓扑的基础上部署 TiDB Binlog。 |
参考配置如下：
server_configs:
tidb:
binlog.enable: true
binlog.ignore-error: true
pump_servers:
- host: 10.0.1.1
- host: 10.0.1.2
- host: 10.0.1.3
drainer_servers:
- host: 10.0.1.12
# drainer meta data directory path
data_dir: "/path/to/save/data"
config:
syncer.db-type: "file"
# directory to save binlog file, default same as data-dir(save checkpoint file) if this is not configured.
# syncer.to.dir: "/path/to/save/binlog"
详细配置请参考（github网站访问不稳定，可使用加速工具，如Watt Toolkit）：
https://github.com/pingcap/docs-cn/blob/master/config-templates/complex-tidb-binlog.yaml
3.配置使用
Pump/Drainer 的使用
Pump/Drainer 中状态的定义：
online：正常运行中
pausing：暂停中
paused：已暂停
closing：下线中
offline：已下线
第七部分 其他工具部署
一、HAproxy的安装部署
1.依赖包和安装包下载
依赖包：epel-release gcc systemd-devel
cpp.x86_64 0:4.8.5-44.el7
glibc-devel.x86_64 0:2.17-326.el7_9
glibc-headers.x86_64 0:2.17-326.el7_9
kernel-headers.x86_64 0:3.10.0-1160.71.1.el7
libmpc.x86_64 0:1.0.1-3.el7
mpfr.x86_64 0:3.1.1-4.el7
gcc-4.8.5-44.el7.x86_64.rpm
以上依赖包的附属依赖包太多，所以此处只下载以上依赖包，强制安装
# rpm -ivh *.rpm --force --nodeps
2.HAproxy下载
https://github.com/haproxy/haproxy/archive/refs/tags/v2.5.0.zip
此处下载2.5版本的zip包
安装
解压zip包，进入对应文件夹目录，编译，安装，配置
前提make和make cc可用
# cd haproxy-2.5.0
# make clean
# make -j 8 TARGET=linux-glibc USE_THREAD=1
# make PREFIX=/usr/local/haproxy_v2.5.0 SBINDIR=/usr/local/haproxy_v2.5.0/bin install
# ln -s /usr/local/haproxy_v2.5.0 /usr/local/haproxy
# echo 'export PATH=/usr/local/haproxy/bin:$PATH' >> /etc/profile
# source /etc/profile
# which haproxy
/usr/local/haproxy/bin/haproxy
3.部署
编辑haproxy.cfg文件，离线安装在解压包下目录examples里不会自动生成haproxy.cfg文件，需自行创建。
haproxy.cfg配置文件按照TIDB官方文档配置
注意：以下的全局部署中的/var/lib/haproxy文件夹如过启动时报错，需手动创建，按报错提示信息进行处理。
global
log 127.0.0.1 local1
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4096
nbthread 48
user haproxy
group haproxy
daemon
stats socket /var/lib/haproxy/stats
defaults
log global
retries 2
timeout connect 2s
timeout client 30000s
timeout server 30000s
listen admin_stats
bind 0.0.0.0:8080
mode http
option httplog
maxconn 10
stats refresh 30s
stats uri /haproxy
stats realm HAProxy
stats auth admin:admin
stats hide-version
stats admin if TRUE
listen tidb-cluster
bind 0.0.0.0:13390
mode tcp
balance leastconn
server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3 server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3
server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3
4.启动
# /usr/local/haproxy/bin/haproxy -f haproxy.cfg
设置开机自启动
~]# cp /root/haproxy-2.5.0/examples/haproxy.init /etc/init.d/haproxy
~]# chmod +x /etc/init.d/haproxy
~]# ln -s /usr/local/haproxy/bin/haproxy /usr/sbin/
~]# chkconfig --add haproxy
~]# chkconfig haproxy on
~]# systemctl enable haproxy
5.手动启动
~]# systemctl restart haproxy
~]# systemctl status haproxy
~]# systemctl start haproxy
~]# systemctl stop haproxy
6.配置负载
（1）配置tidb文件
TiDB侧配置文件加入proxy协议
需要配置使用 PROXY 协议连接 TiDB，配置后单节点tidb将无法直接登录
[tidb@tidb1]# tiup cluster edit-config tidb
在server_configs>>tidb中加入如下内容
server_configs:
tidb:
proxy-protocol.networks:21.72.124.42
其中，21.72.124.42为HAproxy安装地址。
配置完成后，重启tidb节点，检测是否生效
（2）重启tidb节点
重启：
tiup cluster restart tidb -R tidb或者
tiup cluster restart tidb -N 21.72.124.38:4000,21.72.124.45:4000
其中，-R代表需要重启的角色，-N代表需要重启的节点
（3）检验负载均衡
检测是否生效：
[tidb@tidb2 tidb]# mysql -uroot -h21.72.124.42 -P 13390 -e "select @@hostname;"
+------------+
| @@hostname |
+------------+
| tidb2 |
+------------+
[tidb@tidb2 tidb]# mysql -uroot -h21.72.124.42 -P 13390 -e "select @@hostname;"
+------------+
| @@hostname |
+------------+
| tidb3 |
+------------+
前提是修改各tidb节点的hostname
使用root登录各tidb节点,
# hostnamectl set-hostname tidb1
第八部分 QA
一、DM安装时导致grafan等组件失效
1.【复现路径】
主控机上安装了tidb的alertmanager\grafana\prometheus组件，运行正常，页面运行正常，今天，在主控机上安装DM时，配置安装文件时将DM的alertmanager\grafana\prometheus组件和tidb的IP:PORT写成一样的了，安装DM完成后发现不对，查询tidb集群的上述组件状态正常，于是使用tiup dm destory dm删除了dm，再次查询TIDB的组件，已经Down了。
2.【遇到的问题：问题现象及影响】
组件Down了以后，尝试tiup start tidb -R grafana和tiup satrt tidb -N ip:port,均无法启动起来，报错如下：
Error: Failed to start alertmanger:failed to start :21.72.124.43 alertmanager-9093,service,please check the instance’s log(/tidb-deploy/alertmanager-9093/log) for more detail,:excutor.ssh.execute_failed:Failed to execute command over SSH for ‘tidb@21.72.124.43:22’ {ssh_stderr:Failed to start alertmanger-9093.server: Unit not found.,ssh_stdout: , ssh_command: export LANG=C; PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin /usr/bin/sudo -H bash -c “systemctl deamon-reload && systemctl start alertmanager-9093.service”},cause:Process exited with status 5
有业务和数据在跑，所以我没法删除TIDB集群重建，也没办法停TIDB其他模块。
3.【问题处理过程】
考虑到数据库正在运行，且其他模块正常运行，想尝试重新安装down掉的组件，安装时提示端口已被占用，于是，准备先下线Down掉的组件再重新安装，成功恢复了组件和页面状态。
组件ID
grafana组件 21.72.124.43:3000
altermanager组件 21.72.124.43:9093
prometheus组件 21.72.124.43:9090
下线处理：
# tiup cluster scale-in tidb -N 21.72.124.43:3000
# tiup cluster scale-in tidb -N 21.72.124.43:9093
# tiup cluster scale-in tidb -N 21.72.124.43:9090
观察状态
# tiup cluster display tidb
编辑yaml文件
vim grafana-scaleout.yaml
monitoring_servers:
- host: 21.72.124.43
grafana_servers:
- host: 21.72.124.43
alertmanager_servers:
- host: 21.72.124.43
重新安装上线
# tiup cluster scale-out tidb grafana-scaleout.yaml
检查状态&登录grafana和Dashboard页面
# tiup cluster display tidb
状态正常，页面正常（需等待一分钟左右刷新数据）
4.【处理过程错误】
重新安装上线 scale-out 时，报错，根据报错提示显示，ssh互信失败，需重新配置互信，再执行扩容，一切正常
PS:DM安装过程中，执行的语句里有用户名密码，估计在安装中使上述三个组件模块的互信失效。
可能不需要下线重装组件，只需重新配置互信后，start一下可能就会正常，此方法暂未测试。
二、TiKV节点下线速度满
1.【复现路径】
由于业务原因，需重新分配数据盘目录，操作思路：4个TiKV节点每两个下线，重新写好配置文件，重新上线。
2.【遇到的问题：问题现象及影响】
同时下线2个KV节点
# tiup cluster scale-in tidb --node 21.72.124.40:20160
# tiup cluster scale-in tidb --node 21.72.124.50:20160
命令开始执行后，观察上述节点日志和pd、tidb日志，发现GC在给PD节点任务后，两个KV节点均未马上有日志产生，约10分钟后，KV日志报错，大概意思为要执行数据迁移到其他节点，但未连接到PD节点，使用命令tiup cluster display tidb观察，两KV节点一直处于OFFLINE状态，前台面板观察TIKV storge状态也未发生变化，此状态持续约2小时
3.【问题处理过程】
思路：是否因为同时执行了2个节点下线任务，导致GC任务繁重，决定先恢复其中一个TIKV节点，然后修改GC检查时间，等待下线。
以下为操作流程：
1.处于offline状态的节点未成为tombstone前可以通过以下命令终止其下线过程(需在PD所在节点执行)，使tikv重新成为UP状态，不适用已经删除tikv 数据目录或宕机的情况，部分情况该tikv可能需要重启。
终止下线：
curl -X POST http://pd_ip:pd_port/pd/api/v1/store/{store_id}/state\?state=Up
2. 通过pd-ctl config set 命令可以增大leader-schedule-limit、replica-schedule-limit、region-schedule-limit等参数增加leader/region的调度速度，加快下线过程，上述命令是用于控制PD侧调度命令的产生速度，实际的执行还收tikv侧的消费速度限制，通过pd-ctl store limit <store_id> <limit> 增加消费速度。
3. 再次观察下线过程
调整完的下线任务只剩一个节点，观察KV日志和PD日志，开始正常跑下线流程了，大约5分钟，下线完成，继续下线其他节点，约2-5分钟不等。
4.【总结】
(1)系统部署时对于单机多tikv的情况一定要打上label标签，保障同一服务器上不同的tikv实例在isolation-level具有相同的label，避免将相同region的多个副本调度到同一服务器，从而因服务器故障造成多副本丢失。
(2)缩容tikv时应尽量提前进行leader/region转移，使缩容过程更加可控。
(3)缩容时、store处于offline状态时禁止使用--force参数，仅对宕机无法修复、数据目录被删除的场景使用。
(4)缩容多个tikv时要尽量一个一个的进行处理，避免一次下线多个时出现问题，尤其是同一服务器上的多个tikv。
(5)缩容时要保障其他的tikv节点有足够的磁盘空间接收转移的region。
(6)如果允许尽量使用高版本数据量。
(7)做完多副本失败恢复后要检查数据是否一致。
(8)注意使用tikv-ctl等工具时要不同的版本会有不一样的参数，如--db或--data-dir。