关于tidb:技术分享-TiDB-上百T数据拆分实践

作者：杨家鑫

多点⾼级 DBA，擅⻓故障剖析与性能优化，喜爱摸索新技术，喜好摄影。

本文起源：原创投稿

* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。

提⾼ TiDB 可⽤性，须要把多点已有上百 T TiDB 集群拆分出 2 套

现有须要拆分的 12 套 TiDB 集群的版本多(4.0.9、5.1.1、5.1.2 都有)，每个版本拆分⽅法存在不⼀样
其中 5 套 TiDB，数据量均超过 10T、最⼤的 TiDB 集群⽬前数据量 62T、单 TiDB 集群备份集⼤，耗费⼤量磁盘空间和带宽资源

空间最⼤ 3 套集群

tidb 使⽤⽅式多样（每种⽅式拆分⽅法不同），有间接读写 tidb，也有 mysql->tidb 汇总剖析查问，也有 tidb->cdc-> 上游 hive
全量备份 TiDB 在业务⾼峰期是否会产⽣性能影响
⼤数据量的拆分数据的⼀致性保障

⽬前 TiDB 官⽅提供的同步⼯具备：

DM 全量 + 增量（该⽅法⽆法⽤于 tidb->tidb，适⽤于 MySQL->TiDB）
BR 全量物理备份 +CDC 增量同步（CDC 同步在 tidb、tikv 节点 OOM 后修复老本⾼ https://github.co m/pingcap/tiflow/issues/3061）
BR 全量物理备份 +binlog 增量（相似于 MySQL 记录所有变更的 binlog ⽇志，TiDB binlog 由 Pump(记录变更⽇志)+Drainer(回放变更⽇志)组成，咱们采⽤该⽅法进⾏全量 + 增量同步拆分）

备份与复原⼯具 BR：https://docs.pingcap.com/zh/t…

TiDB Binlog：https://docs.pingcap.com/zh/t…

1、清理现有 TiDB 集群⽆⽤数据

按⽉分表 tidb 库有⽆⽤的表，如 3 个⽉前的 xxxx ⽇志表

2、降级 GZ 现有 15 套 TiDB 集群（12 套 TiDB 集群须要 1 分为 2）版本⾄ 5.1.2

趁这次拆分统⼀ GZ tidb 版本，解决挑战 1

1、新机器部署好雷同版本 5.1.2TiDB 集群

set @@global.tidb_analyze_version = 1;

2、⽬的端，源端所有 tikv tiflash 挂载好 NFS，pd 节点上装置好 BR

Exteral storge 采⽤腾讯云 NFS ⽹盘，保障 tikv 备份⽬的端和还原全量起源端都能在同⼀⽬录，NFS ⽹盘空间⾃动动静减少 + 限速备份以应答挑战 2

3、独⽴ 3 台机器部署好 12 套 TiDB 集群

pump 收集 binlog(端⼝辨别不同 TiDB 集群) pump，drainer 采⽤独⽴ 16C, 32G 机器保障增量同步最⼤性能

留神：为保障 tidb 计算节点的可⽤性，需设置 ignore-error binlog要害参数（https://docs.pingcap.com/zh/t…）

server_configs: 
  tidb: 
    binlog.enable: true 
    binlog.ignore-error: true

4、批改 pump 组件 GC 工夫为 7 天

binlog 保留 7 天保障全量备份 -> 到增量同步过程能接上

pump_servers: 
  - host: xxxxx 
    config: 
      gc: 7 
#需 reload 重启 tidb 节点使记录 binlog ⽣效

5、备份 TiDB 集群全量数据⾄ NFS Backup & Restore 常⻅问题（https://docs.pingcap.com/zh/t…）

留神：每个 TiDB 集群在同⼀个 NFS 建不同备份⽬录

留神：源⽼ TiDB 集群别离限速 (备份前后对读写延迟时间根本⽆影响) 进⾏错峰全量备份 (存在之前多个 TiDB 集群同时备份把 NFS 3Gbps ⽹络带宽打满状况) 以加重对现有 TiDB 读写、NFS 的压⼒以应对挑战

mkdir -p /tidbbr/0110_dfp 
chown -R tidb.tidb /tidbbr/0110_dfp 
#限速进⾏全业务应⽤库备份
./br backup full \ 
     --pd "xxxx:2379" \ 
     --storage "local:///tidbbr/0110_dfp" \ 
     --ratelimit 80 \ 
     --log-file /data/dbatemp/0110_backupdfp.log 
#限速进⾏指定库备份 
 ./br backup db \ 
   --pd "xxxx:2379" \ 
   --db db_name \ 
   --storage "local:///tidbbr/0110_dfp" \ 
   --ratelimit 80 \ 
   --log-file /data/dbatemp/0110_backupdfp.log 
   
12.30 号 45T TiDB 集群全量备份耗时 19h，占⽤空间 12T 
[2021/12/30 09:33:23.768 +08:00] [INFO] [collector.go:66] ["Full backup succes s summary"] [total-ranges=1596156] [ranges-succeed=1596156] [ranges-failed=0] [backup-checksum=3h55m39.743147403s] [backup-fast-checksum=409.352223ms] [bac kup-total-ranges=3137] [total-take=19h12m22.227906678s] [total-kv-size=65.13T B] [average-speed=941.9MB/s] ["backup data size(after compressed)"=12.46TB] [B ackupTS=430115090997182553] [total-kv=337461300978]

6、每个新建 TiDB 集群独自同步⽼ TiDB 集群⽤⼾明码信息

留神：BR 全量备份不备份 tidb mysql 零碎库，应⽤、管理员⽤⼾明码信息可⽤开源 pt-toolkit ⼯具包 pt-show-grants 导出

7、复原 NFS 全量备份⾄新 TiDB 集群

留神：新 TiDB 集群磁盘空间需富余，全量备份还原后新 TiDB 集群占⽤空间⽐⽼ TiDB 集群多⼏个 T，和官⽅⼈员沟通是因为还原时⽣成 sst 的算法是 lz4，导致压缩率没有⽼ TiDB 集群⾼

留神：tidb_enable_clustered_index，sql_mode 新⽼ TiDB 集群这 2 参数必须⼀致

8、tiup 扩容 drainer 进⾏增量同步

扩容前确认上游 checkpoint 信息不存在或已清理

如果上游之前接过 drainer，相干位点在⽬标端 tidb_binlog.checkpoint 表中，重做的时候须要清理

留神：因源最⼤ TiDB 集群⻓期均匀写⼊ TPS 在 6k 左右，在增⼤ worker-count 回放线程数后，只管⽬的端域名解析到 3 个 tidb 节点，单个 drainer 增量还是⽆法追上提早（回放速度最⾼在 3k TPS），后和 TiDB 官⽅沟通改成按 3 个 drainer（不同 drainer 同步不同库名）并⾏增量同步提早追上（3 个 drainer 增量让“漏⽃”没有沉积，源流⼊端数据能及时达到⽬标流出端）

留神：多个 drainer 并⾏增量必须指定⽬的端 checkpoint.schema 为不同库 drainer 配置阐明


#从备份⽂件中获取全量备份开始时的位点 TSO
grep "BackupTS=" /data/dbatemp/0110_backupdfp.log 
430388153465177629 
#第⼀次⼀个 drainer 进⾏增量同步要害配置
drainer_servers: 
- host: xxxxxx 
commit_ts: 430388153465177629 
deploy_dir: "/data/tidb-deploy/drainer-8249" 
config: 
syncer.db-type: "tidb" 
syncer.to.host: "xxxdmall.db.com" 
syncer.worker-count: 550 1516


#第⼆次多个 drainer 进⾏并⾏增量同步
drainer_servers: 
- host: xxxxxx 
commit_ts: 430505424238936397 #该位点 TSO 为从第⼀次 1 个 drainer 增量停⽌后⽬的端 ch eckpoint 表中的 Commit_Ts
config: 
syncer.replicate-do-db: [db1,db2,....] 
syncer.db-type: "tidb" 
syncer.to.host: "xxxdmall.db.com" 
syncer.worker-count: 550 
syncer.to.checkpoint.schema: "tidb_binlog2"

1 个 drainer 进⾏增量提早越来越⼤

3 个 drainer 进⾏并⾏增量同步最慢⼀条增量链路：9h 追了近 1 天数据

3 个 drainer 并⾏同步⽬的端写⼊ 1.2w TPS > 源端 6k 写⼊ TPS

9、配置新建 tidb grafana&dashboard 域名

建 grafana、dashboard 的域名指向⽣产 nginx 代理，由 nginx 代理 grafana 端⼝，dashboard 端⼝

1、check 新⽼ TiDB 集群数据同步⼀致性状况

TiDB 在全量和增量时会⾃⾏进⾏数据⼀致性校验，咱们次要关注增量同步提早状况，并随机 count(*)源⽬的端表

# 提早查看⽅法⼀：在源端 TiDB drainer 状态中获取最新曾经回复 TSO 再通过 pd 获取提早状况 
mysql> show drainer status;
+-------------------+-------------------+--------+--------------------+------- --------------+ 
| NodeID | Address | State | Max_Commit_Ts | Update_Time | 
+-------------------+-------------------+--------+--------------------+------- --------------+ 
| xxxxxx:8249 | xxxxxx:8249 | online | 430547587152216733 | 2022-01-21 16:50:58 | 


tiup ctl:v5.1.2 pd -u http://xxxxxx:2379 -i 
» tso 430547587152216733; 
system: 2022-01-17 16:38:23.431 +0800 CST 
logic: 669 


#提早查看⽅法⼆：在 grafana drainer 监控中察看 
tidb-Binlog->drainer->Pump Handle TSO 中 current 值和以后理论工夫做提早⽐较 
曲线越陡，增量同步速率越快

2、tiflash 表建⽴ &CDC 同步在新 TiDB 集群建⽴ & 新 mysql->tidb 汇总同步链路闭环(DRC-TIDB)

tiflash

源端 tidb ⽣成⽬的端新建 tiflash 语句


SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = '<db_name>' and TABLE_NAME = '<table_name>' 
SELECT concat('alter table',table_schema,'.',table_name,'set tiflash replica 1;') FROM information_schema.tiflash_replica where table_schema like 'dfp%';

CDC 链路闭环

在⽼ TiDB CDC 同步中选取 1 个 TSO 位点在新 TiDB 中建⽴ CDC ⾄ kafka topic 同步

DRC-TIDB 链路闭环（⾃研 mysql->tidb 合库合表同步⼯具）

上图左右为 DRC-TIDB 拆分前后状态

1、左⽼ drc-tidb 同步规定 copy 到右新 drc-tidb，不启动 drc-tidb 同步(记录以后工夫 T1)

2、drainer 同步现有 TiDB 数据⾄新建 TiDB 链路启⽤平安模式 replace(syncer.safe-mode: true)插⼊

3、批改左 drc-tidb 同步源⽬的地址为闭环，并启动 drc-tidb（记录以后工夫 T2）

4、右 tidb grafana drainer 监控中 check 以后同步工夫 checkpoint 是否 >=T2（相似于 tikv follower- read），若没有则期待提早追上

5、右 tidb 集群增量同步批改 edit-config drainer 配置⽂件，去掉 mysql-tidb 同步的库名（所有库同步减少指定库名同步）并 reload drainer 节点

commit_ts: 431809362388058219 
config: 
syncer.db-type: tidb 
syncer.replicate-do-db: 
- dmall_db1 该 DB 为间接读写 
- dmall_db2 该 DB 为从 mysql 同步⽽来，需去掉

6、批改右 drc-tidb 同步源⽬的地址为闭环，并启动右 drc-tidb（drc-tidb 采⽤幂等同步，会反复消费 copy 同步规定 T1 工夫到当初的 mysql binlog）

3、每个新 TiDB 集群 ANALYZE TABLE 更新表统计信息

不是必须，更新统计信息为最新能够防止查问 sql 索引抉择⾛错

1、左 tidb 集群应⽤域名解析⾄新建 tidb 计算节点

2、批量 kill 右 TiDB 集群左应⽤的连贯

存在脚本屡次批量 kill tidb pid; 在右 tidb 节点仍然有⼤量左应⽤的连贯，因而左应⽤滚动重启后右

tidb 节点左应⽤连贯开释

3、移除⽼ TiDB 集群 -> 新 TiDB 集群增量同步 drainer 链路

留神：因多个 TiDB 集群共⽤的 1 台⾼配 drainer 机器，node_exporter(采集机器监控 agent)也是多个 TiDB 集群共⽤，当 A TiDB 集群停⽌ drainer 链路，B C TiDB 集群会报 node_exporter 不存活告警

不同 TiDB 版本的降级统⼀版本很有必要，⼀是拆分⽅法的通⽤，缩小拆分的复杂度，⼆是享受新版本的个性，减低运维治理老本
⽬标 TiDB 集群磁盘空间需⾜够富余
在源 TiDB 写⼊压⼒⼤时增量同步 binlog 到⽬的端的提早保障须要 drainer 按库名进⾏并发增量同步
TiDB 拆分波及步骤多，能提前做的步骤就提前做，真正拆分的工夫窗⼝很短
感激 TiDB 官⽅社区对咱们的技术⽀持，路漫漫其修远兮，咱们将高低⽽求索

关于tidb:技术分享-TiDB-上百T数据拆分实践

背景

挑战

⽅案

因 TiDB 拆分 BR 全量物理备份 +binlog 增量波及周期⻓，咱们分为 4 个阶段进⾏

第⼀阶段

第⼆阶段

第三阶段

第四阶段

总结