记一次数据库内存调整引发的运维事故

记一次数据库内存调整引发的运维事故

• 环境
  我维护的一个重要的业务系统，生产环境采用的mysql5.6，一主两从的架构，两个从库配置不同，因为不是同一时期添加的。其中配置低的那台作为数据统计分析用，配置高的那台留做灾备。作为数据分析的那台从库同时承担着NFS文件服务器的作用。
• 需求
  因为负责数据分析的那台数据库服务器内存较低，还经常因为数据分析加载旧数据，因此出现数据分析性能很差，执行SQL查询速度很慢。
  为此我提出增加内存这种直接高效的方法提高查询速度，得到同意后就执行了。
• 操作步骤
  1 登录从库，停止mysql服务，mysql服务可以直接停止，没有因为主从的原因需要特别注意的。
  2 服务停止后，断电服务器。
  3 为服务器添加内存调
  4 服务器加电重启
  5 启动数据库服务，启动后数据库服务会自动连接主库，不需要手动操作
  以上就是数据库从库增加内存的全部过程。但是事情到此并未结束。。。。。。。
• 意外
  数据库内存刚刚升级完，业务系统监控就报错了，业务系统页面无法访问。
  第一反映就是应该和我升级内存无关吧，迅速冷静下来思考了一下，应该无关（不是很自信）。马上着手调查，经过一些列紧张的排查，发现是业务系统的80端口不能提供响应了。针对这个问题进行了很多常规排查和测试都没能解决。无奈之下只能重启服务器，重启后问题奇迹般的得到解决，百思不得其解中。
  还没等我想到原因，业务部门又上报说，业务系统的图片打不开了。此时吓的我一身的冷汗，因为我想到问题了。问题就是我重启的数据库服务器不仅是从库还是文件服务器，在调整内存时居然把这项业务忘记了。
  迅速恢复文件服务器，因为我直接重启了文件服务器的原因，和文件服务器有关的服务器，都不能执行df的命令了。这个问题我以前遇到过一次，所以我没在这个问题上有疑问。恢复文件服务器后，业务系统都恢复正常。
  目前怀疑前端nginx代理不响应到80端口的请求也和NFS文件系统中断有关，但还没分析出确切原因
• 总结
  1 生产环境千万不要盲目调整，千万不要在业务繁忙的时间调整，给自己留条后路
  2 生产环境业务系统，最好做到一个服务器一个业务，否则出现问题很难排查，还会因为调整一个服务影响另外的服务
  3 千万别太相信自己的经验和判断，短时间发生的一系列事件大多数都是相关的
  4 生产环境，建议NFS别做开机启动，因为一旦NFS有问题，开机就挂载NFS的系统重启会起不来。