mysql master-master數據複製一致性

Question

正如我們所知，mysql會異步執行復制。我聽說我需要一些額外的插件來做
同步複製。

因此，讓我們考慮異步複製的情況： 主站將事件寫入其二進制日誌，但不知道master2是否或何時檢索並處理它們。使用異步複製，如果master1崩潰，則，它提交的事務可能未傳輸到任何master2。

我的問題是這些事務最終是否會在master1重新啓動後最終複製到master2？如果不是，那麼這是一個很大的不一致問題。

我的問題對於主從複製是一樣的，主控關閉的情況相同。

我是否需要一些特殊的配置參數使其自動發生？

或者我是否必須手動從master1轉出數據並導入到master2等？

======

更新： 我可能誤用了「崩潰」上面，我只想引用該master1未能同步的數據給他人一些時間的情況。下面的回覆（謝謝）涵蓋了兩種情況：由於磁盤故障導致的實際不可恢復崩潰，或者由於網絡問題等造成暫時脫機問題。

Answer 1

如果master1在中斷後重新聯機，並且binlogs天堂不會丟失，那麼奴隸可以下載它遺漏的任何二進制日誌。對於這個討論，master2是一個奴隸。

當然，如果master1的崩潰足夠嚴重，可能會損壞或丟失binlog，那麼您運氣不好。

還有一些情況，其中master1向其數據庫寫入更改，但binlog條目在崩潰中丟失。要解決此風險，您可以設置sync_binlog=1，以便master1上的事務要求相應的binlog條目在磁盤上安全，否則事務無法完成。

但是，在每個COMMIT中將binlogs同步到磁盤有一些開銷，並且許多網站決定他們寧願有比數據安全的性能。確實，有些工作負載每秒鐘的事務處理速度太高，無法實現這一點。即每秒磁盤同步的數量有一個物理上限。那麼解決方案需要獲得更快的磁盤（或SSD），或將工作負載分散到多個服務器上。

我也看到了一種相反的情況：binlog條目被寫入到master1上的文件系統緩存中，並且從屬服務器下載該binlog條目並且從服務器應用它，但該條目永遠不會將其記錄到master1上的磁盤上因爲磁盤有間歇性故障。如此具有諷刺意味的是，奴隸已經處理了從未被委託給主人磁盤的變更！

您提到了同步複製的可能性。 MySQL並不是真的有這個選項。它們最接近的是Semisynchronous Replication，這意味着master1上的事務不允許提交，直到至少有一個半同步從服務器確認它已收到事務的binlog條目。這意味着你永遠不會有像上面描述的差異。但是這會給每個COMMIT增加一些延遲。

爲什麼它是「半」 - 同步？由於master1上的COMMIT不必等待事務在從站上執行，它只需等待從站確認接收到binlog事件。奴隸仍然可以落後。

評論來自@ceejayoz提及Percona XtraDB Cluster。這與半同步複製非常類似，因爲在COMMIT期間，writer節點必須將該事務的日誌傳輸到集羣中的其他節點的所有。所以延遲是最慢的節點確認接收事件的速度。

Answer 2

如果master1崩潰，提交的事務將可在日誌文件，並儘快再次到了，他們將被輸送到從（S），在這種情況下，master2。如果通過您的配置，有可能master1出現故障master2提交了相同的主鍵值，您將會遇到不一致問題。

您可以通過服務器分配不同的主鍵來防止這種情況 - 例如，一個只寫奇數而另一個偶數。甚至是使用服務器ID的組合主鍵。