开始前先说明一下环境
redis规模是在kubernetes环境下搭建的集群三主三从模式 使用hostpath将数据保存在宿主机上
6个POD分布在三台机器上 需求是要把6个POD分开调度到6台机器上
迁移的大概想法就是 redis的三个master节点不做迁移 只迁移三个slave 因为是生产环境中 安全第一
迁移前保证集群状态正常以及确认master节点分布在已有的主机节点上
确认新迁移的主机节点数据目录存在
备份数据 三个master节点就可以 这里就不贴三个图片了
通过控制器调整slave节点的副本数为0 然后修改控制器将pod漂移
参数
nodeSelector:
kubernetes.io/hostname: 新节点ip
修改完成后 将副本数恢复
此时会在新节点上启动一个redis pod 数据目录也会自动创建出来 但是redis集群的nodes.conf中只有自己的信息 需要从原先节点的数据目录将nodes.conf 文件内容覆盖到节点迁移到新主机上自动生成的nodes.conf
正常的节点信息
新节点信息
将slave节点调0 覆盖完成后 再次恢复pod副本数
此时进入pod查看节点信息 是正常的 但是检查主从link状态显示是down
此时进入对应的master节点查看主从状态 state=wait bgsave（如果本地有数据文件 会先将本地数据读取到内存中）
此时master节点正在执行bgsave 如果现在手动执行bgsave 会报错说已经有一个线程在执行
而在master节点显示wait bgsave过程中 可以到master的数据目录中查看到会有一个temp.rdb临时文件生成 也就是我们查阅到的资料中说的 rdb持久化不会直接覆盖原有的旧文件，而是先持久化到一个临时文件 持久化完成后 再进行覆盖
可以看到这个临时文件在一直增大 直到bgsave结束
在slave节点的数据目录中也可以查看到一个temp.rdb文件 在master节点的持久化没有结束之前 可以看到这个文件大小一直为0 也就是对应刚刚在master节点上查看到的slave状态 wait bgsave
当master节点的持久化动作结束 temp文件会消失 其实是替换了之前的rdb文件 可以通过文件的时间戳验证
master的持久化动作结束 此时查看slave节点数据文件 发现temp.rdb文件开始增大
此时再次到对应的master节点查看主从状态 会发现由原先的wait bgsave变为send_bulk状态
直到slave接收rdb文件结束 temp.rdb替换rdb文件 此时slave节点开始往内存中写入数据
这里需要注意的是 redis启动后会首先将本地持久化文件中的数据导入进去
接收完maste同步来的数据之后 因为数据差异过大 会进行全量同步 首先会将原有的数据刷掉
也就是会先执行一个flush命令
而这个命令 会堵塞redis
下面这个图片中我执行info keyspace 也会被堵塞
日志中也可以看到
等待了会 再重连 此时到slave中查看key信息 发现一直在增加 从数据文件中读取到内存中
从master节点查看主从状态
直到slave读取完成数据之前 master显示slave的offset值一直为0
数据同步完成 offset变为与当前master的offset值相同
master上显示slave为online
slave上也显示link状态为up
