對于數據實時同步,其核心是需要基于日志來實現,是可以實現準實時的數據同步,基于日志實現不會要求數據庫本身在設計和實現中帶來任何額外的約束。

這是常見的方案,一般來說,中小型規模的時候,采用這種架構是最省事的。
兩個節點可以采用簡單的雙主模式,并且使用專線連接,在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
新聞熱點
疑難解答