黄东旭解析 TiDB 的核心优势
654
2023-11-24
在某地震多发省,为了避免地震造成的机房级灾难,或者城市级灾难,导致整个系统不可用,拟建设一套三地五中心五副本分布式高可用数据库系统,保证高可用需求。
在该系统中需要接入不同地区的应用流量,做流量单元化处理,且前期应用开发已经采用了百库百表的水平分库表策略。为尽可能减少应用和数据库延迟、数据库计算层向存储层跨机房跨城取数延迟,需要做到业务流量与对于数据分片leader在同一个机房。
共12台阿里私有云托管物理机,其中10台用作部署集群,2台用作部署同测试HTAP能力和扩容实践。
单台配置如下:
配置项配置信息系统内核版本麒麟v10、arm架构cpu海光 64c(已超线程)内存512GB磁盘4*nvme *** 3TBtidb版本v7.1.0(存在小bug)-->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)
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 文档中心
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 文档中心
压力测试中,az1、az2、az3、az4各占25%流量,流量与数据主副本leader也保持一致,但是响应延时却并不一致,结合我们看到tso wait指标比较高,我们怀疑是跨城访问pd leader的延时导致
为了确认是否是跨城获取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
不合理的切换方式:
第一步: 假设原放置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交付服务,涵盖金融、证券、物流、电力、政府、零售等重点行业。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。