Galera Cluster 2 節點 - 無法在節點 1 上重新啟動 MySQL 服務器

Question

我遇到了這個問題，類似於這個問題： 無法重新啟動 MySQL 服務器，但我不確定如何繼續，所以我向社區詢問，尤其是在 Galera Cluster 上有比我更有經驗的人。 我會試着總結一下：

配置：

Galera Cluster 2 節點 - 每個節點都是 Ubuntu 16.04 和 Mariadb 10.2.17 版本。

問題：

其中一個節點（node1）出現故障，不幸的是沒有配置錯誤日志或通用日志，但在journalctl上我可以看到錯誤類似於“文件中的mariadb innodb斷言失敗”，建議嘗試innodb_force_recovery（ 1 到 6) 但我不知道 Galera 同步是如何工作的，或者它是否是一個主動/主動配置，所以我沒有信心最終啟動一個不同步的節點，因為有幾天可能會出現裂腦情況。 另外，我在 datadir 上看到存在一個名為“sst_in_progress”的文件。

考慮：

最終刪除故障節點上的datadir並重啟mysql服務是否可以？ 是否足以讓它開始與復制數據的節點 2 同步而不觸及當前正在向客戶端提供服務的節點 2 上的數據？ 此外，據我所知，Galera 集群不復制系統表，所以我應該從 node2 導出 mysql.user 表並在 node1 上導入以恢復所有用戶和權限。 謝謝，我希望我能成功解釋這個問題，如果不清楚請告訴我。

Answer 1

文件sst_in_progress表示損壞的節點已經請求了 SST（State Snapshot Transfer），這基本上是從集群中的另一個節點進行的完整數據傳輸。 您可以使用多種不同的 SST 方法，您可以通過檢查wsrep_sst_method變量來查看您啟用了哪一種。 需要注意的是，捐助者和加入者節點必須使用相同的 SST 方法。 有關不同 SST 方法和一般 SST 的更多信息，我推薦mariadb 文檔

SST 應該能夠將損壞的節點重新加入集群。 您可以在 mysql 錯誤日志中看到 SST 的進度。 但是，由於您沒有配置，您可以改為檢查節點上的 wsrep 狀態（例如， show global status like '%wsrep%;' ）。 您可以通過檢查wsrep_local_state_comment來查看節點狀態。 如果健康節點正在將 SST 傳輸到損壞節點，您將看到 wsrep_local_state_comment 的值為Donor/Desynced 。 有關各種 wsrep 變量的更多詳細信息可以在 Galera 文檔中找到

如果自動 SST 有問題，您可以改為進行手動 SST。 對於 Mariadb 10.1 或更高版本，建議為此使用 Mariabackup。 您可以在 Mariadb 文檔中找到有關使用 Mariabackup 執行手動 SST 的信息。

回答您關於刪除損壞節點上的 datadir 並重新啟動 MySQL 服務的問題：這將強制損壞的節點從另一個節點請求 SST。 請注意，啟動 MySQL 服務可能會超時，因為根據 datadir 的大小，此過程可能需要很長時間。

SST 也會將系統表轉移到損壞的節點上，所以 SST 完成后，mysql.user 表應該是完整的用戶和權限，你應該不需要重新創建它們。

作為旁觀，我看到您使用的是 2 節點 Galera 集群。 一般來說，建議至少使用 3 個節點。 如果您運行的是 2 節點 Galera 集群，您可能需要使用 Galera 仲裁器。 更多信息可以在Galera 文檔中找到