不久前的一次機房網絡故障，再一次對我們在Heartbeat+DRBD+MySQL資料庫架構運維水準的一個考驗，之前不止一次的測試與線上部署，還有之後大言不慚的關于該架構元件的所謂深入了解，在這一次不經意的意外面前又是“很囧”的收場，慌張呀！這次斷網導緻H-D-M全線異常，真是千載難逢，都讓我們趕上啦lol: 下面就把這次的小幸運小幸福和大家分享下，以下是按照問題處理的先後順序依次講述。
- MySQL Replication同步異常
當發生網絡故障一個小時後，從庫io_thread和主庫的連接配接被中斷，抛出錯誤提示：[ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)，沒想到竟遇到了一個古董級的Bug，有點喜出望外了(心想，我也能遇到bug)。最後解決辦法，隻能拿備份重新做一遍主從。後來，好奇想查查，究竟是怎麼導緻這個問題，竟發現，從庫relay log中的記錄比主庫binlog中的記錄多了2條insert和1條update(0_0!!!…不合邏輯呀？！！)。
- DRBD狀态異常
處理完資料庫同步問題後，當時并沒有去檢視DRBD的狀态，直到周一才發現出問題了，簡單地通過指令cat /proc/drbd就可以檢視，DRBD的狀态是否正常。檢視/var/log/messages知道網絡故障導緻DRBD發生腦裂，彼此都認為對方已經死了，然後自己都将角色作為Primary，并積極擷取資源，當時的兩端的連接配接狀态都為StandAlone，角色都為Primary。在發生腦裂不久後原active node被heartbeat強制将系統重新開機，最後，原active node角色變為Secondary/Unknown，原standby node角色依然是腦裂時的Primary/Unknown，兩端的連接配接狀态，分别為WFConnection和StandAlone。解決方法如下：
Step 1 - On New Secondary:
# service heartbeat stop
# service drbd stop
# drbdadm create-md r0
# service drbd start
# service heartbeat start
Step 2 – On New Primary:
# service drbd reload
之後就進入漫長資料同步階段，重新将Primary上的資料塊檔案拷貝到Secondary上，最後完成同步。
- Heartbeat通信異常
通過檢視/var/log/ha-dug日志，發現在出現網絡故障後4分鐘内，Heartbeat服務在active node與standby node間反複做資源釋放與擷取的操作，最後資源被之前的standby node獲得，而之前的active node因為DRBD資源的問題，請求系統重新開機“CRIT: Resource STOP failure. Reboot required!”。系統重新開機後，Heartbeat服務并沒有被開啟，chkconfig裡面沒有把heartbeat設定為開機自啟動，drbd是被設定開啟自啟的。其實，周日在處理問題時，沒有考慮到heartbeat問題，理所當然的人為，資源是被正常切換，而認為heartbeat當時是正常(~臉紅~:
# less /var/log/ha-dug — 發現問題
On Active Node(之前的standby–>切換後active):
WARN: Gmain_timeout_dispatch: Dispatch function for retransmit request took too long to execute: 390 ms (> 10 ms)
ERROR: Message hist queue is filling up (500 messages in queue)
On Standby Node(之前的active–>切換後standby):
WARN: Rexmit of seq 17224382 requested. 41 is max.
在目前的active node上執行如下指令：
# top — 注意有4個僵屍程序(zombie)，同時會發現heartbeat的cpu使用達到100%左右
Tasks: 245 total, 2 running, 239 sleeping, 0 stopped, 4 zombie
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2106 root -2 0 422m 376m 4788 R 100.1 1.6 5002:17 heartbeat
# ps aux |grep defunct |grep -v grep — 找出是哪4個僵屍程序
root 15678 0.0 0.0 0 0 ? Z 10:57 0:00 [heartbeat]
root 17932 0.0 0.0 0 0 ? Z 13:48 0:00 [heartbeat]
root 19176 0.0 0.0 0 0 ? Z Jul11 0:00 [status]
root 19626 0.0 0.0 0 0 ? Z Jul11 0:00 [heartbeat]
既然，heartbeat服務有問題，那麼很自然的就想到重新開機該服務，重新開機heartbeat是也會釋放掉所有的資源的，會影響到正常業務，是以，選擇到晚上閑時操作。出于安全為了不讓資源切換到standby node上(其實，當時的情況heartbeat以及不能工作)，我先停掉了standby node上的heartbeat，接着去停止active node上的服務，但是過了幾分鐘都沒有相應，事實上，heartbeat的主程序已經僵死了，最後我“鼓足勇氣”—kill -9 heartbeat-PID，然後先重新開機active node，再重新開機standby node，最後，檢視日志一切都恢複正常了。之前，在做kill操作後，active node上的資源并沒有釋放，依然正常運作。
– — – END — – –
即便這次飛不小的勁，看似把問題都依依解決了，但心裡依然沒譜，對于之後可能發生的問題還是沒有十足的把握；事實上，還是對于Heartbeat和DRBD技術本身，了解的不夠透徹，Heartbeat對于資源的切換、檢測後的判斷以及對于日志輸出的了解都還有很多疑惑，DRBD發生腦裂時資源争奪，會對資料塊有多大影響，等等，是以就像田老師的感慨說的，我們之前做的僅僅就是能夠把這個架構簡單的打起來而已，根本談不上專業的運維。
覺得文章有用？立即：
和朋友一起 共學習 共進步！
猜您喜歡