导读
文章首先简单介绍了TiDB数据库，包括产品特性、使用场景和组件架构，随后说明了本次TiDB数据库迁移的背景和原因，接着详细阐述了TiDB集群两种主流的迁移方案，包括通过 TiCDC 实现实时数据同步的主备集群迁移方案，以及使用 TiDB 的 Placement Rules 进行跨云跨 Kubernetes 集群的副本投放迁移方案，同时分析了在当前业务场景下，为何我们选取通过TiCDC作为桥梁进行新旧集群迁移。此外，还考虑了一些迁移过程中的特殊的业务场景，以及解决的一些问题。希望给大家在选用TiDB数据库以及做数据迁移时提供一些实践经验和参考。
前文-TiDB介绍
TiDB简介
TiDB 是一款开源的分布式关系型数据库， 适合高可用、强一致要求、数据规模较大等应用场景，具备如下特性：
•TiDB 采用的分布式架构支撑海量数据扩展，可以有效地解决单机 MySQL 容量和性能的瓶颈问题；
•TiDB 与 MySQL 兼容性非常好，迁移成本很低，接入周期短，收益见效快；
•支持在线扩容和在线 DDL，业务几乎无感知；
•数据具有强一致性，支持事务，使用场景不受限制；
•相同数据下, TiDB存储的磁盘占用是MySQL的1/3, 更加节省存储资源, 降本增效。
TiDB架构
图1：TiDB集群架构图
TiDB Server
SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。
TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV。TiDB 层本身是无状态的，一个集群可以有多个 TiDB 实例，通过负载均衡组件（如 LVS或HAProxy ）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。
PD Server
整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。
TiKV Server
负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。另外，TiKV 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。
TiFlash
TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。
一、迁移背景
1.1 数据量大，存储分散，管理困难
随着业务的不断增长，早期自建TiDB集群的存储资源经历多次扩容，数据量不断攀升。同时因存储资源制约和业务历史原因，业务方在自建TiDB集群之外集团其他平台申请了多个TiDB集群混用，导致同业务线的数据存储在不同的平台、不同的机房，部分业务库存在共读共写的情况，在一定程度上，提升了数据安全风险，也提升了数据资产管理的复杂度和日常工作中的沟通成本。在可观测性方面，没有统一的监测体系和运维管理手段，也不利于安全生产的实施和数据质量的把控。
1.2 机器老旧，存在读写性能风险
自建TiDB集群使用物理机部署，部署在旧机房，部分机器老旧，存在性能风险，集团整体逐步推进旧机房过保机器裁撤，机房迁移势在必行。已有部分业务使用的TiDB数据库在大促前频繁出现TiKV节点CPU使用率高，磁盘读写繁忙告警，偶发短暂影响接口性能，也需要尽快实现迁移。
1.3 TiDB on Kubernetes OR 物理机
分布式数据库往往对运维管理、性能指标监测有较高要求，原有自建TIDB基于物理机部署，使用tiup作为运维工具处理日常运维事务，在schema管理、账号权限管理、DDL审批、SQL审计、慢查询治理方面尚不完备。计划将集群迁移至京东公有云平台，借助Kubernetes实现TiDB的集群部署、动态扩缩容、运维监控。综合对比来看，Kubernetes 适合动态、多租户场景，物理机则更适合对性能要求极高的关键任务，两种方式的具体优劣对比如下：
•灵活性与弹性: Kubernetes 提供自动扩展、负载均衡和自愈能力，使数据库能更灵活地响应业务流量波动。相比之下，物理机部署固定资源，弹性扩展较难，需手动调整。
•资源管理: Kubernetes 提供资源隔离和调度优化，允许数据库与其他应用共享资源。物理机则专注于资源固定分配，难以实现动态调度。
•运维复杂度: Kubernetes自动化运维工具（如 TiDB Operator）简化了数据库的部署、升级和故障恢复，而物理机则需要通过tiup进行手动维护，操作更为复杂。
•性能: 物理机通常能提供更高的性能，尤其是对高 I/O 需求的数据库，而 Kubernetes可能因虚拟化开销导致性能下降。
TiDB Operator 是 Kubernetes上的 TiDB 集群自动运维系统，提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator，TiDB 可以无缝运行在公有云或自托管的 Kubernetes 集群上。
TiUP 是 TiDB 4.0 版本引入的集群运维工具，通过 TiUP cluster 组件就可以进行日常的运维工作，包括部署、启动、关闭、销毁、弹性扩缩容、升级 TiDB 集群，以及管理 TiDB 集群参数。以下是TiDB集群两种运维工具的多维度对比：
图2：TiDB集群运维工具对比
总的来说，基于K8s的 TiDB Operator实现了更为强大的可扩展性和自动化运维能力。公有云平台基于K8s集群，使用TiDB Operator处理TiDB集群运维事务，更有利于统一集中运维管理。
二、迁移过程
2.1 迁移方案
本章介绍适用于不同场景的TiDB集群迁移方案，包括基于TiCDC构建实时数据同步管道的迁移方案，以及跨云跨Kubernetes的TiDB placement-rule 副本投放迁移方案。我们选用旧集群基于TiCDC的迁移方案，有以下两点原因：1.旧集群是TiDB v5.1版本，公有云平台产品化的TiDB只有更高版本，所以只能进行升级迁移，只有基于TiCDC的方案支持升级迁移。2.旧集群部署在物理机，无法实施跨K8s集群的副本投放迁移方案。基于以上原因，我们选用基于TiCDC的迁移方案，接下来详细介绍两个方案及其执行细节。
2.1.1 基于TiCDC实时同步的主备集群迁移方案
什么是TiCDC？
TiCDC 是 TiDB 生态中的一个数据同步工具，它能够将上游 TiDB集群中产生的增量数据实时的同步到下游目的地。TiCDC 典型的应用场景为搭建多套 TiDB 集群间的主从复制，或者配合其他异构系统搭建数据集成服务。
如何基于TiCDC实现集群迁移？
基于 TiCDC 迁移需要通过Backup/Restore工具，将旧集群的存量数据恢复至新集群，再通过 TiCDC 搭建数据同步管道进行增量同步。在数据同步后需要和业务方配合进行迁移，高优业务需要在低峰时进行迁移，对数据一致性有严格要求的需要业务配合停写迁移
图3：基于TiCDC的实时同步架构图
优点
•迁移过程支持版本升级：上下游均为独立集群，下游新集群版本可以高于上游集群，对于需要替换老版本或者希望用到新版本特性的业务，可以迁移升级一起完成。但需要注意升级版本后的 SQL 兼容性。
•资源隔离，方便业务拆分整合：对于之前多个业务混合部署在同一 TiDB 集群的情况，支持按库、表不同粒度创建同步任务，可实现拆分为多集群；也可以将散落在不同集群的同业务线数据进行整合，提升资源利用率。
•容错率高，支持故障恢复：TiCDC 的迁移可以随时回滚，在业务停写切读写到下游集群时刻创建反向同步任务，将新集群生产的数据同步回老集群，在业务确定迁移成功一周后再停掉同步任务，并删除老集群，提升迁移过程的容错率
缺点
•数据同步延迟不稳定：上游集群写入数据量较大时，TiCDC 数据同步延迟较高，读敏感场景无法支持切换
•数据同步能力有限制：TiCDC 的同步能力在单worker 3w/s，超过该限制，TiCDC节点运行稳定性降低
•需延长gc-life-time：Backup/Restore较大数据量可能时间较长（经验来说，一般10TB数据备份时间会超过6hours，具体也受限于网络带宽和对象存储的IO性能），需要调整数据版本有效时间参数 gc-life-time 来保证增量同步有效， gc-life-time 配置过长会保留较多 MVCC，可能会对 TiDB 读性能造成部分影响。
TiCDC 迁移操作步骤
基于TiCDC创建同步任务changefeed，创建粒度综合考虑业务线、库表数量、单表写入数据量，划分为多个任务。
通过TiCDC进行数据迁移的具体步骤如下：
（1）在公有云平台创建新TiDB 集群(根据业务要求，版本可以一样也可以升级到高版本)
（2）延长旧集群的 gc_life_time，时间视备份数据量大小而定，此处设置为72hour
mysql> select * from mysql.tidb where VARIABLE_NAME like '%gc_life_time%';
+-------------------+----------------+----------------------------------------------------------------------------------------+
| VARIABLE_NAME | VARIABLE_VALUE | COMMENT |
+-------------------+----------------+----------------------------------------------------------------------------------------+
| tikv_gc_life_time | 10m | All versions within life time will not be collected by GC, at least 10m, in Go format. |
+-------------------+----------------+----------------------------------------------------------------------------------------+
update mysql.tidb set VARIABLE_VALUE='72h' where VARIABLE_NAME='tikv_gc_life_time';
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> select * from mysql.tidb where VARIABLE_NAME like '%gc_life_time%';
+-------------------+----------------+----------------------------------------------------------------------------------------+
| VARIABLE_NAME | VARIABLE_VALUE | COMMENT |
+-------------------+----------------+----------------------------------------------------------------------------------------+
| tikv_gc_life_time | 72h | All versions within life time will not be collected by GC, at least 10m, in Go format. |
+-------------------+----------------+----------------------------------------------------------------------------------------+
（3）使用 BR 工具备份旧集群数据到 S3，BR 的版本要跟 TiDB 集群版本一致
export AWS_ACCESS_KEY_ID=xxxxx
export AWS_SECRET_ACCESS_KEY=xxxxx
./br backup full \
## db粒度
--db cps \
## table粒度
-f 'db1.xxx' \
-f 'db2.xxx' \
-f 'db3.jb_uesrpath_detail' \
--pd 'ip:port' \
--storage 's3://tidbbackup/online/' \
--s3.endpoint 'http://s3-internal.tech-north-1.jdfin.local' \
--ratelimit '128' \
--s3.provider 'ceph' \
--send-credentials-to-tikv=true \
--log-file backup_online_all.log
下方代码块为备份成功打印的日志信息，显示12TB数据量，时间消耗约6hours。此处获取TSO（BackupTS）参数，代表数据版本号，后续cdc同步任务基于该参数完成搭建，需要保存。
[INFO] [collector.go:67] ["Full backup success summary"] [total-ranges=365329] [ranges-succeed=365329] [ranges-failed=0] [backup-checksum=5h16m46.886603421s] [backup-fast-checksum=73.657854ms] [backup-total-ranges=5] [backup-total-regions=227539] [total-take=6h20m59.462341107s] [BackupTS=444494078810521601] [total-kv=46659499330] [total-kv-size=12.48TB] [average-speed=3.245GB/s] ["backup data size(after compressed)"=4.858TB]
（4）使用 BR工具将 第三步中的S3 数据备份恢复到 公有云新集群
export AWS_ACCESS_KEY_ID=xxxxx
export AWS_SECRET_ACCESS_KEY=xxxxx
./br restore full \
--pd 'ip:port' \
--storage 's3://tidbbackup/online/' \
--s3.endpoint 'http://s3-internal.tech-north-1.jdfin.local' \
--ratelimit '128' \
--s3.provider 'ceph' \
--send-credentials-to-tikv=true \
--log-file restore2cloud_online_all.log
（5）创建旧集群到新集群的 CDC 任务
旧集群需要部署 CDC 组件节点，CDC任务使用上文第三步中提到的备份日志中的 TSO
tiup ctl:v5.1.0 cdc changefeed create \
--pd=http://ip:port \
--sink-uri="mysql://user:pswd@tidb_address:tidb_port/?worker-count=16&max-txn-row=500" \
--start-ts=${TSO} \
--changefeed-id="cdc-db-tb" \
--sort-engine="unified" \
--config changefeed_tb.toml \
（6）数据同步验证方法
•观察 grafana 监控的cdc模块的change feed（如下图）
•cdc query changefeed-id 命令查看已经没有延迟（如下代码块）
•dataSize、data sample抽样验证数据一致性
图5-TiDB监控-changefeed checkpoint panel
#cdc changefeed query --pd=http://ip:port --changefeed-id=xxxxx
# "status": {
"resolved-ts": 443792651063394305, //resolved-ts: upstream ——> cdc
"checkpoint-ts": 443792650918952961, //checkpoint-ts: cdc ——> downstream
"admin-job-type": 1
}
（7）线上业务读流量灰度发布：读敏感型业务，需保证严格的数据一致性，对同步延迟不能接受，需要选择凌晨低峰期同步切读写。可以让读取不敏感的读业务灰度发布到新集群，验证业务 SQL 的执行情况；
（8）线上业务读流量灰度 100% ，写流量切换：业务切写的方式有两种选择：
• 业务自己控制停写，然后切到下游：适用于上游是消息队列MQ或者离线批次写入的情况；
•数据库回收老集群用户的写入权限来强制停写：回收权限对已建链接不生效，需要 kill 一遍所有的链接或者重启一遍 TiDB Server，适用于大规模服务端直连数据库写入的情况
（9）停写后的容灾策略：需要观察下同步链路，确认没有数据同步，然后停止老机房到新机房的 TiCDC 同步链路，并且建立新机房 TiDB 集群反向同步老机房的链路，目的是一旦新集群有任何问题，可以随时切回老集群，数据也不会丢失
（10）业务切到下游新集群完成 TiDB 切换
（11）观察一周后，下线 TiCDC 反向同步链路以及删除老集群
（12）回滚方案：如果在一周内出现读写问题，可以随时切换回老集群
2.1.2 跨云跨 k8s 的 TiDB placement-rule 副本投放迁移方案
图6-同城双中心TiDB集群架构示意图
Placement Rules 是 PD 在 4.0 版本引入的一套副本规则系统，用于指导 PD 针对不同类型的数据生成对应的调度。通过组合不同的调度规则，用户可以精细地控制任何一段连续数据的副本数量、存放位置、主机类型、是否参与 Raft 投票、是否可以担任 Raft leader 等属性。Placement Rules 特性在 TiDB v5.0 及以上的版本中默认开启（ 5.0 之前开启需要通过 pd-ctl 命令：config set enable-placement-rules true 开启）。
****默认开启 placement-rule 后的情况如下：
# ./pd-ctl -i
» config placement-rules show
[
{
"group_id": "pd",
"id": "default",
"start_key": "",
"end_key": "",
"role": "voter",
"is_witness": false,
"count": 5 # 代表集群副本数为5
}
如果想给这个 TiDB 集群实现同城双中心的副本放置 3 个 voter 副本在老集群，2 个 follower 副本在新集群，并且在每个规则内通过 label_constraints 将副本限定在对应的数据中心内。配置如下：
[ { "group_id": "pd", "id": "default", "start_key": "", "end_key": "", "role": "voter", "count": 3, "label_constraints": [ {"key": "zone", "op": "in", "values": ["zone1"]}
],
"location_labels": ["rack", "host"]
},
{
"group_id": "pd",
"id": "online2",
"start_key": "",
"end_key": "",
"role": "follower",
"count": 2,
"label_constraints": [
{"key": "zone", "op": "in", "values": ["zone2"]}
],
"location_labels": ["rack", "host"]
}
]
通过以上配置就搞定了新机房的副本投放，相当于我将之前 5 voter 副本都在 id=default 的老机房，拆分成了 3 个 voter 在老机房，2 个 follower 在新机房的同构集群。在 2 个 follower 副本数据同步完成后,修改 placement-rule 配置，将 id=online2 的 region role 由 follower 调整 voter 即可完成 region leader 的跨机房分布，通过观察监控等 leader 均衡后，调整老机房的 count=0，新机房的 count=5 来完成新机房的副本补充，一定时间后老机房 region 掉 0 就完全完成数据的迁移了。调整方式如下：
[
{
"group_id": "pd",
"id": "default",
"start_key": "",
"end_key": "",
"role": "voter",
"count": 0, ####这里的0就代表把老机房的副本删除了
"label_constraints": [
{"key": "zone", "op": "in", "values": ["zone1"]}
],
"location_labels": ["rack", "host"]
},
{
"group_id": "pd",
"id": "online2",
"start_key": "",
"end_key": "",
"role": "voter", ####这里将之前的follower调整到voter
"count": 5, ####这里的5就代表把新online2的副本扩容到5
"label_constraints": [
{"key": "zone", "op": "in", "values": ["zone2"]}
],
"location_labels": ["rack", "host"]
}
]
优点： TiKV 数据根据 placement-rule 规则自动投放，业务读写访问都是同一个集群，只是 tikv 存储的数据副本投放到了不同 k8s 里的不同 TiDB 集群中，整体的迁移对于业务透明，刚才的 3voter : 2follower 配置，好处就在于 3 个 voter 都在老数据中心，TiDB 的写入也基本都是本中心多数派提交，写入性能基本没有什么变化，TiDB 读取也是老数据中心的 leader 读取。
缺点： 副本投放方式不能够跨版本，必须保证和当前集群版本一致，另外一旦有 leader 在新机房产生，业务存在跨机房读写 region leader 的延迟增加问题（增加的延迟对于大部分业务都可控）。
多云同构集群迁移操作步骤
（1）在 online2 创建同版本 TiDB 集群，拷贝老集群的 tc.yaml 的配置，修改里面的配置，只有配置了 clusterDomain 的集群，新集群的 PD 才能在跨云跨 k8s 跟老集群的 PD 通信，另外还需要注意修改 PD 的权重配置，目的在迁移期间将PD leader圈在老机房来保证性能（ TiDB server 经常跟 pd 获取 TSO 和全局 ID 等请求）：
pd-ctl member leader_priority <member_name><priority>
（2）创建同配置同数量的 TiKV 节点 + 配置 placement-rule，这时需要考虑副本的 leader 放置策略（角色设定：voter/follower/learner）
（3）调优region的创建速度：store limit 配置，这里可以使用下面的命令专门给新的 online2 的 TiKV store 配置较高的 region 创建速度。相关的操作如下：
kubectl exec tidb-test-0 -n tidb-test -- ./pd-ctl store |grep -B 2'tidb-test.online2.com'|grep'id":'|awk -F':''{print $2}'|awk -F',' '{print "store limit "$1" 40 add-peer"}
如何观察？查看监控 region health（注意 miss-peer/extra-peer 的变化），另外还可以通过计算 leader region 数量 X 2 ，或者 store region数量 X store 量看估算。
注: Store Limit 与 PD 其他 xxxx-schedule-limit 相关的参数不同的是，Store Limit 限制的主要是 operator 的消费速度，而其他的 limit 主要是限制 operator 的产生速度。
（4）config set schedule 来加速调度，先 config show 查看当前调度配置默认值，执行下面的命令调整 region/leader 调度的并发(注意观察 PD leader 的负载)：
config set leader-schedule-limit 16 ### 控制 Transfer Leader 调度的并发数
config set region-schedule-limit 2048 ### 控制增删 Peer 调度的并发数
config set replica-schedule-limit 64 ### 同时进行 replica 调度的任务个数
（5）均衡 region leader 到新机房集群（follower->voter）
上面讲方案时提到了 online2 机房的 tikv 如何通过 placement-rule 提升为 leader ，并且将老集群 region 缩 0 的方法。需要考虑业务是否能接受跨机房读写 region leader 的延迟增加（从整个迁移周期来看，大部分都是接受的，影响可控），如果读写敏感业务，就需要定一个凌晨切全部的 leader 到 online2，以及切 PD leader 和业务域名到新机房。
（6）多云多活状态，缩容老机房所有 TiKV，delete store，对于“顽固 region ”进行 delete region
这种状态会持续一段时间，因为均衡 region leader，以及下线老机房的 region 都需要天级别的时间，对于下线老机房 store 时，会出现只剩下部分 region 无法迁移走的情况，这是需要用到强制删除的策略，下面的命令就是给 store id=10 的这个 tikv 强制增加 remove-peer 来删除老机房的 region：
kubectl exec tidb-test-pd-0 -n tidb-test -- ./pd-ctl region store 10| jq '.regions | .[]| "(.id)"'|awk -F'"''{print "kubectl exec tidb-test-pd-0 -n tidb-test -- ./pd-ctl operator add remove-peer ",$2," 10"}'> remove_peer.sh
（7）切 PD leader 到新机房
切 PD leader 时需要注意集群抖动和低峰切，因为之前设定了 leader_priority，需要进行调整，可以有两个方式切 PD leader：
•直接设定 online2 的 pd leader_priority 比老机房高，这时PD集群就会因权重调整自动切PD。
•设定online2的 pd leader_priority 跟老机房一致，手动并且选低峰执行 member leader transfer切主到 online2 的集群。
（8） 业务切读写到新机房
因为副本投放的集群两边机房访问的是同一个集群,所以只需要把 dns 从老机房迁到新机房即可,不用 kill 连接,待容器自动销毁后连接自动释放。
（9）缩容老机房 TiDB Server
缩容前查看 cluster-processlist 确认是否还有业务链接，如果有通过 pods IP 找到对应的业务程序，让业务及时切主。查看监控是否还有业务流量，确认没有流量后，老机房 TiDB Server 缩 0。
（10） 老机房缩容所有 pd 节点
确认新 online2 机房有至少 3 个 pd 节点，就可以缩容老机房的所有 pd 节点。
（11） 老机房 delete pvc
默认缩容 TiKV 的 pods 的 PVC 不会删除，需要手动删除 PVC，这样 pv 也自然释放。
（12）老机房 delete tc
老机房 delete tc 的操作风险非常的巨大，操作错新 online2 机房的集群会有毁灭性的影响，操作时一定要 kubectl get pods -n tidb-test 看下是否是已经空的老集群，同时要找找 DBA double check 。
（13）回收物理机资源(delete nodes ，关机回收)
回收资源后，机房迁移完毕。同构集群能够按照上述流程进行升级迁移，当你遇到无法副本投放的集群，就涉及到集群 tc.yaml 中的一个重要的配置 clusterDomain ，如果没有这个配置，就要创建异构集群来添加（所以对于 TiDB on K8s ，如果要跨 K8s 建立集群，必须要配置 clusterDomain ）。
2.1.3 其他场景
空集群业务双写
对于日志型业务，可以在新机房建立集群，业务双写7～30天就完成切换。
BR/dumping 备份，业务切读切写
有些 TiDB 集群只有凌晨写入，白天可以 BR/dumping+lightning 备份恢复后切主。
2.2 问题解决
问题：如果上游集群写入数据量过大，cdc负载过大，造成同步数据延迟，甚至造成cdc节点OOM重启，如何调整？
方案：可以调整cdc同步任务changefeed的worker数量和max-txn-row参数，限制同步的速率，调整cdc同步任务参数语句如下
cdc changefeed update
--changefeed-id=cdc-db-tb simple-replication-task
--pd=http://ip:port
--sink-uri="mysql://user:pswd@address:port/?worker-count=16&max-txn-row=400"
--config=changefeed_tb.toml
如果仍然无法缓解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://ip:port
三、总结
在设计实现基于TiCDC的全量/增量数据迁移方案后，经过跨部门多个业务方的沟通协调，最终完成全部TiDB集群迁移云平台，涉及9条业务线、6个集群、10个DB、约50TB数据，计算资源总计约1500C+。实现集群全部上云，迁移过程基本实现业务无感知和数据无损。通过TiCDC搭建同步数据流，也实现了业务数据整合，实现主备双集群容灾，整合后实现冗余资源下线，整体实现集群数量减少2个，节约资源344C/ 1328GB/13TB，在不影响业务读写性能的前提下，有效降低资源成本开销。
