對於資料實時同步，其核心是需要基於日誌來實現，是可以實現準實時的資料同步，基於日誌實現不會要求資料庫本身在設計和實現中帶來任何額外的約束。

基於MySQL原生複製主主同步方案

這是常見的方案，一般來說，中小型規模的時候，採用這種架構是最省事的。

兩個節點可以採用簡單的雙主模式，並且使用專線連線，在master_A節點發生故障後，應用連線快速切換到master_B節點，反之也亦然。有幾個需要注意的地方，腦裂的情況，兩個節點寫入相同資料而引發衝突，同時把兩個節點的auto_increment_increment（自增步長）和auto_increment_offset（自增起始值）設成不同值。其目的是為了避免master節點意外宕機時，可能會有部分binlog未能及時複製到slave上被應用，從而會導致slave新寫入資料的自增值和原先master上衝突了，因此一開始就使其錯開；當然了，如果有合適的容錯機制能解決主從自增ID衝突的話，也可以不這麼做，使用更新的資料版本5.7+，可以利用多執行緒複製的方式可以很大程度降低複製延遲，同時，對複製延遲特別敏感的另一個備選方案，是semi-sync半同步複製，基本上無延遲，不過事務併發效能會有不小程度的損失，特別是在雙向寫的時候，需要綜合評估再決定。

基於Galera replication方案

Galera是Codership提供的多主資料同步複製機制，可以實現多個節點間的資料同步複製以及讀寫，並且可保障資料庫的服務高可用及資料一致性，基於Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster（簡稱PXC）。

目前PXC用的會比較多一些，資料嚴格一致性，尤其適合電商類應用，不過PXC也是有其侷限性的，如果併發事務量很大的話，建議採用InfiniBand網路，降低網路延遲，因為PXC存在寫擴大以及短板效應，併發效率會有較大損失，類似semi-sync半同步複製，Gelera實際只能用三個節點，網路抖動造成的效能和穩定性習慣性問題

基於Group Replication方案

通過Paxos協議提供資料庫叢集節點資料強一致保證，MGR準確來說是MySQL官方推出的高可用解決方案，基於原生複製技術，並以外掛的方式提供，並且叢集間所有節點可寫入，解決了單個叢集的寫入效能，所有節點都能讀寫，解決網路分割槽導致的腦裂問題，提升複製資料的可靠性，不過現實還是有些殘酷，目前嚐鮮的並不是很多，同時僅支援InnoDB表，並且每張表一定要有一個主鍵，用於做write set的衝突檢測，必須開啟GTID特性，二進位制日誌格式必須設定為ROW，用於選主與write set

COMMIT可能會導致失敗，類似於快照事務隔離級別的失敗場景，目前一個MGR叢集最多支援9個節點，不支援外來鍵於save point特性，無法做全域性間的約束檢測與部分部分回滾，二進位制日誌不支援binlog event checksum

基於canal方案

對於資料庫的實時同步，阿里巴巴專門有一個開源專案，即otter來實現分散式資料庫的同步複製，其核心思想仍然是通過獲取資料庫的增量資料日誌，來進行準實時的同步複製。因此otter本身又依賴於另外一個開源專案即canal，該專案重點則是獲取增量資料庫同步日誌資訊。

當前otter的重點是實現mysql間的資料庫同步複製，基本即利用的類似技術來實現兩個mysql資料庫間的雙向同步資料庫複製。要注意這個雙向本身指既可以A->B，也可以從B->A，在某個時間節點本身是單向的。

主從複製分成三步：

master將改變記錄到二進位制日誌(binary log)中（這些記錄叫做二進位制日誌事件，binary log events，可以通過show binlog events進行檢視）；

slave將master的binary log events拷貝到它的中繼日誌(relay log)；

slave重做中繼日誌中的事件，將改變反映它自己的資料。

canal原理相對比較簡單：

canal模擬mysql slave的互動協議，偽裝自己為mysql slave，向mysql master傳送dump協議

mysql master收到dump請求，開始推送binary log給slave(也就是canal)
canal解析binary log物件(原始為byte流)

更多參考 https://github.com/alibaba/canal

總結

以上所述是小編給大家介紹的MySQL 雙活同步複製四種解決方案，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回覆大家的。在此也非常感謝大家對我們網站的支援！