源端为集群模式，具体不能开启move slot操作的原因是什么？ about redisshake HOT 9 CLOSED

move slot将会在源节点delete key，在目的节点restore key，目前redis-shake是按db并发的，这就代表着db之间的严格顺序一致性是没办法保证（先delete 再restore，反过来则不行），而这个也是move slot中必须要保证的。

from redisshake.

再请教下， 比如有个场景：
1.源端集群中发生了move slot，A节点delete key，B节点restore key
2.redis shake获取了这两个操作，然后同步目标集群
3.目标集群中，先B1节点restore key，再A1节点delete key
这时看上去也不会出现数据丢失的情况，是不是我的理解不正确，能帮忙解答下吗，歇息了。

from redisshake.

你说的是可以的，但是问题是如何保证A和B的操作哪个先执行？由于现在是并发执行的，没有一个全局序，这个happened-before关系没办法维护

from redisshake.

我的困惑是，不管目前集群先delete还是先restore，因为这两个操作是发生在不同节点上的，所以看这个过程并不会产生数据的丢失；如果这两个操作在同一节点，的确存在因为先restore后delete后，导致数据丢失。能否帮忙解答下这个疑惑点，谢谢了。

from redisshake.

对于源端是在不同的db结点，目的端不一定，源端和目的端的分片分布是不一定的，db个数也不一定一样

from redisshake.

再请教下，同步过程中，如果源端的一个master挂了，其对应的slave被选举成新的master，redis-shake会从这个新的master进行同步吗？redis-shake是已经实现了这个机制了吗？

from redisshake.

failover机制目前没有，如果是sentinel可以配置，后续将会加上hypervisor机制，这样重启就会从新master拉取。但是拉取将会重新触发全量，挺多用户对此不好接受，所以目前增量重连机制还没做，没有特别合适的方案。

from redisshake.

请教下，redis-shake是如何避免循环写入，两个机房的redis需要互相同步，会出现在A机房写入，同步到B机房，监听B机房的redis-shake感知到变化后，又同步回A机房吗？

from redisshake.

会的，目前没有循环写入避免的机制。跟标题不相关的问题，重新开一个issue吧

from redisshake.