TiDB大规模节点下线实践
一、 背景
集群容量不够了,这些年各大公司都在做机器资源利用率的事情,我司也不例外,好不容易申请了5台机器加入集群扩容,balance的正欢乐呢,Region Balance Ratio经过了1天半的时间刚刚降到93%,结果接到通知,5台机器的交换机升级,需重启机器,网卡要做bond。
集群配置
集群版本:v3.0.5 集群配置:普通SSD磁盘,128G内存,40 核cpu tidb21 TiDB/PD/pump/prometheus/grafana/CCS tidb22 TiDB/PD/pump tidb23 TiDB/PD/pump tidb01 TiKV tidb02 TiKV tidb03 TiKV tidb04 TiKV tidb05 TiKV tidb06 TiKV tidb07 TiKV tidb08 TiKV tidb09 TiKV tidb10 TiKV tidb11 TiKV tidb12 TiKV tidb13 TiKV tidb14 TiKV tidb15 TiKV tidb16 TiKV tidb17 TiKV tidb18 TiKV tidb19 TiKV tidb20 TiKV wtidb29 TiKV wtidb30 TiKV wtidb31 新加入的TiKV wtidb32 新加入的TiKV wtidb33 新加入的TiKV wtidb34 新加入的TiKV wtidb35 新加入的TiKV
缩容流程:
缩容 TiKV 节点 例如,如果要移除一个 TiKV 节点(node9),IP 地址为 172.16.10.9,可以进行如下操作: 1. 查看 node9 节点的 store id: /home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://172.16.10.1:2379" -d store 2. 从集群中移除 node9,假如 store id 为 10: /home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://172.16.10.1:2379" -d store delete 10 2. 使用 Grafana 或者pd-ctl检查节点是否下线成功(下线需要一定时间,下线节点的状态变为 Tombstone 就说明下线成功了): /home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://172.16.10.1:2379" -d store 10 3. 下线成功后,停止 node9 上的服务: ansible-playbook stop.yml -l 172.16.10.9 4. 编辑inventory.ini文件,移除节点信息: [tidb_servers] 172.16.10.4 172.16.10.5 [pd_servers] 172.16.10.1 172.16.10.2 172.16.10.3 [tikv_servers] 172.16.10.6 172.16.10.7 172.16.10.8 #172.16.10.9 # 注释被移除节点 [monitored_servers] 172.16.10.4 172.16.10.5 172.16.10.1 172.16.10.2 172.16.10.3 172.16.10.6 172.16.10.7 172.16.10.8 #172.16.10.9 # 注释被移除节点 [monitoring_servers] 172.16.10.3 [grafana_servers] 172.16.10.3 现在拓扑结构如下所示: Name Host IP Services node1 172.16.10.1 PD1 node2 172.16.10.2 PD2 node3 172.16.10.3 PD3, Monitor node4 172.16.10.4 TiDB1 node5 172.16.10.5 TiDB2 node6 172.16.10.6 TiKV1 node7 172.16.10.7 TiKV2 node8 172.16.10.8 TiKV3 node9 172.16.10.9 TiKV4 已删除 5.更新 Prometheus 配置并重启: ansible-playbook rolling_update_monitor.yml --tags=prometheus 打开浏览器访问监控平台:监控整个集群的状态
balance情况
因为balance速度过大会影响业务,此时新加入的5台机器经历近两天的时间,region balance刚降至93.9%
二、实战演练
我们对TiKV实例执行缩容操作,正常下线都是一个个下的,当时我是5个一起执行的命令,好在并没有什么异常情况出现,不过并不推荐~
现在状态都是"state_name": "Offline",没有变Tombstone
状态含义
在下线的过程中,需要迁移region,之前迁移了一天才下降5%还得反迁移回去,当时是93%差不多快2天了,执行后可以看到region balance和leader balance都反向增长
异常情况
我们发现下线迁移balance过程中,速度越来越慢
官方手册有如下一段话:
例如 Region 没均衡的情况下做下线节点操作,下线的调度与 Region Balance 会抢占 region-schedule-limit 配额,此时你可以调小 replica-schedule-limit 以限制下线调度的速度,或者设置 disable-replace-offline-replica = true 来暂时关闭下线流程。
27号14点后速度放缓,按照手册中的说明,调大replica-schedule-limit 可以加快下线调度速度,为了加快迁移速度,尽快下线,我们调大了该参数到32。
此时可以看出,调度确实有了明显的增加,但是仅仅持续了没多久,我们发现调度速度又变慢了,这是为什么呢,其实是因为调度争用导致的。
我们能够通过下图看出,replace-offline-replica的速度短暂标高,后又下降
这时我们看一下,是不是手册中说到的,region balance抢占配额
果然,14点后,balance-region又有速度了,所以问题的关键已经找到了。
三、关键性参数
关闭调度
» config set replica-schedule-limit 64
Success!
» config set region-schedule-limit 0
Success!
我们目前的场景是,balance期间,如何尽快的下线目标机器,region分布在剩余的机器中是否均衡不是我们的首要任务,因此,我们关闭region-schedule在剩余机器中的balance,尽可能大的开启控制下线调度限制的参数replica-schedule-limit。就能够实现让指定的机器尽可能快的迁移走region来完成下线。
上图能够看出,当我们将region-schedule-limit配置为0禁用region调度时,balance-region的值降值0 opm
此时,下线速度获得了大幅度的提升:
那么同理,如果我们临时也禁止leader的调度,理论上调度器io将全部交给replica-schedule-limit
因此我们执行如下命令:
» config set leader-schedule-limit 0 Success!
这是能看到待下线的机器balance速度又再次获得进一步的提升
四、效果对比
我们把时间线拉长,与最开始未进行任何优化前的下线调度速度进行对比,可以发现提升的非常明显:
验证结果
文档这里其实也是有问题的,当变成tombstone后,pd-ctl store命令是看不到tombstone节点的,除非你记得id
[tidb21 ~]$ /data1/tidb-ansible-3.0.5/resources/bin/pd-ctl -i -u http://192.168.1.248:2379 ? store 12131001 { "store": { "id": 12131001, "address": "192.168.1.249:20160", "state": 2, "version": "3.0.5", "state_name": "Tombstone" }, "status": { "capacity": "5.904TiB", "available": "5.902TiB", "leader_weight": 1, "region_weight": 1, "start_ts": "2020-08-25T10:59:57+08:00", "last_heartbeat_ts": "2020-08-28T10:49:55.144024892+08:00", "uptime": "71h49m58.144024892s" } } 或者使用api curl pd-addr:port/pd/api/v1/stores?state=2
当然,监控也是能看到结果的
五、相关知识点
offline到tombstone这个过程本身是比较缓慢的,因为下线迁移的scheduler要和region balance scheduler抢占资源 缩容是指预备将某个 Store 下线,通过命令将该 Store 标记为 “Offline“ 状态,此时 PD 通过调度将待下线节点上的 Region 迁移至其他节点。 故障恢复是指当有 Store 发生故障且无法恢复时,有 Peer 分布在对应 Store 上的 Region 会产生缺少副本的状况,此时 PD 需要在其他节点上为这些 Region 补副本。 这两种情况的处理过程基本上是一样的。replicaChecker检查到 Region 存在异常状态的 Peer后,生成调度在健康的 Store 上创建新副本替换异常的副本。 系统中同时运行有其他的调度任务产生竞争,导致 balance 速度上不去。这种情况下如果 balance 调度的优先级更高,可以先停掉其他的调度或者限制其他调度的速度。例如 Region 没均衡的情况下做下线节点操作,下线的调度与 Region Balance 会抢占 region-schedule-limit 配额,此时你可以调小 replica-schedule-limit 以限制下线调度的速度,或者设置 disable-replace-offline-replica = true 来暂时关闭下线流程。
五、后续操作
后面的操作就很常规了
停止节点
[sync360@tidb21 tidb-ansible-3.0.5]$ ansible-playbook stop.yml -l xx.xx.xx.xx,xx.xx.xx.xx,xx.xx.xx.xx,xx.xx.xx.xx,xx.xx.xx.xx
编辑inventory.ini
注释相关节点
重启监控
ansible-playbook rolling_update_monitor.yml --tags=prometheus
其实重启监控也一样能看到节点还是处于tombstone状态,这块也需要人为的去pd-ctl里删除,手册也写得不全,尤其是我们这个案例,是要重启后再加回集群的,不删除再加回来肯定后续信息会有异常
stores remove-tombstone
Tips:迁移完成后,不要忘记调回region-balance-limit和leader-balance-limit
调回参数后,各节点开始balance,直到评分一致
六、思考
本案例我们通过优化参数,达到大幅度提升下线调度速度,本案例是新加入集群的机器正在调度,且执行了store delete操作后的优化思路,但其实还有更优解:
临时下线维护操作:
主要利用tidb里只有leader提供服务
迁出leader比迁移region快很多,同时调整downtime阈值,避免region迁移,就可以快速下线维护,不过也要注意风险点,尤其是写入特点是非常分散的业务,具体的看原文,本文不在赘述
文章链接:
https://asktug.com/t/topic/33169
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
【AWS征文】AWS Lambda 借助 Serverless Framework,迅速起飞
前言 微服务架构有别于传统的单体式应用方案,我们可将单体应用拆分成多个核心功能。每个功能都被称为一项服务,可以单独构建和部署,这意味着各项服务在工作时不会互相影响 这种设计理念被进一步应用,就变成了无服务(Serverless)。「无服务」看似挺荒唐的,其实服务器依旧存在,只是我们不需要关注或预置服务器。这让开发人员的精力更集中——只关注功能实现 Serverless 的典型便是 AWS Lambda AWS Lambda 如果你是 Java 开发人员,你应该听说过或使用过 JDK 1.8 里面的 Lambda,但是 AWS 中的 Lambda 和 JDK 中的 Lambda 没有任何关系 这里的 AWS Lambda 就是一种计算服务,无需预置或管理服务器即可运行代码,借助 Lambda,我们几乎可以为任何类型的应用程序或后端服务运行代码,而且完全无需管理,我们要做的只是上传相应的代码,Lambda 会处理运行和扩展 HA 代码所需的一切工作 说的直白一点 Lambda 就好比实现某一个功能的方法 (现实中,通常会让 Lambda 功能尽可能单一),我们将这个方法做成了一个服务供调用...
- 下一篇
Serverless Spark的弹性利器 - EMR Shuffle Service
背景与动机 计算存储分离下的刚需 计算存储分离是云原生的重要特征。通常来讲,计算是CPU密集型,存储是IO密集型,他们对于硬件配置的需求是不同的。在传统计算存储混合的架构中,为了兼顾计算和存储,CPU和存储设备都不能太差,因此牺牲了灵活性,提高了成本。在计算存储分离架构中,可以独立配置计算机型和存储机型,具有极大的灵活性,从而降低成本。 存储计算分离是新型的硬件架构,但以往的系统是基于混合架构设计的,必须进行改造才能充分利用分离架构的优势,甚至不改造的话会报错,例如很多系统假设本地盘足够大,而计算节点本地盘很小;再例如有些系统在Locality上的优化在分离架构下不再适用。Spark Shuffle就是一个典型例子。众所周知,Shuffle的过程如下图所示。 每个mapper把全量shuffle数据按照partitionId排序后写本地文件,同时保存索引文件记录每个partition的offset和length。reduce task去所有的map节点拉取属于自己的shuffle数据。大数据场景T级别的shuffle数据量很常见,这就要求本地磁盘足够大,导致了跟计算存储分离架构的冲突。...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Windows10,CentOS7,CentOS8安装Nodejs环境
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Hadoop3单机部署,实现最简伪集群