re-shard和chunk migration

添加或者删除shard，是shard的数量发生变化，叫做re-shard。re-shard会导致chunk的挪动（chunk migration），re-shard的chunk migration是将原来的chunk的序号大的部分，移动到新node上。示意图如下：

我们来发起一次添加shard节点，做re-shard：
1. 检查初始状态，在shardcat主机：

2. 在新的shard node主机（sdb4）启动schagent

3.在shardcat主机add shard node

4. deploy前检查状态：

5.运行deploy
注意deploy之前，确认新主机上的listener已经被关闭，不然的话，在deploy会报错：

在deploy的过程中，可以看re-shard已经在schedule了，注意此时的情况是sdb4正在create instance的过程中：

注意，deploy完，只是sdb4上的数据库创建完成，chunk是还没有挪完的。

6. 观察re-shard的过程，注意Ongoing chunk movement部分的变化：

注：如果deploy完之后一直是schedule状态不动，需要config shared看看是否有DDL error。

另外，需要额外提起的是，chunk migration不仅仅是在shard数量发生改变的时候，也发生在数据或者负载倾斜较大的时候(是由DBA发起)。在chunk migration的时候，chunk大部分时间是online的，但是期间会有几秒钟的时间chunk中的data处于read-only状态。

我们来手工的move一下chunk：

另一窗口：

做move shard，我们来看看对应的节点的alertlog：
节点sh1的alertlog：

节点sh21的alertlog：

从上面的alertlog，我们大致的可以看出，chunk migration的过程就是综合利用全备和增备，以及TTS的过程：
level 0备份源chunk相关的TS，还原到新shard->开始FAN（等待几秒）->将源chunk相关的TS置于read-only->level 1备份还原->chunk up(更新routing table连新shard)->chunk down(更新routing table断开源shard)->结束FAN（等待几秒）->删除原shard上的老chunk

最后我们再来看一下remove shard。

remove shard的命令，发起的时候，要求你remove的那个shard，不能有chunk在上面，不然报错：

所以我们先movechunk先。将sh21上的chunk移走：

注意此时，虽然remove chunk的命令已经执行成功，但是move chunk的动作其实还在后台进行中的。用config chunks命令检查，看到sh21上，还是有chunks在的。

我们不断运行show_reshard看其结果。直到Ongoing chunk movement部分为空，说明没有再需要move的chunk了。

这个时候看config chunks，就只看到所有的chunks在2个shard上了。此时进行remove shard：

注意此时，在sdb4上的sh21的实例，还是存在的，这个实例需要手工删除。remove shard命令不会帮你删除sh21实例。