作者： 像风一样的男子原文来源：https://tidb.net/blog/c8f548e8

背景

双集群主从架构优点：

1. 高可用性：主从数据库架构可以提供数据冗余和自动故障转移，当主数据库发生故障时，从数据库可以接管服务，保证系统的持续可用性。

2. 读写分离：通过将读请求分发到从数据库，可以分担主数据库的读负载，提高系统整体的性能和响应速度。

3. 数据备份：从数据库可以用作主数据库的实时备份，确保数据的安全性和可靠性。在主数据库数据丢失或损坏时，可以从从数据库中快速恢复数据。

4. 数据分析：从数据库可以用于数据分析、报表生成等只读操作，不影响主数据库的性能。

5. 地理冗余：通过将从数据库部署在不同的物理位置，可以实现地理冗余，提高系统的灾难恢复能力。

6. 异地容灾：当主数据库所在地发生灾难性事件时，可以切换到远程的从数据库，保证业务的连续性。

7. 误操作数据找回：在不影响主库性能情况下 gc 时间比较短，一旦发生误操作无法找回数据，可以延长从库 gc 时间，同过 FlashBack 闪回功能找回数据。

Tidb 主从同步有 2 种方式:binlog 和 Ticdc。

主从同步切换原因

  我使用的Tidb版本早期是4.0版本，使用binlog做主从同步，随着数据量增长，同步延迟开始变大，调大drainer并发参数worker-count、扩容tidb节点后能解决延迟问题。

从 TiDB v7.5.0 开始，TiDB Binlog 的数据同步功能被废弃。从 v8.3.0 开始，TiDB Binlog 被完全废弃，并计划在未来版本中移除。

binglog 和 ticdc 同步数据区别

MySQL binlog 直接记录了上游执行的所有 DML 操作的 SQL 语句。

与 MySQL 不同，TiCDC 则实时监听上游 TiKV 各个 Region Raft Log 的信息，并根据每个事务前后数据的差异生成对应多条 SQL 语句的数据变更信息。TiCDC 只保证输出的变更事件和上游 TiDB 的变更是等价的，不保证能准确还原上游 TiDB 引起数据变更的 SQL 语句。

当下游是 MySQL 或者 TiDB 时，因为 TiCDC 并非直接获取原生上游执行的 DML 语句，而是重新根据数据变更信息来生成 SQL 语句，因此不能保证写入下游的 SQL 语句和上游执行的 SQL 语句完全相同，但会保证最终结果的一致性。

综上今年数据库版本升级到 7.5 后决定放弃 binlog 换成 ticdc。

切换步骤

1、扩容 ticdc 组件

准备好三台 cdc 服务器。

编写一个名为 scale-out.yml 的配置文件，包含需要扩容的节点的配置信息。

cdc_servers:  - host: 10.1.1.1    gc-ttl: 86400    data_dir: /tidb-data/cdc-8300  - host: 10.1.1.2    gc-ttl: 86400    data_dir: /tidb-data/cdc-8300  - host: 10.0.1.4    gc-ttl: 86400    data_dir: /tidb-data/cdc-8300

扩容节点：

tiup cluster scale-out <cluster-name> scale-out.yml -u root -p

2、停止 drainer 服务

tiup cluster stop <cluster-name> -N x.x.x.x:8249

3、从 drainer 日志中获取最后同步数据 ts。

日志路径： /tidb-deploy/drainer-8249/log/drainer.log

[INFO] [syncer.go:279] [“write save point”] [ts=454753168687628823]

4、创建同步任务，复制增量数据到 从库。

cdc cli changefeed create –server=http://x.x.x.x:8300 –sink-uri=“mysql://username:password\@x.x.x.x:4000/” –changefeed-id=“slave-tidb” –start-ts=454753168687628824

注意 start-ts 需要第三步中 ts+1

效果

从 dashboard 监控上看效果明显

从库整体 qps 从 6000 降低至 800，cpu 使用率降低 80%。

TiDB 资源管控使用从 35kRU 降低至 15kRU。