對于數據實時同步，其核心是需要基于日志來實現，是可以實現準實時的數據同步，基于日志實現不會要求數據庫本身在設計和實現中帶來任何額外的約束。
這是常見的方案，一般來說，中小型規模的時候，采用這種架構是最省事的。
兩個節點可以采用簡單的雙主模式，并且使用專線連接，在master_A節點發生故障后，應用連接快速切換到master_B節點，反之也亦然。有幾個需要注意的地方，腦裂的情況，兩個節點寫入相同數據而引發沖突，同時把兩個節點的auto_increment_increment（自增步長）和auto_increment_offset（自增起始值）設成不同值。其目的是為了避免master節點意外宕機時，可能會有部分binlog未能及時復制到slave上被應用，從而會導致slave新寫入數據的自增值和原先master上沖突了，因此一開始就使其錯開；當然了，如果有合適的容錯機制能解決主從自增ID沖突的話，也可以不這么做，使用更新的數據版本5.7+，可以利用多線程復制的方式可以很大程度降低復制延遲，同時，對復制延遲特別敏感的另一個備選方案，是semi-sync半同步復制，基本上無延遲，不過事務并發性能會有不小程度的損失，特別是在雙向寫的時候，需要綜合評估再決定。
Galera是Codership提供的多主數據同步復制機制，可以實現多個節點間的數據同步復制以及讀寫，并且可保障數據庫的服務高可用及數據一致性，基于Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster（簡稱PXC）。
目前PXC用的會比較多一些，數據嚴格一致性，尤其適合電商類應用，不過PXC也是有其局限性的，如果并發事務量很大的話，建議采用InfiniBand網絡，降低網絡延遲，因為PXC存在寫擴大以及短板效應，并發效率會有較大損失，類似semi-sync半同步復制，Gelera實際只能用三個節點，網絡抖動造成的性能和穩定性習慣性問題
通過Paxos協議提供數據庫集群節點數據強一致保證，MGR準確來說是MySQL官方推出的高可用解決方案，基于原生復制技術，并以插件的方式提供，并且集群間所有節點可寫入，解決了單個集群的寫入性能，所有節點都能讀寫，解決網絡分區導致的腦裂問題，提升復制數據的可靠性，不過現實還是有些殘酷，目前嘗鮮的并不是很多，同時僅支持InnoDB表，并且每張表一定要有一個主鍵，用于做write set的沖突檢測，必須打開GTID特性，二進制日志格式必須設置為ROW，用于選主與write set
COMMIT可能會導致失敗，類似于快照事務隔離級別的失敗場景，目前一個MGR集群最多支持9個節點，不支持外鍵于save point特性，無法做全局間的約束檢測與部分部分回滾，二進制日志不支持binlog event checksum
對于數據庫的實時同步，阿里巴巴專門有一個開源項目，即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 雙活同步復制四種解決方案，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復大家的。在此也非常感謝大家對VeVb武林網網站的支持！
新聞熱點
疑難解答
