我有 5 台配置了 Percona XtraDB Cluster 的專用伺服器（相同的機器：32 個核心、96GB RAM、RAID 中的 SSD 磁碟機和千兆位元乙太網路連結）。
有一個反覆出現的問題會導致集群嚴重減速，通常持續約 30 到 60 秒，但有時會卡住長達 5 到 10 分鐘。
該系統用於繁忙的網站網絡，我在每個網絡伺服器上使用 mysql-proxy 來平衡資料庫流量的負載。
如果僅啟用一個節點，則不會出現此問題。隨著每增加一個節點，問題的強度就會增加（查詢減慢/鎖定的時間量），直到 4 個節點處於活動狀態時變得非常難以忍受（此時叢集無法再自動恢復）。
詳細症狀如下：
- 每隔 5 到 15 分鐘，所有寫入查詢（INSERT/UPDATE）就會卡在每個節點的佇列中。有些查詢會在 45-50 秒後分派，而有些則完全停止。
- 大多數情況下，30 到 60 秒後，叢集能夠以某種方式趕上並在 1-2 秒內快速分派查詢。
- 有時，叢集無法自動處理這些卡住的查詢，我需要手動停用最繁忙的網站，以便降低負載，並且在幾乎沒有負載的 30 秒後，叢集再次能夠調度所有查詢。
錯誤日誌通常是乾淨的，在速度下降之前或之後沒有錯誤訊息。我很少遇到這樣的事情（也許十分之一）：
130906 9:53:27 [注意] WSREP：（3f3abd42-15bc-11e3-b38b-2e049b972e3b，'tcp://0.0.0.0:4567'）開啟訊息中繼請求，非活動對等點：tcp:// IPOFONEOFTHENODES
130906 9:53:27 [注意] WSREP: (3f3abd42-15bc-11e3-b38b-2e049b972e3b, 'tcp://0.0.0.0:4567') 關閉訊息中繼請求
在正常負載下，我通常的 wsrep_cert_deps_distance 約為 400。一旦開始減速，wsrep_cert_deps_distance 就會慢慢增加，直到 2k-3k 範圍（當達到 3k 標記時，我需要手動禁用應用程序，否則集群無法自行恢復）
使用 mytop 和 atop 進行監控，我發現伺服器或 mysql 進程中沒有高負載。在正常操作和減速期間，CPU 使用率始終相當低（大約是最大值的 25%）。 I/O 使用情況良好，有足夠的可用 RAM，vmcom 低於限制。
我使用 myq_status 即時監控每個節點上的集群，結果如下：
- 即使發生減速，wsrep_flow_control_paused 變數也始終為 0.0。
- 不會發生 wsrep_local_bf_aborts 或 wsrep_local_cert_failures。
- 在每個節點上，出站複製通常為 0，當速度下降時，出站複製會增加到 200-300。
- 每個節點上的入站複製始終為 0（很少為 1，但即使在正常負載下也會發生）。這讓我很困惑，因為顯然叢集中沒有慢速節點。
- 從減速開始 10-15 秒後，每個節點上發送和接收的操作和位元組都變為 0。它們在0 處停留一兩秒，然後下一秒發生大量的操作和字節，再加上大量的“oooe”操作（無序執行），這種情況每隔幾秒就會重複一次，直到伺服器返回到普通的。
以下是我為嘗試解決問題而進行的測試的詳細資訊（沒有任何運氣...）：
- 我首先檢查了網路：伺服器位於具有專用千兆位元網路的同一機架中，一切似乎都工作正常，沒有封包遺失或其他明顯的網路問題。
- 我檢查了頻寬使用：每個節點平均使用 30 到 100mbps（兆位元）的頻寬。我使用“iftop”即時檢查，當問題發生時，頻寬使用率通常低於平均值（15 到 30mbps）。雖然同步節點頻寬高達 800-900mbps（應該是），所以我認為網路尚未飽和。
- 我嘗試了所有節點的組合，以確保一個特定節點影響其他所有節點：無論我停用或使用哪個節點，問題始終存在。此問題始終與同時活動的節點數量有關。
有人遇到類似的問題嗎？先致謝！