前言

最近做了个集群TiKV节点缩容的操作，开始前本来是信心满满，毕竟当初刚接触TiDB的时候，这缩容操作做的次数可不少，本以为是个手到擒来的工作，可是在实际操作过程中，还是遇到了不少自己在初学的时候没有注意到的点。

比如说tikv的Tombstone状态、修改PD参数、在PD中删除Tombstone状态的TiKV节点等，写操作文档的时候遇到各种磕磕绊绊，请教前辈、查官网一步步做下来。不过好在实际操作过程中一切顺利。在此将缩容TiKV的操作步骤分享出来，给和我一样的各位初学者和没有做过类似操作的同学一个参考。也希望如果有幸被哪位大佬看到，辛苦帮我查漏补缺！

架构与背景

集群架构：

缩容前集群架构：9TiDB server + 3PD server + 14TiKV server

预期缩容后集群架构： 9TiDB server + 3PD server + 10TiKV server

需求背景：

因生产环境资源较紧张，经评估集群的数据量不是很大，可以缩容出来几个TiKV节点临时挪用，待集群的数据量增长到一定程度，再把TiKV给扩容出来。

整个缩容步骤做完大概花了6小时左右，之前在学习TiDB的时候，做个缩容TiKV的操作，可能也就是一小时不到。之所以耗费了这么久的时间，主要是在等待集群balance。

balance这一步，主要是TiKV节点缩容命令执行完成后，这些节点中的数据将被调度到其他节点，如果数据量大的话，就需要等待久一些（我在做的时候，集群的数据量是7T左右，balance阶段耗时在五小时左右）。

接下来我先讲讲缩容的具体过程，有一些注意事项，或者是在做实验的时候不会去关注到的点，我放在文章的最后。

缩容具体过程

1、查看现有集群节点及其状态：

su - tidb

tiup cluster display tidb-test

2、确认需缩容的节点实例情况：

确认需缩容的节点为10.3.65.141:20161

3、检查关键指标

缩容前，登录grafana监控界面，检查检查集群region health、region leader分布情况，磁盘io、内存、cpu及集群负载等各项关键指标是否正常。

（因为需要缩容的节点是我刚才在测试集群扩容出来的，所以监控曲线有些升高，对缩容无影响，暂且忽略。如果是在生产环境操作，需排查清楚各项指标升高原因，确认处理完毕恢复正常或对缩容无影响再做操作）

4、修改PD参数，加快balance进度

/tidb-data1/pd/tidb-deploy/pd-2379/bin/pd-ctl -i -u http://127.0.0.1:2379

·查看参数

» config show » store limit（将集群原参数设置保留一份，修改如果出现问题可迅速修改回原参数）

·修改参数

» config set max-pending-peer-count 256（控制单个 store 的 pending peer 上限，防止在部分节点产生大量日志落后的 Region。需要加快补副本或 balance 速度可以适当调大这个值，设置为 0 则表示不限制。）

» config set replica-schedule-limit 512 （可以控制同时进行 replica 调度的任务个数。这个配置主要控制节点挂掉或者下线的时候进行调度的速度，值越大调度得越快，设置为 0 则关闭调度。Replica 调度的开销较大，一般不建议将此值设置过大，但我这是测试集群，设置值大一些加快速度。）

» store limit all 800 add-peer（设置所有 store 添加 peer 的速度上限为每分钟 800 个）

» store limit all 20000 remove-peer（设置所有 store 删除 peer 的速度上限为每分钟20000个）

·如有问题，回滚原参数

5、开始缩容：

使用screen工具执行，因为缩容过程命令可能会执行很久，防止因意外导致链接断开，命令执行失败：

screen -S test

tiup cluster scale-in tidb-test -N 10.3.65.141:20161

命令执行过程中，关注集群监控，检查leader与region是否平滑迁出缩容的tkv实例，region health、leader region分布状态，磁盘io使用状态，内存使用情况。

缩容前集群各项监控指标：

缩容命令执行完成后集群各项监控指标：

从监控图可以看出，集群已经开始迁移副本，数据量越大，迁移副本耗时越久。迁移副本过程中，需要关注集群关键指标，出现问题及时处理。

6、节点缩容完成后，检查集群状态：

tiup cluster display tidb-test

确认已经缩容的节点状态为Tombstone，同时登录grafana监控界面，进入overview–>TiKV面板，查看leader及region分布情况，确认迁移副本调度完成。

确认balance完成，开始执行清理命令

tiup cluster prune tidb-test

tiup cluster display tidb-test

至此集群已经缩容完成，缩容后的集群符合预期，但还需进入pd删除tombstone组件，否则grafana监控还会记录tombstone kv。

检查是否有tombstone组件：

./pd-ctl store --state Tombstone

./pd-ctl store remove-tombstone

./pd-ctl store --state Tombstone

清理完成：

登录grafana监控面板，查看集群各项健康指标是否正常，节点数量是否符合预期。

集群组件状态正常，节点数量符合预期。

最后将PD参数调整回集群原参数。

#将PD参数调整回原参数

/tidb-data/pd/tidb-deploy/pd-2379/bin/pd-ctl -i -u http://127.0.0.1::2379

» config set max-pending-peer-count 16

» config set replica-schedule-limit 64

» store limit all 15 add-peer

» store limit all 15 remove-peer

#检查参数

» config show » store limit

确认集群参数已经修改至缩容前状态。至此，TiKV节点已缩容完毕。

注意事项

我在最后做总结的时候，发现一部分操作步骤比较重要，或者说是像我一样初学者在做实验的时候，比较容易遗漏的几个点：

1、关于参数

在缩容开始之前，如果集群的数据量较大，可以去调整一些PD参数，来加快迁移副本进度。具体的参数因人而异，大家可以去官方文档 中找找。我调整的那部分参数，也可以拿来参考，但是在调整参数之前，一定得将原参数值保留一份，以防万一参数调整出问题的话，及时回退。

2、关于集群

需要等待集群迁移副本，这一步是比较容易遗漏的操作，因为我们用来做实验的集群，可能没什么数据量，这一步耗时很短，不会去刻意等待，或者是在做的时候，就不会想到这一步。

3、关于状态

在缩容完成之后，需要在PD中删除状态为Tombstone的节点，否则grafana监控还会记录tombstone kv，这一步我们在做实验的时候，也是不会去特别关注的点。

至此，我的这个缩容操作已经讲完了，中间添加了一些做的时候自己的理解，各位大佬如果有什么想要补充的，或者是发现我有写的不对的地方，欢迎补充~

版权声明:本文由神州数码云基地团队整理撰写，若转载请注明出处。
公众号搜索神州数码云基地，后台回复Odoo，加入Odoo技术交流群！