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

发表于 更新于 分类于

事情起因

redis master 所在物理机A, 物理内存16G, aof rewrite 被触发时, aof文件已达12G, redis的默认配置触发了后台的rewrite进程, 内存占用达到了50%, 已严重影响到redis的正常访问. 而此时距离美股交易开盘只剩1小时.

处理过程

跟server组几名同事(carl, shilinchen, echo, jiezhao, zhiguocai)一起理清楚问题现状

  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. 对生产环境的hosts文件修改, 使hosts中配置的域名指向新的master
  3. 重启相关进程, 使其连接到新的redis master
  4. 测试白名单账号验证服务正常
  5. stop原来物理机A上的旧master进行, 暂时保留现场不动
  6. 第2天, 交易收盘后, 清理redis中的历史数据
  7. 周末进一步处理
    1. 新准备好下一交易日的uinfo和margin相关数据
    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
  8. 补齐定期删除历史数据的server逻辑

后记

交易系统和风控系统经过重新设计, 进行了重构, redis已经是过去时了, 不过曾经踩过的这个坑希望能记录下来, 让我们时时警示一下.