假冒彩票网站开发,wordpress 密码查看,delphi做网站开发,wordpress 彩色标签云目录 一、POC测试背景
//测试环境信息
二、流量单元化控制
//需求
//解决方案
三、跨城获取TSO的影响与探索
//问题描述与初步分析
//优化方案
四、灾难恢复与流量切流
//需求
//pd leader 切换
//region leader t切换
五、写在最后 一、POC测试背景 在某地震多发省…目录 一、POC测试背景
//测试环境信息
二、流量单元化控制
//需求
//解决方案
三、跨城获取TSO的影响与探索
//问题描述与初步分析
//优化方案
四、灾难恢复与流量切流
//需求
//pd leader 切换
//region leader t切换
五、写在最后 一、POC测试背景 在某地震多发省为了避免地震造成的机房级灾难或者城市级灾难导致整个系统不可用拟建设一套三地五中心五副本分布式高可用数据库系统保证高可用需求。
在该系统中需要接入不同地区的应用流量做流量单元化处理且前期应用开发已经采用了百库百表的水平分库表策略。为尽可能减少应用和数据库延迟、数据库计算层向存储层跨机房跨城取数延迟需要做到业务流量与对于数据分片leader在同一个机房。 //测试环境信息 机器软件环境配置
共12台阿里私有云托管物理机其中10台用作部署集群2台用作部署同测试HTAP能力和扩容实践。
单台配置如下 机器与空间信息
共有三个城市cd、ya、lz
五个机房cd有两个机房AZ1、AZ2ya有两个机房AZ3、AZ4lz有一个机房AZ5
延迟同城两机房延时小于1mscd与ya两地延时3mscd与lz两地延时7ms;ya与lz两地延时9ms
机器放置拓扑每个机房两台机器 二、流量单元化控制 //需求 3地数据中心架构有如下需求 db_00-24 这 25 个库的 leader 在 AZ1db_25-49 这 25 个库的 leader 在 AZ2db_50-74 这 25 个库的 leader 在 AZ3db_75-99 这 25 个库的 leader 在 AZ4AZ5 不能有 Leader即使前面 4 个 AZ 任意一个故障AZ5 也不能 Leader5 副本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_CONSTRAINTSazaz1FOLLOWER_CONSTRAINTS{azaz2: 1,azaz3: 1,azaz4: 1,azaz5: 1}在百库百表下每个az约有进250库2500表生成更改表放置规则的sql语句,约2500DDL
selectconcatenatealter table,table_achema ,.,table_name,placement policy p1frominformation_schema.tables whereright(table_schema ,2) between00and24orderbytable_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:vCLUSTER_VERSIONpd -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获得语句约2500DDL
selectconcatenatealter table,table_achema ,.,table_name,placement policy p2frominformation_schema.tables whereright(table_schema ,2) between00and24orderbytable_schema
第二步
执行获得的2500个DDL问题切换时间长
数据库层操作altertablexx placement policyaz2; -- 之前是 az1最终耗时28 分钟 优化后切换方式
换一个思路不再更改表绑定更换规则而是直接更改绑定的规则的内容
ALTERPLACEMENT POLICYp1 LEADER_CONSTRAINTSazaz2FOLLOWER_CONSTRAINTS{azaz1: 1,azaz3: 1,azaz4: 1,azaz5: 1}切换时常约3分钟 五、写在最后 1、poc(概念验证)是一个非常好的检验数据库能力的方式可以帮我们验证和了解各种功能
2、本次只摘取了整个测试实战过程中碰到的三个点来分享希望能帮助到有类似需求的TiDB用户 作者陈卓敏| 后端开发工程师 版权声明:本文由神州数码云基地团队整理撰写若转载请注明出处。
公众号搜索神州数码云基地后台回复数据库加入数据库技术交流群。
