TiDB 在 WPS丨分享业务双机房建设实践

WPS 算是国内 TiDB 较早的一批用户，WPS 分享业务就是在 TiDB-v2.x 稳定运行了几年。直到 2020 远程办公爆发式增长，数据量巨大，为提高稳定性和性能，同时考虑到数据安全等方面因素，规避单机房故障导致的业务不可用风险，多机房建设及稳定性提升已然成为 WPS IT 建设中的重要指标。经过 TiDB 在近几年内的快速迭代，v2.x 已是很古老的版本，新版本的特性升级在建设双机房的过程中显得更加容易落地。

在工作和生活中我们常需要传输各种各样的文件。普通的传输方式传输时间久低效，无权限控制不安全，而分享协作它会将文件以分享方式发送给他人，减少了因文件过大带来的传输时间。还可以设置好友编辑权限、有效期、自定义关闭文件的分享权限，大大提高了文件传输的安全性。WPS 分享业务在数据库结构上有个特殊的服务，它需要在单表上使用多个维度的索引，一个表需要分别通过多字段组合来查询，而且数据量巨大，目前单表最大规模约几十亿条数据。如果用传统的分库分表来设计，虽然也可以解决问题，但是会面临很多麻烦，比如代码逻辑复杂，数据冗余，数据不一致等问题，而使用 TiDB 分布式数据库就能轻松应对这些问题。

TiDB 高度兼容 MySQL 协议，基本可以当成 MySQL 使用；天然的分布式存储与计算分离的架构的设计，让多副本保存数据无需考虑单点问题；同时能够动态在线扩容缩容，对应用透明不影响业务，操作也相对简单。除此之外，TiDB 官方社区活跃，文档很齐全，遇到问题时官方的响应也很及时。

TiDB 版本：TiDB-v2.x

TiDB 版本：TiDB-v4.x

因为现有架构的 TiDB 版本是 2.x 版本 ，不支持 TiDB CDC 同步数据到另一个 IDC 集群，所以需要先升级版本；利用 TiDB 滚动开启 binlog，配置 Drainer 再增量同步到 TiDB-v4.x。

架构演变

同步架构

1. TiDB-v2 开启 binlog，设置 gc-time 720h，Dumpling 全量备份;

2. Lightning 导入 TiDB-v4，配置 TiCDC 同步；

3. TiDB-v2 配置 Drainer 增量同步至 TiDB-v4;

双机房高可用架构

1. 配置内部 DNS 域名指向 HAProxy 代理，两个 HAProxy 同时解析到 IDC1-TiDB 集群，当 IDC1 不可用，切至 IDC2-TiDB 集群；

2. 数据核验，包括定时核对，滚动核对；

3. 应用切换连接域名；

实施步骤

流程简述

1. TiDB-v2.x 滚动开启 binlog；

2. TiDB-v2.x 备份导出数据库，恢复到 IDC1-TiDB-v4.0 集群、IDC2-TiDB-v4.0 集群；配置 TiCDC，IDC1 增量同步数据到 IDC2-TiDB-v4.0 集群；

3. TiDB-v2.x 配置 Drainer 增量同步到 TiDB-v4.x；

4. 业务设置只读，检查数据一致性，指定时间核对表数据，sync-diff-inspector 滚动校验，停止 Drainer 同步，应用连接地址切换到域名："xxxx"；

5. 测试检验业务功能模块是否正常。

实施步骤

TiDB-v2.x 滚动开启 binlog

修改 tidb-ansible/inventory.ini 文件设置 enable_binlog = True，表示 TiDB 集群开启 binlog。

## binlog trigger
enable_binlog = True
## Binlog Part
[pump_servers]
pump1 ansible_host=ip1 deploy_dir=/disk/ssd/tidb/pump
pump2 ansible_host=ip2 deploy_dir=/disk/ssd/tidb/pump
pump3 ansible_host=ip3 deploy_dir=/disk/ssd/tidb/pump

ansible-playbook deploy.yml --tags=pump -l ${pump1_ip},${pump2_ip},${pump3_ip}

ansible-playbook start.yml --tags=pump

ansible-playbook rolling_update.yml --tags=tidb

ansible-playbook rolling_update_monitor.yml --tags=prometheus

show pump status; 

./dumpling -h xxx.xxx.xxx.xxx -P 4000 -u root -pxxxxxx -r 200000 --tidb-mem-quota-query 536870912 -t 1 -F 128MB -B shared_link -o $bakdir

nohup /opt/tidb-toolkit-v4.x-linux-amd64/bin/tidb-lightning -config tidb-lightning.toml > nohup.out &

[drainer_servers]
drainer_tidb ansible_host=ip1 initial_commit_ts="xxxx"

cd /srv/tidb-ansible/conf
cp drainer.toml drainer_tidb_drainer.toml
detect-interval = 10
[syncer]
ignore-schemas = "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql,test"
txn-batch = 20
worker-count = 16
disable-dispatch = false
safe-mode = false
db-type = "TiDB"
replicate-do-db = ["xxxx"] #只同步需要迁移的db
[syncer.to]
host = "xxx.xxx.xxx.xxx"
user = "root"
password = "xxxxxx"
port = 4000

ansible-playbook deploy_drainer.yml

 ansible-playbook start_drainer.yml

ansible-playbook rolling_update_monitor.yml --tags=prometheus

tiup ctl cdc changefeed create --pd=http://ip1:2379 --sink-uri="TiDB://root:xxxxx@xxx.xxx.xxx.xxx:4000/?worker-count=16&max-txn-row=20000" --changefeed-id="simple-replication-task"  #创建同步
tiup ctl cdc changefeed list --pd=http://ip1:2379  #查看同步ID
tiup ctl cdc changefeed query -s --pd=http://ip1:2379 --changefeed-id=simple-replication-task #查看同步状态
tiup ctl cdc changefeed query --pd=http://ip1:2379 --changefeed-id=simple-replication-task  #查看详细配置

1. cdc 重启
2. 反复 kill cdc 进程
3. 脚本持续写入更新 停 cdc 进程一小时，
4. 重启 tidb follower
5. tidb follower 停机一小时
6. 重启 tidb master
7. iptable 断网

部署配置参考官方文档：https://pingcap.com/zh/blog/best-practice-haproxy。下面简述下 HAProxy 冷切、热切的方式：

冷切：冷切换代理至 IDC2 机房 TiDB 集群，修改配置直接重启 HAProxy

unlink haproxy.cfg
ln -s hw-haproxy.cfg haproxy.cfg
重启 HAProxy
systemctl stop haproxy.service 
systemctl start haproxy.service 

haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)

update mysql.tidb set VARIABLE_VALUE = '720h' where VARIABLE_NAME = 'tikv_gc_life_time';