POC测试背景
在某地震多发省，为了避免地震造成的机房级灾难，或者城市级灾难，导致整个系统不可用，拟建设一套三地五中心五副本分布式高可用数据库系统，保证高可用需求。在该系统中需要接入不同地区的应用流量，且前期应用开发已经采用了百库百表的水平分库表策略。为尽可能减少应用~数据库延迟、数据库计算层向存储层跨机房跨城取数延迟，需要做到业务流量与对于数据分片leader在同一个机房。
POC测试项
#敏感信息已脱敏，测试用例信息可作为参考与学习
测试环境信息
机器软件环境配置
共12台阿里私有云托管物理机，其中10台用作部署集群，2台用作部署同步程序或测试HTAP能力扩容。
单台配置如下：
| 配置项 | 配置信息 |
|---|---|
| 系统内核版本 | 麒麟v10、arm架构 |
| cpu | 海光 64c(已超线程) |
| 内存 | 512GB |
| 磁盘 | 4*nvme SSD 3TB |
| tidb版本 | v7.1.0-->v7.1.1 |
机器与空间信息
共有三个城市：cd、ya、lz
五个机房：cd有两个机房AZ1、AZ2；ya有两个机房AZ3、AZ4；lz有一个机房AZ5
延迟：同城两机房延时小于1ms；cd与ya两地延时3ms；cd与lz两地延时7ms;ya与lz两地延时9ms
机器放置拓扑：每个机房两台机器
流量单元化控制
需求
3地数据中心架构有如下需求：
- db_00-24 这 25 个库的 leader 在 AZ1，db_25-49 这 25 个库的 leader 在 AZ2，db_50-74 这 25 个库的 leader 在 AZ3，db_75-99 这 25 个库的 leader 在 AZ4
- AZ5 不能有 Leader，即使前面 4 个 AZ 任意一个故障，AZ5 也不能 Leader
- 5 副本（max-replicas）
解决方案（存在bug）
1、给机器打label
以az1的两台机器为例：
tikv_server:
-host1
config:
server.lables: {az: "az1" ,host : "host1" }
-host2
config:
server.lables: {az: "az1" ,host : "host2" }
2、按照AZ级别设置placement rule确定副本role
az1数据副本(全能型）放置规则，(az2\3\4规则类似）：
"group_id": "pd",
"id": "cd1",
"start_key": "",
"end_key": "",
"role": "voter",
"count": 1,
"label_constraints": [
{"key": "az", "op": "in", "values": ["az1"]}
],
"location_labels": ["az", "host"]
az5数据副本(只同步，不提供服务）放置规则：
"group_id": "pd",
"id": "lz",
"start_key": "",
"end_key": "",
"role": "follower",
"count": 1,
"label_constraints": [
{"key": "az", "op": "in", "values": ["az5"]}
],
"location_labels": ["az", "host"]
详细细节参考Placement Rules 使用文档 | PingCAP 文档中心
3、使用placement rule in sql 配置主副本leader放置规则
创建放置在az1数据的放置规则：
CREATE PLACEMENT POLICY p1 LEADER_CONSTRAINTS="+az=az1" FOLLOWER_CONSTRAINTS="{+az=az2: 1,+az=az3: 1,+az=az4: 1,+az=az5: 1}"
在百库百表下每个az约有进250+库，2500+表
生成更改表放置规则的sql语句,约2500+DDL
select concatenate（'alter table' ,table_achema ,'.',table_name,'placement policy = p1' from information_schema.tables where right(table_schema ,2) between '00' and '24' order by table_schema
备注：在库已有放置规则的情况下，库下新建无放置规则的表
详细细节参考Placement Rules in SQL | PingCAP 文档中心
bug1
**bug描述：**TiDB v7.1.0 pd调度bug
**bug现象：**数据副本无法按照placement rule in sql设置的放置规则完成调度
bug解决方案：
升级pd从v7.1.0到v7.1.1或整体升级集群到v7.1.1
可以从v7.1.1的镜像源中获取7.1.1版本pd，在一台和外网相通的机器上拉取需要的组件：
tiup mirror clone tidb-community-server-${version}-linux-amd64 ${version} --os=linux --arch=amd64
参考：https://docs.pingcap.com/zh/tidb/stable/production-deployment-using-tiup#%E5%87%86%E5%A4%87-tiup-%E7%A6%BB%E7%BA%BF%E7%BB%84%E4%BB%B6%E5%8C%85
打热补丁
tiup cluster patch <cluster-name> <package-path> [flags]
参考：https://docs.pingcap.com/zh/tidb/stable/tiup-component-cluster-patch#tiup-cluster-patch
或整体升级集群版本，参考：https://docs.pingcap.com/zh/tidb/stable/upgrade-tidb-using-tiup#%E4%BD%BF%E7%94%A8-tiup-%E5%8D%87%E7%BA%A7-tidb
bug2
**bug描述：**placement rule的规则无法完全生效
**bug现象：**按照az去打placement rule 后，在az5仍然会有mysql库、information_schema库等系统库表的region leader ,且部分表出现副本数大于5副本的情况。
**bug解决方案：**弃用按照AZ定义副本role的做法，采用reject-leader方案，参考：跨数据中心部署拓扑 | PingCAP 文档中心
调整方案后收益
跨城获取TSO的影响与探索
问题描述与初步分析
压力测试中，az1、az2、az3、az4各占25%流量，流量与数据主副本leader也保持一致，但是响应延时却并不一致
实测确认跨城获取TSO影响
优化方案
拆分一套集群为4套集群。
灾难恢复与流量切流
需求
1、当发生机房级别灾难时，流量需要切换，为保证最佳性能，pd leader 也要region leader 也要尽可能的与流量进行契合
2、同城一机房挂机后，流量优先切换到同城另一个机房
3、当一个城市两机房全部挂机后，例如cd的az1和az2挂机，流量全部切换至az3和az4，不切换到az5
pd leader 切换
给pd menber 打上权重，保证灾难时优先调度pd leader 到同城节点
交互模式
tiup ctl:v<CLUSTER_VERSION> pd -i -u http://127.0.0.1:2379
以az1流量为例，设置pd leader 调度策略
tiup ctl:v7.1.0 pd member leader_priority pd-1 5
tiup ctl:v7.1.0 pd member leader_priority pd-2 3
tiup ctl:v7.1.0 pd member leader_priority pd-3 1
tiup ctl:v7.1.0 pd member leader_priority pd-4 1
tiup ctl:v7.1.0 pd member leader_priority pd-5 0
手动pd leader 切换（为避免切换后不稳定，需要先调整调度权重）
tiup ctl:v7.1.0 pd member leader transfer pd3
region leader 切换
有问题的切换：
第一步：
假设原放置az1的region leader需要切换到az2,执行sql获得语句，约2500+DDL
select concatenate（'alter table' ,table_achema ,'.',table_name,'placement policy = p2' from information_schema.tables where right(table_schema ,2) between '00' and '24' order by table_schema
第二步：
执行获得的2500+个DDL
问题：切换时间长
数据库层操作：alter table xx placement policy az2; -- 之前是 az1
最终耗时：28 分钟
优化后切换：
换一个思路不再更改表绑定更换规则，而是直接更改绑定的规则的内容
ALTER PLACEMENT POLICY p1 LEADER_CONSTRAINTS="+az=az2" FOLLOWER_CONSTRAINTS="{+az=az1: 1,+az=az3: 1,+az=az4: 1,+az=az5: 1}"
切换时常约3分钟
写在最后
1、poc(概念验证)是一个非常好的检验数据库能力的方式，可以帮我们验证和了解各种功能
2、本次只摘取了整个测试实战过程中碰到的三个点来分享，希望能帮助到有类似需求的TiDB用户
作者介绍：BraveChen，来自神州数码钛合金战队，是一支致力于为企业提供分布式数据库TiDB整体解决方案的专业技术团队。团队成员拥有丰富的数据库从业背景，全部拥有TiDB高级资格证书，并活跃于TiDB开源社区，是官方认证合作伙伴。目前已为10+客户提供了专业的TiDB交付服务，涵盖金融、证券、物流、电力、政府、零售等重点行业。
