re-shard和chunk migration

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

我们来发起一次添加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实例。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据