Master-Master複製的恢復策略
我已經實現了基於主-主複製的 mysql 高可用性解決方案。前端部分有一種機制可以保證在給定時間只讀取/寫入一個數據庫（即我們只對 HA 使用複制）。
我已經確認複製按預期工作，但我想知道失敗場景和恢復。特別是，我擔心當一個 master 在不可恢復的狀態下失敗時會發生什麼，需要從另一個 master 重新創建：
- 由於另一個主伺服器是活動的並且很可能已使用，我無法鎖定它並從中創建轉儲
mysqldump（我們的數據庫中等大小，mysqldump使用幾個月後很容易花費數小時）。- 即使假設我有轉儲，顯示 MASTER STATUS 所示的 binlog 位置也必須與數據庫鎖定後正在進行的轉儲相對應。
第一個問題的簡單解決方案是使用第三個數據庫作為備份，我可以從中執行
mysqldump. 但是，如何確保重新創建的 master 可以以一致的方式從正在執行的 master 開始複製？
我知道有兩種基本方法可以解決這個問題。首先，如果您執行的是 InnoDB 而不是 Myisam，那麼您可以在事務中進行備份（–single-transaction –lock-tables=FALSE），它結合了 –flush-logs（不是必需的，但很好）和–master-data 將為您提供具有複製位置資訊的一致備份。刷新日誌將在創建轉儲之前重置日誌，這意味著位置將始終為 106，並且 –master-data 會將日誌文件名稱和位置正確地放在轉儲文件中。當然，您必須在主伺服器上執行它才能使 –master-data 工作。
您提到的第二種方法是使用第三台主機來創建備份。在這種情況下，您需要停止複制，確保數據庫是只讀的（儘管實際上，所有副本都應該是只讀的，因為這不會影響複製的寫入），然後創建備份並記錄複製位置。在這種情況下，您不能使用 –master-data。相反，您可能會執行以下操作：
echo 'stop slave' | mysql {options) mysqldump {your options} > DB.sql echo 'show slave status\G' > DB.replication echo 'start slave' | mysql {options)如果您需要從此備份恢復，您將執行恢復，然後設置複製，其中兩個參數 master_log_file 和 master_log_pos 來自 DB.replication 文件：
master_log_file = value of Master_Log_File master_log_pos = value of Exec_Master_Log_Pos注意：您可以並且應該從另一個副本測試它。
附加說明：如果您有一個副本池（例如，如果您將 Web 應用程序的讀取與寫入分開），則副本可能與新的主伺服器不同步；如果在大量寫入 I/O 期間發生故障轉移，則可能會發生這種情況，因為副本是非同步流式傳輸的，並且無法保證您的備用副本在故障轉移時與其他副本處於相同位置。然而，這還沒有發生在我身上……