redis-data-migrate

3.1   aof不是幂等的

aof不像binlog那样可以重做 redolog, binlog 记录的操作是 幂等(idempotent) 的, 意味着如果失败了, 可以重做一次.

这是因为binlog记录的是操作的结果, 比如:

op                  log
---------------------------
set x 0             x = 0
incr x              x = 1
incr x              x = 2

但是redis的aof记录的是操作:

op                  log
---------------------------
set x 0             x = 0
incr x              incr x
incr x              incr x

这就是说, 如果我们在重放aof的过程中出错(比如网络中断):

• 不能继续(不好找到上次同步到哪),
• 也不能重新重放一次, (incr两次, 值就错了)

只能清除目标集群的数据重新迁移一次 ( redis-mgr 里面有 clean-keys 命令按照前缀清除)

不过, 好在redis单实例的afo数据都不大, 一般10G左右, 重放大约20min就能完成, 出错的概率也很小. (这也是redis可以这样做, 而其他持久存储比如mysql, mongo必须支持断点同步的原因)

3.2   切流量时的不一致

前面说的步骤是:

1. 追aof
2. 追上后, 切流量.

追aof是一个动态的过程, 追上后, 新的写操作马上就来, 所以这里追上的意思是说, 新的写入马上会被消化掉.

但是考虑这样一种场景:

假设client上做对x做两次set(一个机器上做两次, 或者两个app-server上分别做):

client          old_cluster         new_cluster
-----------------------------------------------
set x 1(a)      set x 1(客户操作)
-----------------------------------------------> 切流量到new_cluster
set x 2(b)                          set x 2 (客户操作)
                                    set x 1 (b 操作被重放到 new_cluster)

a操作还没同步到new_cluster, 流量就已经切到了new_cluster, 这时候对同一个key的更新, 会被老集群上的操作覆盖掉.

解决:

• 这个短暂的不一致, 对多数业务, 是能容忍的(很少有业务会高速更新同一个key)
• 如果非要达到一致, 当追aof追上后, app-server停写, 等待彻底追上(此时老集群的aof不会有更新了), 然后再切流量.

4.1   redis-mgr 集成

redis-mgr 里面集成了一个命令来方便操作:

#从cluster1迁移到cluster5
./bin/deploy.py cluster1 replay_aof cluster5 'prefix_'