前一段時間  我們已經總結過一個關於  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分鐘內就可以完成幾十個節點的狀態轉換. 但是整個系統切換,還是要好久.

原來掉坑裡了.

我們接手後, 就很方便追查問題來源了.  當然了.問題也就此解決了.

while read 迴圈中呼叫ssh 遠端執行程式碼的一個超級大坑.

相關文章

while read 迴圈中 呼叫ssh 遠端執行程式碼的一個超級大坑.

相關文章

while read 迴圈中呼叫ssh 遠端執行程式碼的一個超級大坑.