不久前的一次機房網絡故障，再一次對我們在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發生腦裂時資源爭奪，會對數據塊有多大影響，等等，所以就像田老師的感慨說的，我們之前做的僅僅就是能夠把這個架構簡單的打起來而已，根本談不上專業的運維。

覺得文章有用？立即：

和朋友一起 共學習 共進步！

猜您喜歡

總結

以上是生活随笔為你收集整理的drbd heartbeat mysql_Heartbeat+DRBD+MySQL Replication故障处理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。