这里将的是已有集群(已经有数据且在运行)的运维操作。
检查集群状态
进入任意节点:
|
|
注意: 这里看到的是当前节点的集群视图,如果发现 A 节点和 B 节点的结果不一致,那就说明出现故障了。
参考命令:
添加 Master
进入任意 master,把新 master 加进来:
|
|
成功后要 Resharding,redis-cli方式 或 Redis Command方式 ,把一些 slot 转移到新 master 上。
参考命令:
添加 Slave
进入新 slave,把自己加入到集群里,将其配置为某个 master 的 slave,注意符合高可用部署架构:
|
|
参考命令:
删除 Master
前提:master 是空的,不负责任何 slot。
方法:Resharding,redis-cli方式 或 Redis Command方式 ,把 master 上的所有 slot 转移到其他 master 上。
进入到以下节点执行命令:
- 每个 master(除了要被删掉的 master)
- 每个 slave (除了要被删掉的 master 的 slave)
|
|
进入到被删除 master,重置:
|
|
被删掉的 master 的 slave 会自动转移到其他 master 下。
注意:以上所有操作要在 60 秒内全部执行完,否则可能因为 gossip 协议导致被删除 master 再次加入。
参考命令:
删除 Slave
进入到以下节点执行命令:
- 每个 master
- 每个 slave (除了要被删掉的的 slave)
|
|
进入到被删除 slave,重置:
|
|
注意:以上所有操作要在 60 秒内全部执行完,否则可能因为 gossip 协议导致被删除 slave 再次加入。
手动 Failover
手动 failover 让你把一个 master 和其 slave 对调角色,常见于升级节点的时候。
进入 slave,让其升格为 master,这样它会把自己的 master 踢掉,自己做 master,而原来的 master 则会变成它的 slave:
|
|
参考命令:
参考资料:
K8S部署环境崩溃
如果你的 Redis 集群部署在 K8S 环境中,而恰巧,整个 K8S 环境出现过崩溃,导致你的集群处于不可用状态,那么你可以通过下面方法恢复集群(假设 Redis 都挂载了 PVC 数据没丢失)。
假设你的 Redis 实例 Pod 都已经重建了,而且是超过一半以上的 Redis Pod 发生过重建。
虽然每个实例的 node id 没有发生变化,但是他们的 IP 变了,导致每个实例根据 nodes.conf
中保存的 IP 信息已经无法联系到对方。
这时你需要做的是,到每个实例中执行以下命令:
|
|
然后整理出以下表格:
ip | role | node id |
---|---|---|
x.x.x.x | master | zzzz |
x.x.x.x | master | zzzz |
x.x.x.x | master | zzzz |
x.x.x.x | slave | zzzz |
x.x.x.x | slave | zzzz |
x.x.x.x | slave | zzzz |
然后,随意进入到一个 master 实例,和其他 master 碰个面:
|
|
最后,进入到所有 slave 实例,和任意一个 master 碰个面:
|
|
这样 Redis 集群就恢复了。
升级节点
见 高可用架构。
评论