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

事情起因

redis master 所在物理机A, 物理内存16G, aof rewrite 被触发时, aof文件已达12G, redis的默认配置触发了后台

的rewrite进程, 内存占用达到了50%, 已严重影响到redis的正常访问. 而此时距离会对该redis master进行写操作

的业务进程开始运行只剩1小时.

处理过程

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

redis slave的数据是完整的, 1小时内不会有写入请求

aof rewrite进程已运行2小时, 是否能在1小时内运行完毕不可控

aof rewrite进程, 即使在1小时内运行完, 不确认是否会马上触发第2次rewrite

整理方案如下:

将物理机B的redis slave切换为master, 使其跟现有物理机A的redis脱离master-slave关系

对生产环境的相关进程进行配置, 使其连接到新的redis master

测试, 验证服务正常

stop原来物理机A上的旧master进行, 暂时保留现场不动

第2天, 在执行写操作的业务进程停止写入后, 清理redis中的历史数据

周末进一步处理

备份和准备好必要的数据(这步很重要, 对生产环境的任何变更, 一定要做好备份)

将物理机A的redis配置为物理机B新master的slave

重命名该redis配置路径的aof文件

重启该redis, 使该redis从0开始从物理机A的redis master进行数据同步

手动触发物理机B的redis master的aof rewrite, 此过程完成后, aof文件从10G变为1.5G

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