快捷導(dǎo)航

詳解MySQL雙活同步復(fù)制四種解決方案

更新時(shí)間：2018年08月23日 09:02:16 投稿：mrr

這篇文章主要介紹了MySQL 雙活同步復(fù)制四種方案,主從復(fù)制分成三步，本文給大家介紹的非常詳細(xì)，具有一定的參考借鑒價(jià)值，需要的朋友可以參考下

對(duì)于數(shù)據(jù)實(shí)時(shí)同步，其核心是需要基于日志來(lái)實(shí)現(xiàn)，是可以實(shí)現(xiàn)準(zhǔn)實(shí)時(shí)的數(shù)據(jù)同步，基于日志實(shí)現(xiàn)不會(huì)要求數(shù)據(jù)庫(kù)本身在設(shè)計(jì)和實(shí)現(xiàn)中帶來(lái)任何額外的約束。

基于MySQL原生復(fù)制主主同步方案

這是常見(jiàn)的方案，一般來(lái)說(shuō)，中小型規(guī)模的時(shí)候，采用這種架構(gòu)是最省事的。

兩個(gè)節(jié)點(diǎn)可以采用簡(jiǎn)單的雙主模式，并且使用專線連接，在master_A節(jié)點(diǎn)發(fā)生故障后，應(yīng)用連接快速切換到master_B節(jié)點(diǎn)，反之也亦然。有幾個(gè)需要注意的地方，腦裂的情況，兩個(gè)節(jié)點(diǎn)寫(xiě)入相同數(shù)據(jù)而引發(fā)沖突，同時(shí)把兩個(gè)節(jié)點(diǎn)的auto_increment_increment（自增步長(zhǎng)）和auto_increment_offset（自增起始值）設(shè)成不同值。其目的是為了避免master節(jié)點(diǎn)意外宕機(jī)時(shí)，可能會(huì)有部分binlog未能及時(shí)復(fù)制到slave上被應(yīng)用，從而會(huì)導(dǎo)致slave新寫(xiě)入數(shù)據(jù)的自增值和原先master上沖突了，因此一開(kāi)始就使其錯(cuò)開(kāi)；當(dāng)然了，如果有合適的容錯(cuò)機(jī)制能解決主從自增ID沖突的話，也可以不這么做，使用更新的數(shù)據(jù)版本5.7+，可以利用多線程復(fù)制的方式可以很大程度降低復(fù)制延遲，同時(shí)，對(duì)復(fù)制延遲特別敏感的另一個(gè)備選方案，是semi-sync半同步復(fù)制，基本上無(wú)延遲，不過(guò)事務(wù)并發(fā)性能會(huì)有不小程度的損失，特別是在雙向?qū)懙臅r(shí)候，需要綜合評(píng)估再?zèng)Q定。

基于Galera replication方案

Galera是Codership提供的多主數(shù)據(jù)同步復(fù)制機(jī)制，可以實(shí)現(xiàn)多個(gè)節(jié)點(diǎn)間的數(shù)據(jù)同步復(fù)制以及讀寫(xiě)，并且可保障數(shù)據(jù)庫(kù)的服務(wù)高可用及數(shù)據(jù)一致性，基于Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster（簡(jiǎn)稱PXC）。

目前PXC用的會(huì)比較多一些，數(shù)據(jù)嚴(yán)格一致性，尤其適合電商類應(yīng)用，不過(guò)PXC也是有其局限性的，如果并發(fā)事務(wù)量很大的話，建議采用InfiniBand網(wǎng)絡(luò)，降低網(wǎng)絡(luò)延遲，因?yàn)镻XC存在寫(xiě)擴(kuò)大以及短板效應(yīng)，并發(fā)效率會(huì)有較大損失，類似semi-sync半同步復(fù)制，Gelera實(shí)際只能用三個(gè)節(jié)點(diǎn)，網(wǎng)絡(luò)抖動(dòng)造成的性能和穩(wěn)定性習(xí)慣性問(wèn)題

基于Group Replication方案

通過(guò)Paxos協(xié)議提供數(shù)據(jù)庫(kù)集群節(jié)點(diǎn)數(shù)據(jù)強(qiáng)一致保證，MGR準(zhǔn)確來(lái)說(shuō)是MySQL官方推出的高可用解決方案，基于原生復(fù)制技術(shù)，并以插件的方式提供，并且集群間所有節(jié)點(diǎn)可寫(xiě)入，解決了單個(gè)集群的寫(xiě)入性能，所有節(jié)點(diǎn)都能讀寫(xiě)，解決網(wǎng)絡(luò)分區(qū)導(dǎo)致的腦裂問(wèn)題，提升復(fù)制數(shù)據(jù)的可靠性，不過(guò)現(xiàn)實(shí)還是有些殘酷，目前嘗鮮的并不是很多，同時(shí)僅支持InnoDB表，并且每張表一定要有一個(gè)主鍵，用于做write set的沖突檢測(cè)，必須打開(kāi)GTID特性，二進(jìn)制日志格式必須設(shè)置為ROW，用于選主與write set

COMMIT可能會(huì)導(dǎo)致失敗，類似于快照事務(wù)隔離級(jí)別的失敗場(chǎng)景，目前一個(gè)MGR集群最多支持9個(gè)節(jié)點(diǎn)，不支持外鍵于save point特性，無(wú)法做全局間的約束檢測(cè)與部分部分回滾，二進(jìn)制日志不支持binlog event checksum

基于canal方案

對(duì)于數(shù)據(jù)庫(kù)的實(shí)時(shí)同步，阿里巴巴專門有一個(gè)開(kāi)源項(xiàng)目，即otter來(lái)實(shí)現(xiàn)分布式數(shù)據(jù)庫(kù)的同步復(fù)制，其核心思想仍然是通過(guò)獲取數(shù)據(jù)庫(kù)的增量數(shù)據(jù)日志，來(lái)進(jìn)行準(zhǔn)實(shí)時(shí)的同步復(fù)制。因此otter本身又依賴于另外一個(gè)開(kāi)源項(xiàng)目即canal，該項(xiàng)目重點(diǎn)則是獲取增量數(shù)據(jù)庫(kù)同步日志信息。

當(dāng)前otter的重點(diǎn)是實(shí)現(xiàn)mysql間的數(shù)據(jù)庫(kù)同步復(fù)制，基本即利用的類似技術(shù)來(lái)實(shí)現(xiàn)兩個(gè)mysql數(shù)據(jù)庫(kù)間的雙向同步數(shù)據(jù)庫(kù)復(fù)制。要注意這個(gè)雙向本身指既可以A->B，也可以從B->A，在某個(gè)時(shí)間節(jié)點(diǎn)本身是單向的。

主從復(fù)制分成三步：