TiDB中kv的扩容和缩容

下面是本次测试环境服务器的概况，一共四台机，其中三个KV。按照默认的副本数，一共有三个，也就是说可以允许我的KV能挂掉一个而不影响业务。下面我们来测试一下三种的情况：

1. 在三个kv的情况下，直接挂掉一个看下服务是否还正常。
2. 扩容一个kv，看下regions和 leader的转移的情况。
3. 缩容一个kv，看下regions和 leader的转移的情况，并查看能不能缩容成功。

组件	CPU	内存	IP地址	主机名
TiDB	2核+	4 GB+	192.168.113.20	tidb01
PD	2核+	4 GB+	192.168.113.20	tidb01
TiKV	2核+	4 GB+	192.168.113.21	tikv01
TiKV	2核+	4 GB+	192.168.113.22	tikv02
TiKV	2核+	4 GB+	192.168.113.23	tikv03

1.1 模拟一个kv宕机的情况

我们的测试方法很简单，首先新建一个测试表并插入数据；然后直接kill掉kv的进程，模拟宕机；然后再登录TiDB看下数据是否还在，能否做插入、删除的操作。

1. 新建测试表，并插入数据。

use test;
create table tb_test1 (
id int,
user_name VARCHAR(20)
)

insert into tb_test1 VALUES (1,'test1');
insert into tb_test1 VALUES (2,'test2');
insert into tb_test1 VALUES (3,'test3');

select查询确认数据

select * from tb_test;

这时候我们看grafana的tv监控页面，看到leader的分布是很不均匀的，这里我们不探讨。下面我们把tikv_2给kill了看下。

grafana监控面板的显示内容

2. kill掉tikv进程模拟tikv挂掉的情况

   
   主机名与实例名称的对应关系

在这里我们要kill的是tikv_2，这里刚好对应的是我的tikv主机IP较小的那个（192.168.113.21）

ps aux |grep tikv-server|grep -v grep|awk '{print $2}'|xargs kill

这样kill掉之后，很快tikv会自己重启启动的，这样的没办法很好地测试的。所以干脆，我直接把tikv_1的服务器给shutdown了，看下是什么样的一个情况。
在grafana的监控面板上我们可以看到有一个tikv down了，还有该服务器上的探测器。

我们看下tikv的leader的情况，可以看到已经有部分的leader转移到tikv_1和tikv_7上了，我们看下那个测试表的数据。

在挂了一个kv的情况下，还是可以正常地插入和删除数据的，也就是说TIDB还是正常运作的。

select * from tb_test1;
insert into tb_test1 VALUES (4,'test4');
delete from tb_test1 where id=1;
select * from tb_test1;

测试结束后我们开启虚拟机，并重新把tikv01上的tikv的服务打开。

ansible-playbook start.yml -l 192.168.113.21

启动后我们还发现了kv的leader并没有转移回给tikv_2上，leader的分布还是很不均匀。

1.2 扩容一个Tikv

这里我们新增一个kv，新增的一个虚拟机的配置情况如下

组件	CPU	内存	IP地址	主机名
Tikv	2核+	4 GB+	192.168.113.24	tikv04

1. 新增tikv实例
   编辑hosts.ini以及inventory.ini文件，增加一个tikv的IP地址。

[servers]
192.168.113.20
192.168.113.21
192.168.113.22
192.168.113.23
192.168.113.24
...

[tikv_servers]
192.168.113.21
192.168.113.22
192.168.113.23
192.168.113.24
...
[monitored_servers]
192.168.113.20
192.168.113.21
192.168.113.22
192.168.113.23
192.168.113.24
...

使用ansible来初始化并部署tikv

#新建tidb用户
ansible-playbook -i hosts.ini -l 192.168.113.24 create_users.yml -u root -k
#部署ntp服务
ansible-playbook -i hosts.ini -l 192.168.113.24 deploy_ntp.yml -u tidb -b
#初始化服务器配置
ansible-playbook bootstrap.yml -l 192.168.113.24
#部署tikv
ansible-playbook deploy.yml -l 192.168.113.24
#启动tikv
ansible-playbook start.yml -l 192.168.113.24
#更新 Prometheus 配置并重启：
ansible-playbook rolling_update_monitor.yml --tags=prometheus

几分钟后我们就可以在grafana上看到新增的tikv实例了，我们看下他的实例名称，以及leader和regions的数量。

tikv实例名和主机名的对应关系 leader及regions的数量

从上图我们可以看到新增的tikv的实例叫做tikv_2006，并且已经有region转移到这个实例上了，但是分布还是不均匀，我们等待一段时间看下。
半个钟之后，发现tikv_2006还只是获得6个region。这个问题我们后续再讨论，这里继续下面的缩容实验。

1.3 缩容一个Tikv

现在我们有4个Tikv了，下面我们缩容一个，只保留三个。我们对实例名为tikv_1也就是192.168.113.22这台服务器下手吧，缩容的过程也命令非常简单。

对leader数量最多的tikv_1下手

1. 使用 pd-ctl 从集群中移除节点：

查看 192.168.113.22节点的 store id，查询到的store id为1，也就是tikv_1，这就是它的实例名称。

/home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://192.168.113.20:2379" -d store

从集群移除store id 为 1的tikv：

/home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://192.168.113.20:2379" -d store delete 1

使用 Grafana 或者 pd-ctl 检查节点是否下线成功（下线需要一定时间，下线节点的状态变为 Tombstone 就说明下线成功了,这个时间可能非常久）：

/home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://192.168.113.20:2379" -d store 1

等待了几分钟，下线成功。

墓碑状态 下线成功后的leader和region的分布情况

下线成功后，停止192.168.113.22 上的服务，没下线成功请不要进行下面的操作，耐心等待。

ansible-playbook stop.yml -l 192.168.113.22

编辑 inventory.ini 文件，移除节点信息：

[tikv_servers]
192.168.113.21
#192.168.113.22
192.168.113.23
192.168.113.24
...
[monitored_servers]
192.168.113.20
192.168.113.21
#192.168.113.22
192.168.113.23
192.168.113.24
...

更新 Prometheus 配置并重启：

ansible-playbook rolling_update_monitor.yml --tags=prometheus

打开浏览器访问监控平台：http://192.168.113.20:3000，监控整个集群的状态。

1.4 处理 Tombstone Stores 监控条目

在进行tikv的缩容后，grafana的页面上会出现墓碑状态数量为1的情况。在确认下线之后，我们还要处理这个监控，否则这里会干扰我们监控的准确性。一是这个状态很碍眼，明明我都下线成功了为什么这个状态还没有消除；二是 Leader balance 和 Region Balance的判断把墓碑状态的实例数据也算进去，导致这个数据一直都是100%。

墓碑状态

去除这个监控数据的关键在于如何删除pd上的墓碑节点，在旧版本（2.1.17及3.0.0版本）中，这样的节点没办法删除的，在新版本中我们可以使用pd-ctl工具进行删除。

./pd-ctl -u 192.168.113.20:2379 -d stores remove-tombstone

就这样我们就可以把墓碑状态的节点删除了，但是删除后 Leader balance和 Region Balance还没有恢复正常，在prometheus中还是监控到墓碑节点的数据，最后重启pd（生产环境下慎用）解决。

最后的状态