关注公众号【1024个为什么】,及时接收最新推送文章!
前面我们说过了数据库服务的迁移,今天继续聊一下 Redis 服务的迁移。
由于纯 [主 - 从] 结构主节点挂掉后不能自动切换的缺陷,生产环境一般很少使用此结构,我们就直接从哨兵结构说起。
哨兵结构的迁移
场景一:只迁移 redis 实例节点
操作步骤
(一)在新的机器上先搭建一套端口相同的主从节点,M2,R2,把 M2 作为从节点,挂在老的 R1 上,通过 Redis 自有的主从同步功能,同步数据。
(二)手动切换哨兵监控的主节点到 M2,触发客户端变更连接的主节点
(三)停掉老的主从节点 M1, R1
由于上一步手动变更哨兵监控主节点时,会自动更新其所监控的节点信息,哨兵监控的节点列表中只有新的主从节点信息,这里可以直接下掉老节点。
场景二:哨兵节点也迁移
此场景是基于场景一的
操作步骤
(一)搭建一套新的哨兵节点 S4 ~ S6,直接监控 M2 节点,哨兵可以相互自动发现监控同一实例节点的其他哨兵,并互相同步哨兵列表和实例节点列表。由于哨兵的自动发现需要一定的时间,官方建议一个一个地添加,间隔 10 秒。操作完成后,检查所有哨兵节点信息是否都正常。
(二)如果域名没变,修改域名解析到 S4 哨兵节点;
如果域名变了,需要业务服务修改域名配置,重启服务后连接到新的哨兵节点。
(三)停掉老的哨兵节点 S1 ~ S3。
由于哨兵节点不会自动忘记其已记录的其他哨兵节点,需要手动重置哨兵节点,使哨兵列表更新到最新。
集群结构的迁移
集群结构的迁移其实就是扩容、缩容。
操作步骤
(一)先向集群中添加一个主节点 M4,此时 M4 节点是空的,没有任何数据
(二)从其他节点迁移数据给 M4,迁移的数据量,从哪些节点迁,都是可以指定的,但一般为了节点的负载均衡,会从现有节点中平均各迁一部分到新的节点。
我们假设往 M4 上迁 3000 个槽位的 key ,即从 M1、M2、M3 各迁出 1000 个槽位的 key。
(三)迁移完成并检查节点数据正常后,再给 M4 挂上从节点。
之所以迁移完数据之后再挂从节点,是为了尽快完成数据迁移,避免迁移过程中主从同步的消耗。
其他节点以此类推。
节点添加完成后,就可以操作删除老节点,删除节点正好是添加节点的逆向,需要先把节点内的数据迁移到其他节点,数据迁移完成后,再停掉该节点。以此类推,直到所有要下掉的节点都删除完。
Redis 迁移几乎是平滑的,只需观察业务服务是否正常即可。
原创不易,多多关注,一键三连,感谢支持!