前一段时间 我们已经总结过一个关于 while read 循环调用ssh 的问题了.
http://blog.itpub.net/133735/viewspace-2136798/
今天说下另一个存在了几年的大坑.
mysql HA 的 lvs 切换代码端 也存在这么一个 while read 循环 然后其中调用 ssh 到远端主机修改配置文件.
然后问题来了, 今天一台数据库主机重启了. (重启原因不表)
主机重启后, 数据库ha 开始执行ha切换. 由于正在班上, 不想人工干预, 让ha自动切换吧, 速度都可以的.
奇怪的问题来了.
搞了 几分钟, 还是没有切换完, 数据端的 ha 触发机制 都已经全部搞定了, lvs 端只切换了2个节点.
然后忍耐一下, 也只切了4个节点. 然后无法忍受了. 人工干预切换. 1分钟内全部切换完毕.
然后开始调查为什么切的这么慢.
然后开始balabala 代码日志, 发现 如果检测正常,或者没有达到lvs 切换标准的时候, 整个代码流程是能够完整跑完的.
然后 如果 当前的某个节点 达到了切换标准. lvs 切换了, 那么当前的检测循环竟然退出了.
对照日志, 开始balabala 代码. 然后突然发现了这个 while read 循环调用ssh 到远端的执行的 代码结构.
眼前一亮. 问题原因就在这里了.
这里问题就是如果while read 里读到 各个节点 然后去检测这个节点对应健康状态.
如果这个节点需要lvs 切换了. 那么就调用ssh 到某台远端节点 执行某个操作命令.
执行这个ssh 的时候,因为ssh 要把stdin 作为输入. 所以把while read 的stdin buffer 全部读完了.
导致这个节点处理完后, while 循环, 再从头开始的时候,read 已经到达EOF 了. 然后循环退出了.
如果这个节点不够 切换标准, ok , 不会调用ssh . 那么后面的节点还在while read 的stdin buffer 里,
read 可以读到. 然后整个循环会跑完.
大坑 就这么 出来了.
以前很少会整体机器 所有的几十个节点 都切换.
偶尔的发生, 多几分钟的切换都被认为是事务太慢了.或者逻辑上繁琐等等造成的. 还有就是以前lvs 是另一个部门维护,我们都无法查看日志跟登录主机. 也无从追查原因. 只知道数据库端检测很快, 1,2分钟,还是1分钟内就可以完成几十个节点的状态转换. 但是整个系统切换,还是要好久.
原来掉坑里了.
我们接手后, 就很方便追查问题来源了. 当然了.问题也就此解决了.
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/133735/viewspace-2139699/
,如需转载,请注明出处,否则将追究法律责任。