数据库｜三地五中心，TiDB POC最佳实践探索！_跨城az时延过高达到

目录

一、POC测试背景

//测试环境信息

二、流量单元化控制

//需求

//解决方案

三、跨城获取TSO的影响与探索

//问题描述与初步分析

//优化方案

四、灾难恢复与流量切流

//需求

//pd leader 切换

//region leader t切换

五、写在最后

---

一、POC测试背景

在某地震多发省，为了避免地震造成的机房级灾难，或者城市级灾难，导致整个系统不可用，拟建设一套三地五中心五副本分布式高可用数据库系统，保证高可用需求。

在该系统中需要接入不同地区的应用流量，做流量单元化处理，且前期应用开发已经采用了百库百表的水平分库表策略。为尽可能减少应用和数据库延迟、数据库计算层向存储层跨机房跨城取数延迟，需要做到业务流量与对于数据分片leader在同一个机房。

//测试环境信息

机器软件环境配置

共12台阿里私有云托管物理机，其中10台用作部署集群，2台用作部署同测试HTAP能力和扩容实践。

单台配置如下：

机器与空间信息

共有三个城市：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

//解决方案

1、给机器打label标签

以az1的两台机器为例：
tikv_server:
-host1
config:
server.lables: {az: "az1",host : "host1"}
-host2
config:
server.lables: {az: "az1",host : "host2"}

2、给AZ5的机器打上reject-leader规则

label-property:
reject-leader:
- key: "dc"
value: "sha"

详细细节参考跨数据中心部署拓扑 | PingCAP 文档中心（https://docs.pingcap.com/zh/tidb/stable/geo-distributed-deployment-topology#pd-%E5%8F%82%E6%95%B0）

3、使用placement rule in sql 配置主副本leader放置规则

创建放置在az1数据的放置规则：
CREATEPLACEMENT POLICYp1 LEADER_CONSTRAINTS="+az=az1"FOLLOWER_CONSTRAINTS="{+az=az2: 1,+az=az3: 1,+az=az4: 1,+az=az5: 1}"
 
 
在百库百表下每个az约有进250+库，2500+表
 
生成更改表放置规则的sql语句,约2500+DDL
selectconcatenate（'alter table',table_achema ,'.',table_name,'placement policy = p1'frominformation_schema.tables whereright(table_schema ,2) between'00'and'24'orderbytable_schema
备注：在库已有放置规则的情况下，库下新建无放置规则的表

详细细节参考Placement Rules in SQL | PingCAP 文档中心（https://docs.pingcap.com/zh/tidb/stable/placement-rules-in-sql#placement-rules-in-sql）

三、跨城获取TSO的影响与探索

//问题描述与初步分析

压力测试中，az1、az2、az3、az4各占25%流量，流量与数据主副本leader也保持一致，但是响应延时却并不一致，结合我们看到tso wait指标比较高，我们怀疑是跨城访问pd leader的延时导致

//实测确认跨城获取TSO影响

为了确认是否是跨城获取TSO影响导致，我们主动将pd leader transfer到各个机房去做测试

测试结果表明：pd leader 切换到哪个机房后，该机房的响应延时就降低了，这也说明即使tso有预分配机制，但是跨城延时仍然对tso的获取有很大影响。

//优化方案

拆分一套集群为4套集群，这样保证每份流量所属的tidb server 都能在本机房pd leader获取tso。

四、灾难恢复与流量切流

//需求

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 -uhttp://127.0.0.1:2379
 
以az1流量为例，设置pd leader 调度策略
tiup ctl:v7.1.0pd member leader_priority pd-15
tiup ctl:v7.1.0pd member leader_priority pd-23
tiup ctl:v7.1.0pd member leader_priority pd-31
tiup ctl:v7.1.0pd member leader_priority pd-41
tiup ctl:v7.1.0pd member leader_priority pd-50
 
 
手动pd leader 切换（为避免切换后不稳定，需要先调整调度权重）
tiup ctl:v7.1.0pd member leader transfer pd3

//region leader t切换

不合理的切换方式：

第一步：
假设原放置az1的region leader需要切换到az2,执行sql获得语句，约2500+DDL
selectconcatenate（'alter table',table_achema ,'.',table_name,'placement policy = p2'frominformation_schema.tables whereright(table_schema ,2) between'00'and'24'orderbytable_schema
第二步：
执行获得的2500+个DDL
 
问题：切换时间长
数据库层操作：altertablexx placement policyaz2; -- 之前是 az1
 
最终耗时：28 分钟

优化后切换方式：

换一个思路不再更改表绑定更换规则，而是直接更改绑定的规则的内容
ALTERPLACEMENT POLICYp1 LEADER_CONSTRAINTS="+az=az2"FOLLOWER_CONSTRAINTS="{+az=az1: 1,+az=az3: 1,+az=az4: 1,+az=az5: 1}"
 
切换时常约3分钟

五、写在最后

1、poc(概念验证)是一个非常好的检验数据库能力的方式，可以帮我们验证和了解各种功能

2、本次只摘取了整个测试实战过程中碰到的三个点来分享，希望能帮助到有类似需求的TiDB用户

作者：陈卓敏| 后端开发工程师

版权声明:本文由神州数码云基地团队整理撰写，若转载请注明出处。

公众号搜索神州数码云基地，后台回复数据库，加入数据库技术交流群。