TiDB 大规模节点下线实践

2022 年 7 月 11 日
本文字数：3735 字
阅读完需：约 12 分钟

作者： dbapower 原文来源：https://tidb.net/blog/50268d49
一、背景

集群容量不够了，这些年各大公司都在做机器资源利用率的事情，我司也不例外，好不容易申请了 5 台机器加入集群扩容，balance 的正欢乐呢，Region Balance Ratio 经过了 1 天半的时间刚刚降到 93%，结果接到通知，5 台机器的交换机升级，需重启机器，网卡要做 bond。

集群配置

集群版本：v3.0.5集群配置：普通SSD磁盘，128G内存，40 核cputidb21 TiDB/PD/pump/prometheus/grafana/CCStidb22 TiDB/PD/pumptidb23 TiDB/PD/pumptidb01 TiKVtidb02 TiKVtidb03 TiKVtidb04 TiKVtidb05 TiKVtidb06 TiKVtidb07 TiKVtidb08 TiKVtidb09 TiKVtidb10 TiKVtidb11 TiKVtidb12 TiKVtidb13 TiKVtidb14 TiKVtidb15 TiKVtidb16 TiKVtidb17 TiKVtidb18 TiKVtidb19 TiKVtidb20 TiKVwtidb29 TiKVwtidb30 TiKVwtidb31  新加入的TiKVwtidb32  新加入的TiKVwtidb33  新加入的TiKVwtidb34  新加入的TiKVwtidb35  新加入的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 store2. 从集群中移除 node9，假如 store id 为 10：/home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://172.16.10.1:2379" -d store delete 102. 使用 Grafana 或者pd-ctl检查节点是否下线成功（下线需要一定时间，下线节点的状态变为 Tombstone 就说明下线成功了）：/home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://172.16.10.1:2379" -d store 103. 下线成功后，停止 node9 上的服务：ansible-playbook stop.yml -l 172.16.10.94. 编辑inventory.ini文件，移除节点信息：[tidb_servers]172.16.10.4172.16.10.5
[pd_servers]172.16.10.1172.16.10.2172.16.10.3
[tikv_servers]172.16.10.6172.16.10.7172.16.10.8#172.16.10.9  # 注释被移除节点
[monitored_servers]172.16.10.4172.16.10.5172.16.10.1172.16.10.2172.16.10.3172.16.10.6172.16.10.7172.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 0Success!

复制代码

这是能看到待下线的机器 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"  }}
或者使用apicurl 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 迁移，就可以快速下线维护, 不过也要注意风险点，尤其是写入特点是非常分散的业务，具体的看原文，本文不在赘述

文章链接：

【SOP 系列 06】临时关机维护某线上主机 TiDB 运维手册

06 临时关机维护某线上主机周跃跃 2020 年 2 月 28 日一、背景有些时候，由于硬件维护、搬移机架位等需求，需要主动关闭线上主机，时间间隔可能在几分钟到数小时之间。如果主机上运行着线上 TiDB 集群的某个组件，用户需要如何提前做好准备，减少对线上业务的影响呢。本文描述了临时维护的主机的处理方式，包含 PD，TiKV，TiDB 等各组件。二、PD 组件通常大多数的…

发布于: 刚刚阅读数: 2

原文链接:【http://xie.infoq.cn/article/82a20841c3cc58187cb670e60】。文章转载请联系作者。