TiDB集群迁移实战：全量+增量数据同步与MinIO存储配置-代码聚汇网

TiDB集群迁移实战：全量+增量数据同步与MinIO存储配置

酸流

1. 项目背景与核心挑战

最近刚完成一个从TiDB 7.1.5集群到新集群的完整迁移项目，过程中涉及全量数据迁移、增量数据同步以及MinIO对象存储的配置使用。这种迁移场景在实际工作中很常见，比如机房搬迁、硬件升级或者架构优化时都会遇到。与简单的数据库导出导入不同，生产环境的迁移需要保证数据零丢失、服务影响最小化，这对技术方案的选择和细节处理提出了很高要求。

这次迁移的技术栈组合非常典型：

TiDB作为分布式NewSQL数据库
BR工具（Backup & Restore）处理全量数据
TiCDC实现增量数据同步
MinIO作为S3兼容的备份存储

这种组合既发挥了TiDB生态工具的原生优势，又通过MinIO实现了存储方案的灵活性。下面我就结合实战经验，详细拆解每个环节的技术实现和注意事项。

2. 环境准备与集群部署

2.1 源集群与目标集群配置

我们使用TiUP快速部署测试集群，模拟生产环境：

bash复制# 部署上游集群（源集群）
tiup --tag upstream playground --host 0.0.0.0 --db 1 --pd 1 --kv 1 --tiflash 0 --ticdc 1

# 部署下游集群（目标集群） 
tiup --tag downstream playground --host 0.0.0.0 --db 1 --pd 1 --kv 1 --tiflash 0 --ticdc 1

关键参数说明：

--db：TiDB服务节点数
--pd：PD服务节点数
--kv：TiKV服务节点数
--ticdc：TiCDC服务节点数

生产环境建议至少3个节点保证高可用，测试环境单节点即可。TiFlash在本场景中不需要，故设为0。

2.2 测试数据生成

使用sysbench生成测试数据，模拟真实业务负载：

bash复制sysbench oltp_write_only \
  --config-file=./tidb-config \
  --tables=10 \
  --table-size=10000 \
  prepare

配置文件tidb-config示例：

ini复制mysql-host=172.16.6.122
mysql-port=4000  
mysql-user=root
db-driver=mysql
mysql-db=test
threads=10
rate=100

这个配置会生成10张表，每张表1万行数据，同时保持100 TPS的写入压力。注意要根据实际环境修改IP地址。

3. MinIO存储配置

3.1 MinIO服务部署

选择MinIO作为备份存储，因其兼容S3协议且部署简单：

bash复制wget https://dl.min.io/server/minio/release/linux-amd64/minio
chmod +x minio

export MINIO_ROOT_USER='minio'
export MINIO_ROOT_PASSWORD='miniostorage'
mkdir -p data/backup

./minio server ./data --address :6060 &

3.2 访问配置

MinIO部署完成后，备份访问信息如下：

Endpoint: http://${HOST_IP}:6060
Access-key: minio
Secret-access-key: miniostorage
Bucket: backup

对应的S3访问URI：

code复制s3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://${HOST_IP}:6060&force-path-style=true

生产环境建议配置TLS加密和更复杂的访问凭证，测试环境可以用简单配置。

4. 全量数据迁移

4.1 关闭GC机制

为确保备份数据一致性，需要先关闭垃圾回收(GC)：

sql复制SET GLOBAL tidb_gc_enable=FALSE;
SELECT @@global.tidb_gc_enable; -- 确认已关闭

4.2 执行全量备份

使用BR工具备份到MinIO：

sql复制BACKUP DATABASE * TO 's3://backup?...' RATE_LIMIT = 120 MB/SECOND;

关键参数：

RATE_LIMIT：限制备份带宽，减少对业务影响
BackupTS：备份时间点，后续增量同步的起点

4.3 数据恢复

在下游集群执行恢复：

sql复制RESTORE DATABASE * FROM 's3://backup?...';

恢复完成后建议使用sync-diff-inspector校验数据一致性：

bash复制sync_diff_inspector -C ./config.yaml

5. 增量数据同步

5.1 创建TiCDC同步任务

使用备份时的BackupTS作为同步起点：

bash复制tiup cdc cli changefeed create \
  --server=http://172.16.6.122:8300 \
  --sink-uri="mysql://root:@172.16.6.125:4000" \
  --changefeed-id="upstream-to-downstream" \
  --start-ts="431434047157698561"

5.2 重新开启GC

确认同步任务正常运行后，重新开启GC：

sql复制SET GLOBAL tidb_gc_enable=TRUE;

6. 服务切换与验证

6.1 停止上游写入

首先停止业务写入，确保所有增量数据同步完成。

6.2 切换同步方向

暂停原同步任务，创建反向同步：

bash复制tiup cdc cli changefeed pause -c "upstream-to-downstream" --server=http://172.16.6.122:8300

tiup cdc cli changefeed create \
  --server=http://172.16.6.125:8300 \
  --sink-uri="mysql://root:@172.16.6.122:4000" \
  --changefeed-id="downstream-to-upstream"

6.3 业务切换

将应用连接指向新集群，完成最终切换。

7. 关键问题与解决方案

7.1 GC与备份的时序问题

我们遇到过因GC过早清理数据导致备份失败的情况。解决方案是：

备份前先关闭GC
增大TiCDC的gc-ttl参数（默认24小时）
监控备份进度，及时处理异常

7.2 大表备份超时

对于超过1TB的大表，建议：

增加BR的--send-credentials-to-tikv参数
调大--conn-timeout和--storage-timeout
分表分批备份

7.3 MinIO性能优化

当备份速度较慢时，可以：

部署多节点MinIO集群
调整RATE_LIMIT找到最佳平衡点
为MinIO配置高性能磁盘（如NVMe SSD）

8. 监控与指标

整个迁移过程中需要重点关注以下指标：

指标类型	监控项	正常范围
备份进度	BR进度百分比	持续增长
同步延迟	TiCDC同步延迟	<5s
资源使用	CPU/内存/网络	不超过80%水位
业务影响	查询延迟、错误率	波动<10%

9. 项目总结

这次TiDB集群迁移的几个关键收获：

备份策略：全量+增量的组合方案能最大限度减少停机时间
存储选型：MinIO作为S3兼容存储，既经济又高效
流量控制：合理设置RATE_LIMIT对业务平稳运行至关重要
验证机制：sync-diff-inspector是数据一致性的最后保障

对于计划做类似迁移的团队，建议先在测试环境充分验证，特别是网络带宽和存储性能要留足余量。整个过程中，TiDB生态工具链的成熟度给我们留下了深刻印象，从BR到TiCDC的完整解决方案大大降低了分布式数据库迁移的门槛。