最近几次比较郁闷，碰到几起服务器硬件故障或者存储故障，直接导致服务器系统夯住，MySQL服务或多或少受到影响，有的影响是MySQL服务自动重启，有的影响是整个Linux系统重启的，这种硬件错误发生在6的系统居多。通常我们以为MySQL服务使用了高可用架构，类似于MMM/MHA这种能实现故障转移的架构，服务就能高枕无忧，可是最近发生的实事让我对高可用有了新的认识。
案例一：DAS存储碎文件过多，导致文件系统夯住，MySQL服务自动重启。线上一个重要的业务线集群使用了MMM架构，其中master2使用了流式物理备份并二次压缩的方式进行物理备份，本地备份完后会在凌晨将备份文件传输到远端存储，这个DAS存储以NFS的方式挂载在服务器上，其实存储本身是一个windows的界面，夜里进行传输备份的时候会发生master2的MySQL服务自动重启，发生的频率大概是两个月一次，尤其是存储的可用空间不到4T的时候，由于禁用了同步线程自动重启，夜里还需要人工操作并确认各服务正常。最初怀疑是系统的原因，6系统部分内核出现过文件系统夯死，MySQL服务假死不能提供应用的现象，后来存储空间不够，更换了存储为GFS，连续观察了几天，从MMM的日志和系统日志都没有再看到错误输出信息（DAS存储的时候每天会输出一定的MMM错误日志）。解决这类外部因素要保证DAS存储碎文件或目录不宜过多，或者有条件可以更换质量更好的存储。
案例二：服务器内存错误，导致master1服务器文件系统夯住，集群MMM服务的agent与server不能正常通信，故障转移功能无法进行。服务器内存错误导致系统夯住，这种类型的错误导致夯机的危害相比上面案例更大，上面的错误MySQL服务可以自动重启后继续提供应用连接，而内存错误会造成MMM/MHA这种通过SSH方式进行通信和维护心跳机制的架构，容易出现进程类似sleep的现象，不仅故障无法自动转移，也会出现手动切换失败的可能（文件系统夯住导致MMM命令无法使用，长时间不能出来结果）。解决这类文件办法只能是重启硬件故障的服务器才能释放僵死的进程，MMM命令才能正常使用，临时解决这个期间问题的办法是手动添加应用连接的VIP到master2，保证服务受到最小的影响。但是要注意脑裂，服务器恢复正常后，重启MMM的monitor和agent服务前，要删除手动添加的VIP并进行一次arping广播。
