Redis: 集群高可用之故障转移和集群迁移

故障转移

故障转移，包括自动故障转移和手动故障转移

1 ）自动故障转移

• Redis 集群，主节点挂了，从节点可以顶上来继续提供服务
• 常用制造故障的两种方式
  • 第一，对其中一个节点进行 SHUTDOWN 操作
  • 第二，kill 掉主节点的Redis进程
• 当主节点挂掉之后，基于配置的时间，针对这个配置项 cluster-node-timeout，比如15000
• 当 15 s 过去后，从节点接收到主节点下线的通知，就会开始顶替主节点
• 顶替的过程是
  • 在从节点内部进行选举
  • 之后，开启 failover 故障迁移，每个 failover 都会记录当前纪元的时期
  • 选举成功，就会把纪元相关信息记录至配置文件中
  • 丢弃之前主节点的缓存状态信息
  • 更改 master_replid 和 master_replid2 的信息
  • 集群状态标记为成功
• 这时候，从节点就会变为主节点，当之前下线故障的主节点再次上线时
• 之前的主节点就会成为新的主节点的从节点
  • 同样，这个节点的日志信息会记录相关的工作流程
• 在这个过程中，数据也不会丢失

2 ) 手动故障转移

• 有的时候，在主节点没有任何问题的情况下，我们可能需要对这个主节点做出一个处理
• 比如，现在希望把当前的这个服务器停了，但这个服务器上跑着一个Redis集群里的主节点
• 如果按照之前的办法
  • 先把这个槽都转移出去，再把这个主节点删了
  • 最后，在别的地方找一个新的主节点，再把这个槽重新分配
  • 这个过程，想想都很麻烦
• 找一个更安全/更便捷的把这个服务器上的节点做一个降级的处理
  • 降级了之后，删除从节点 del-node 即可
• 可以通过手动故障转移来满足我们的需求
• 手动故障转移会比自动故障转移要更加的安全
  • 因为前提条件就是现在环境是稳定的
  • 已经确保了主从之间的数据是一致的，都已经完全复制了
  • 在这种情况下，去做故障转移的话，肯定是避免了数据的丢失
• 然后它是怎么来完成的呢？
  • 只需要在这个从节点里边去执行 CLUSTER FAILOVER
  • 然后这个从节点就会升级为主节点
  • 而它原来对应的那个主节点就会降级变成从节点
  • 整个过程是非常简单的
• 比如: 之前，101:6371 是从节点，102:6374 是主节点，直接执行下面命令
  • $ /usr/local/redis/bin/redis-cli -c -a 123456 -h 192.168.10.101 -p 6371 cluster failover
• 执行完上述命令后，可看集群状态
  • $ /usr/local/redis/bin/redis-cli -c -a 123456 -h 192.168.10.101 -p 6372 cluster nodes
  • 这时候可以发现，101:6371 变成了主节点，102:6374变成了从节点
• 之后可以分析下 101:6371 和 102:6374 的日志，里面隐藏了所有的变更流程

集群迁移

• 集群迁移，就是把集群的数据备份迁移到另外的一个完整的集群环境中
• 这里面涉及很多的概念
  • 比如说把一个单个的节点迁移到一个集群环境中
  • 或者说把集群的环境里边的数据迁移到某个单个的节点
  • 或者说把主从哨兵迁移到另外的一个主从哨兵或者迁移到另外一个集群等等
• 我们主要关注
  • 把一个正在运行的集群迁移到另外一个完整的集群结构中去
  • 就是集群到集群这样的一个过程
• 迁移的两种方式
  • 一个是手动迁移
    • 注意，如果哪一步做错了，肯定会带来很严重的后果
  • 一个是使用工具来迁移
    • 为了降低出错率可以使用成熟稳定的第三方工具，如：Redis-Shark

1 ）手动迁移

• 这里有两种情况
  • 原集群与目标集群结构一致
  • 原集群与目标集群结构不一致

1.1 原集群与目标集群结构一致

• 可通过 check 命令检查集群状态
  • $ /usr/local/redis/bin/redis-cli -a 123456 --cluster check 192.168.10.101:6371
  • 可以看到集群内主节点和相关槽的数量
• 如果两个集群的上述主节点和相关槽数量一致，则为结构一致
• 这种情况下怎么做迁移呢
  • 1 ）有密码的话，取消密码
  • 2 ）创建新的集群(与原集群目标一致)，或集群已经存在
  • 3 ）停掉目标集群的服务
  • 4 ）删除目标集群所有节点的 AOF 和 RDB 文件
  • 5 ）原集群数据持久化
    • 如果用RDB恢复就 BGSAVE
    • 如果用AOF恢复就 BGREWRITEAOF
  • 6 ）复制源集群所有节点 RDB或AOF 文件到目标集群对应的节点
  • 7 ）启动新集群并设置密码
  • 8 ）检查状态，迁移完毕

1.2 原集群与目标集群结构不一致

• 比如说原集群现在是3个节点，目标集群是5个节点或者7个节点，假如是5个节点
• 无非就是现在的5个主节点共同有 16384 个槽，原集群只有3个主节点和 16384 个槽
• 可以把原集群这些槽全部都转移到一个节点上，目标集群也同样的操作
• 将原集群这个节点的数据持久化之后复制给目标集群的对应的那一个节点
• 让目标集群重新分片，这样就可以分散到 5 个节点上了
• 最后检查下状态，迁移完毕

2 ）使用迁移工具

• 唯品会开源一个 redis-migrate-tool 的工具对Redis4版本以上支持不太友好
• 阿里开源的一个 Redis-Shark 工具
• 我们选择 Redis-Shark 工具来做集群的迁移

2.1 相关文档

• Redis-Shark开源项目：https://github.com/alibaba/RedisShake
• Redis-Shark中文文档：https://github.com/alibaba/RedisShake/wiki/
• Redis-Shark官方编译包：https://github.com/alibaba/RedisShake/releases/
• 从上面的地址中，把客户端下载下来安装
• 还有一个 redis-full-check 的工具，在迁移完成后，要比较两个集群的数据

2.2 环境准备

源集群

IP	端口
192.168.10.101	6371、6372
192.168.10.102	6373、6374
192.168.10.103	6375、6376

Key 分布情况

192.168.10.101:6371 (afe0b393...) -> 210683 keys | 5461 slots | 1 slaves.
192.168.10.102:6373 (339e0d0b...) -> 9 keys | 5462 slots | 1 slaves.
192.168.10.103:6375 (f3353d11...) -> 3 keys | 5461 slots | 1 slaves.

目标集群

IP	端口
192.168.10.104	6371、6372
192.168.10.105	6373、6374
192.168.10.106	6375、6376

Key 分布情况

192,168.10.104:6371 (15d444c6...) -> 0 keys | 5461 slots | 1 slaves.
192.168.10.106:6375 (77772ed7...) -> 0 keys | 5461 slots | 1 slaves.
192.168.10.105:6373 (32069c23...)  -> 0 keys | 5462 slots | 1 slaves.

3.3 进行迁移

• 将上述下载下来的Redis-Shark解压，并将 redis-shake.conf 配置文件重命名备份
• 自己写一个 redis-shake.conf 的配置

  conf.version = 1
  id = redis-shake
  source.type = cluster
  source.address = 192.168.10.101:6371; 192.168.10.102:6373; 192.168.10.103:6375
  source.auth_type = auth
  source.password_raw =123456
  target.type = cluster
  target.address =192.168.10.104:6371; 192.168.10.105:6373; 192.168.10.106:6375
  target.auth_type = auth
  target.password_raw = 123456
  

• 在上述文档中，有对应具体的意思
• 开始迁移
  • $ ./redis-shake.linux -conf=redis-shake.conf -type=sync
  • 输出的日志为官方文档上的三个阶段
    • 1 ）当代源端 save rdb
    • 2 ) 全量同步阶段，显示百分比
    • 3 ）增量同步，出现字样 sync rdb done 后，当前 dbSyncer 进入增量同步
• 迁移完成之后，可以在新集群check看下
• 注意，redis-shake.linux 命令不终止还能起到监听作用，只要源集群数据有改动，就会同步

3.4 使用 RedisFullCheck 工具检查

• 若要检查源和目标是否数据统一，还可选择阿里配套工具RedisFullCheck

• 文档

  • RedisFullCheck开源项目：https://github.com/alibaba/RedisFullCheck
  • RedisFullCheck中文文档：https://github.com/alibaba/RedisFullCheck/wiki/
  • RedisFullCheck官方编译包：https://github.com/alibaba/RedisFullCheck/releases

• 下载官方编译好的工具包，直接解压后就能使用。

• $ tar -zxvf redis-full-check-1.4.8.tar.gz

• 运行

  ./redis-full-check -s "192.168.10.101:6371; 192.168.10.102:6373; 192.168.10.103:6375" --sourcepassword=123456 -t "192.168.10.104:6371;192.168.10.105:6373;192.168.10.106:6375" --targetpassword=123456 --comparemode=1 --comparetimes=1 --qps=10 --batchcount=100 --sourcedbtype=1 --targetdbtype=1
  

  • -s 是 source 源
  • -t 是 target 目标
  • --comparemode 数据比较模式 1 是全量比较，文档上都有说明
  • --comparetimes 比较轮数
  • --qps 是限速阈值
  • --batchcount 批量聚合处理的数量
  • --sourceddbtype 源库的类型 0 是单机 1 是集群 2 是阿里云
  • --targetdbtype 目标库的类别

• 运行之后，就给一个反馈结果，如果是 all finish successfully ... 则没有任何异常