记录一次因为redis aof rewrite重写导致的运维过程

事情起因

redis master 所在物理机A, 物理内存16G, aof rewrite 被触发时, aof文件已达12G, redis的默认配置触发了后台
的rewrite进程, 内存占用达到了50%, 已严重影响到redis的正常访问. 而此时距离会对该redis master进行写操作
的业务进程开始运行只剩1小时.

处理过程

跟组里几名同事一起理清楚问题现状

1. redis slave的数据是完整的, 1小时内不会有写入请求
2. aof rewrite进程已运行2小时, 是否能在1小时内运行完毕不可控
3. aof rewrite进程, 即使在1小时内运行完, 不确认是否会马上触发第2次rewrite

整理方案如下:

1. 将物理机B的redis slave切换为master, 使其跟现有物理机A的redis脱离master-slave关系
2. 对生产环境的相关进程进行配置, 使其连接到新的redis master
3. 测试, 验证服务正常
4. stop原来物理机A上的旧master进行, 暂时保留现场不动
5. 第2天, 在执行写操作的业务进程停止写入后, 清理redis中的历史数据

6. 周末进一步处理

   1. 备份和准备好必要的数据(这步很重要, 对生产环境的任何变更, 一定要做好备份)
   2. 将物理机A的redis配置为物理机B新master的slave
   3. 重命名该redis配置路径的aof文件
   4. 重启该redis, 使该redis从0开始从物理机A的redis master进行数据同步
   5. 手动触发物理机B的redis master的aof rewrite, 此过程完成后, aof文件从10G变为1.5G

7. 补齐定期删除历史数据的server逻辑