tendis存储版集群模式下，对于搬迁有一些需要特殊处理的点。

搬迁的时序：

  • 获取HighestBinlogId作为起始binlogid
  • txn获取快照
  • 用txn快照创建游标，遍历发送到从。
  • 追binlogid
  • lockchunk
  • 获取MaxBinlogId作为结束binlogid，并且不能用之前的快照txn获取。
  • 最后一次追binlog
  • unlockchunk

注意：

  • 步骤1需要在步骤2之前获取kvstore->getHighestBinlogId()，或者直接用步骤2的txn快照获取getMaxBinLog(txn)。
  • 步骤6需要在lockchunk之后获取，并且不能用快照getMaxBinLog(txn)获取，要用kvstore->getHighestBinlogId()获取。

TTL

  • 对于list，hash，set，zset的ttl，因为TTLIndex不在同一个chunk，无法发送到目标节点，需要在目标节点按RecordValue中的ttl恢复TTLIndex。
  • 对于追加binlog过程中的expire，会随着binlog发送到目标节点，并被添加到rocksdb里面去。要注意chunkid设置为MULTI的逻辑。
  • 对于kv的ttl，不用恢复.
  • 对于混存版本，redis层会对expire转化为delete操作，所以Tendis存储版这一层通常是关闭expire功能的。
  • 在ttlindex恢复之后，二级key还在搬迁的过程中，此时扫描线程来删数据，可能有问题。因此，搬迁过程中，停止主动过期。

主从同步

目标节点的主和从

  • 主节点接受快照的keyvalue，通过可以生成binlog的接口设置，这样可以同步给从。
  • 主节点追加的<ReplLogKeyV2,ReplLogValueV2>需要重新设置binlogid，并能够实时同步到从
  • 从节点收到结束搬迁的binlog，需要设置cluster模块中slots的归属。

源节点的主和从：

  • 主节点在搬迁结束进行deleteChunk的时候，需要调用可以生成binlog的删除接口，这样删除操作才能同步到从节点。
  • 从节点收到结束搬迁的binlog，需要设置cluster模块中slots的归属。
  • 数据清理统一交给GC模块处理

slaveof no one

  • 源节点的主在delteChunk阶段挂掉，那么源节点的从就含有多余的没来得及删掉的key。目标节点在搬迁过程中挂掉，那么目标节点的从就含有未生效的key。
  • 为了解决这两种情况，统一交给GC模块处理

deleteChunk保护

importing命令需要判断该slot不能正在执行deletChunk操作。（wayenchen）

versionEP

versionEp在搬迁的最后，都需要同步到目标节点

FLUSH

flush操作以store为单位，但是搬迁却以chunkid为单位。但在搬迁过程中，会一致持有store的IS锁，所以flush操作是会被阻塞。也就是说，搬迁过程中，无法执行flushdb/flusall.