此故障是个人所遇到的最困难的一次; 持续多天才解决;
简述过程
- 发现故障
- 临时解决: 来回切换主备库
- 有效临时措施: 清理 cache
发现故障
发现 mysql 服务夯住, 能登陆主机, 但数据库登陆失败, 业务中断。
临时解决办法: 切换到备库
情况:
备库坚持N个小时后, 也不行了，再切回原主库, 坚持数十分钟后再切, 后续每次切换只能坚持10-15分钟。
期间请各路外援来支持, mysql维保的, weblogic 原厂的, redhat原厂支持, 以及公司的几位大牛专家都来现场协查询未果;
我其实是想去排查的, 可忙于手工来回切换主备库, 没有办法参与;
尴尬的小故事
受于高压的来回手工切换数据库, 只有中途2-8分钟时间排查的间隙时间, 这点时间还需要让开座位请外援来排查，所以非常累，手举着都酸了，于是我招呼同事来接替我进行切换, 我下楼抽支烟，看看有没有什么思路;下楼点上一支烟后，遇到了一个熟人甲方的同事A，就闲聊几句故障情况, 此时甲方的某领导B路过（专门为此故障过来督办的），A喊住B然后简单说了一下故障的情况，然后就开始夸我了，说我能力怎么怎么强，巴拉巴拉一堆夸，推荐B后续考虑把我拉过去咋的;
我脸立马就红了，现在楼上还有一个重大故障没搞定，你在这说这些不是阴阳我吗，我特别尴尬，B也特别尴尬，我想赶紧跑，但情商低又不知道咋打断A的输出，于是猛吸了几口烟，然后说我得上楼再去看看，跑了。
有效临时措施: 清理 cache
第二次下楼抽烟后，我脑袋突然一热，想到了一个主意, 看看主机内存变化吧;
立马上楼趁着切换间隙，看了一下监控数据, 发现 swap 是有波动的;
于是趁着下一次间隙, 将主库给停止了, 然后清理了内存 cache
|
|
然后启动数据库再切换回来, 好啦，这次切换坚持了5个小时, 啧啧
问题基本定位成功;
制定了一个临时措施, 启动一个脚本每 20 分钟执行一次 drop_caches, 嗯，恢复稳定
问题的根本原因
接下来就是详细排查了;
经过一天的资料查询，推测原因如下：
主机的配置是 4CPU + 128G 内存, rhel6.7
主机的内存是按 CPU 进行分区的, 其实每个 CPU 只能用到一部分内存，当这一部分区域的内存满后，即便整体内存还有空闲，也会触发 swap
而回收策略中，还有几条水位线, 经过缓存, 这个机器的 low 水位线和 high 水位线只相差 4M
例如当某个CPU核心所控制的内存区域, 使用量接近 low 时, 并不会触发 swap, 如果此时只申请 一个 2M 大小的内存块, 也不会触发 swap, 只会触发普通的内存回收,
但是如果此时申请一个 5M 的内存块，则超出 high 水位线, 则开始触发 swap 回收, 导致故障了
基本原因就是这样, 不过这只是推论;
我一直打算找时间复测一下问题, 可是没有环境，模拟环境做了一次也没有达到这个效果;
决定等我的新主机到了后, 再复测一下这个事件。
需要对 /proc/zoneinfo 文件进行深入分析
故障教训
教训1
这个事件中非常重要的一个环节错误, 是单点问题;
整个团队只有 2 个人的电脑能接入到 数据库主备环境, 因为另外一位同事对环境也不太熟悉, 于是基本上只有我这一个点能进行排查, 以及配合外援们的排查;
就导致我这其实根本没有办法进行排查, 数据库一夯住, 业务方领导就站在旁边施压要求尽快恢复, 于是只能切备库, 操作完，立马起身让位给外援进行排查, 几分钟后故障复现，再换我坐回来操作切换，然后再让出去;
这就导致效率极低, 对这个环境最熟悉的我完全没发挥上作用。
为什么就不能有多个接入点呢？
教训2
被某位外援误导, 说是某个现场也出现类似的问题, 原因是 weblogic 的连接池的某某问题, 要求对业务代码进行排查;
于是很多项目成员的就去配合这个方向了, 我也舒了一口气, 等他们的结果, 而忽视了自己这边也需要排查;
排查方向还是要多样, 先从最容易最快的方向去, 但同时其它路线也得考虑
教训3
这个 swap 的问题一开始没有看到吗？
肯定不是的, 就算是一位新手SA, 也知道上机后最基础的三命令, top free df
free 肯定是执行过的, 但是这个机器以往 swap 也是有轻微使用的, 而我执行 free 命令查看是也看到的是 swap 使用并不多, 于是就忽略了这个问题;
早期 linux 主机默认的 swappiness 是 60, 也就是当系统内存使用率大于 40% 时就会考虑使用 swap 的空间;
我们一般修改为了 10 或者 5, 因为有很多说法都说不要完全关闭 swap
也就实际上还是会在内存使用率较高时, 使用到一些 swap 空间, 正常情况下会是一个管理进程的内存空间, 不是那么关键, 用一点也是一点，没有啥大影响。
但是此时没有及时注意到 swap 的使用波动就是很不应该的了, 需要自省
教训4
太依赖人工了, 没有标准化, 故障时根本拿不出现场的全局状态信息来，导致只能一条一条命令的去排查;
还是得有个靠谱的监控系统啊;
难道以前没有监控吗？
肯定不是的，只是以前有监控无告警, 而那几千个指标几十页，根本不可能在争分夺秒的关键时刻去慢慢点开看;
一眼看不出来就没有啥用了；
对于这种无告警的场景, 最好还是得弄个动态大盘, 将异常的单元浮动到首页来, 才能被注意到;
为什么没有告警呢？
- 纯内网系统, 无法使用某些外网的接口，如群机器人这些能够进行细化分组的告警。
- 内网也是有短信网关可以使用的, 但必须走故障通道, 一旦有消息进入故障通道，就会影响考核和项目业绩, 可想而知，这是不可能使用的;
- 短信太多，根本没办法看; 业务告警申请了短信网关故障通道的免责, 还是特批的; 造成了每天几百+的短信; 运维类的告警短信不给特批, 且就算有发也不可能去看；短信的作用就只能起到事后写报告的时候有点用了。
复盘
测试环境复现，暂未开始, 待更新
计划复现办法:
虚拟4个以上CPU, 调整内存大小, 尽量使 zone 的 low 和 high 水位线被压到极致, 然后慢慢增加内存使用率; 接近 low 时，再申请一块大内存.