写点什么

三地五中心,TiDB POC 最佳姿势探索

  • 2023-09-29
    北京
  • 本文字数:3017 字

    阅读完需:约 10 分钟

原文来源:https://tidb.net/blog/b4732d88

POC 测试背景

在某地震多发省,为了避免地震造成的机房级灾难,或者城市级灾难,导致整个系统不可用,拟建设一套三地五中心五副本分布式高可用数据库系统,保证高可用需求。在该系统中需要接入不同地区的应用流量,且前期应用开发已经采用了百库百表的水平分库表策略。为尽可能减少应用~ 数据库延迟、数据库计算层向存储层跨机房跨城取数延迟,需要做到业务流量与对于数据分片 leader 在同一个机房。

POC 测试项

# 敏感信息已脱敏,测试用例信息可作为参考与学习


测试环境信息

机器软件环境配置

共 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 地数据中心架构有如下需求:


  1. db_00-24 这 25 个库的 leader 在 AZ1,db_25-49 这 25 个库的 leader 在 AZ2,db_50-74 这 25 个库的 leader 在 AZ3,db_75-99 这 25 个库的 leader 在 AZ4

  2. AZ5 不能有 Leader,即使前面 4 个 AZ 任意一个故障,AZ5 也不能 Leader

  3. 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+DDLselect 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 5tiup ctl:v7.1.0 pd member leader_priority  pd-2 3tiup ctl:v7.1.0 pd member leader_priority  pd-3 1tiup ctl:v7.1.0 pd member leader_priority  pd-4 1tiup 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+DDLselect 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 交付服务,涵盖金融、证券、物流、电力、政府、零售等重点行业。


发布于: 刚刚阅读数: 3
用户头像

TiDB 社区官网:https://tidb.net/ 2021-12-15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
三地五中心,TiDB POC最佳姿势探索_7.x 实践_TiDB 社区干货传送门_InfoQ写作社区