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';