關於核心恐慌的心跳肉件 STONITH
我有一個帶有心跳和 DRBD 管理 mysql 資源的兩個節點集群。如果我停止主伺服器、重新啟動它或斷開網路連接，故障轉移會非常有效。
但是，如果主節點遭受核心恐慌（通過執行模擬
echo c > /proc/sysrq-trigger），則輔助節點不會接管資源。這是輔助節點上的心跳日誌的樣子：
Jul 11 21:33:32 rad11 heartbeat: [7519]: WARN: node rad10: is dead Jul 11 21:33:32 rad11 heartbeat: [7519]: info: Link rad10:eth0 dead. Jul 11 21:33:32 rad11 heartbeat: [8442]: info: Resetting node rad10 with [Meatware STONITH device] Jul 11 21:33:32 rad11 heartbeat: [8442]: ERROR: glib: OPERATOR INTERVENTION REQUIRED to reset rad10. Jul 11 21:33:32 rad11 heartbeat: [8442]: ERROR: glib: Run "meatclient -c rad10" AFTER power-cycling the machine.有誰知道為什麼在這種情況下二級伺服器無法接管？通常故障轉移效果很好，但我試圖在主節點上模擬核心恐慌。
編輯：這是我的心跳配置，ha.cf
# /etc/ha.d/ha.cf logfile /var/log/ha-log keepalive 1 deadtime 10 udpport 695 ucast eth0 rad11 auto_failback on stonith_host rad10 meatware rad11 stonith_host rad11 meatware rad10 node rad10 rad11
當集群節點之間失去聯繫時，為了避免出現裂腦情況，即兩個節點都認為自己是主節點，並試圖同時執行共享資源**，結果可能導致災難**（這在兩個節點集群中尤其嚴重） ，因為如果兩個節點各有一票，誰有仲裁？），所以為了緩解這種情況，一些集群實施了各種形式的圍欄。
Fencing 是將資源鎖定在狀態不確定的節點之外的過程。
有多種可用的擊劍技術。
可以使用 Node Fencing 圍住節點，也可以使用 Resource Fencing 圍住資源。有些類型的資源是自我防護資源，有些不會因同時使用而損壞，根本不需要防護。
當一個節點執行乾淨關閉時，它會很好地離開集群，因此其他節點會知道發生了什麼，因此只會接管節點可能已經執行的任何服務，然後繼續執行。當節點而不是離開集群很好地獲得核心恐慌時，其他集群成員將不知道其他節點的狀態。從他們的角度來看，這將是“不確定的”，因此他們將執行配置的“隔離”操作，在 STONITH 的情況下，這意味著嘗試從集群中強制移除故障節點（通過電源循環等）。
查看您的日誌，似乎為您的集群配置選擇了
meatwareSTONITH機制。顧名思義，這意味著手動重啟另一個節點，然後執行所述命令。來自文件：肉製品
奇怪的名字和一個簡單的概念。肉製品需要人類的幫助才能操作。每當呼叫時，meatware 都會記錄一條 CRIT 嚴重性消息，該消息應顯示在節點的控制台上。然後，操作員應確保節點已關閉並發出一個肉客戶端（8）命令告訴肉件可以告訴集群它可能認為節點已死。有關更多資訊，請參閱 README.meatware。
還有其他配置防護的方法。在製作集群時，我通常會為 PSU 準備兩個 APC 開關並配置“APC 防護”（
stonith -t apcmaster -h）。這樣，當一個節點發生故障時，另一個節點將通過登錄 APC 介面並在連接的 PSU 插槽上發送關閉/重啟命令來重啟故障成員，從而執行硬重啟（我得到兩個以避免單點故障） .