目錄
- 基于MySQL原生復(fù)制主主同步方案
- 基于Galera replication方案
- 基于Group Replication方案
- 基于canal方案
對(duì)于數(shù)據(jù)實(shí)時(shí)同步,其核心是需要基于日志來實(shí)現(xiàn),是可以實(shí)現(xiàn)準(zhǔn)實(shí)時(shí)的數(shù)據(jù)同步,基于日志實(shí)現(xiàn)不會(huì)要求數(shù)據(jù)庫(kù)本身在設(shè)計(jì)和實(shí)現(xiàn)中帶來任何額外的約束。
基于MySQL原生復(fù)制主主同步方案
這是常見的方案,一般來說,中小型規(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)寫入相同數(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新寫入數(shù)據(jù)的自增值和原先master上沖突了,因此一開始就使其錯(cuò)開;當(dāng)然了,如果有合適的容錯(cuò)機(jī)制能解決主從自增ID沖突的話,也可以不這么做,使用更新的數(shù)據(jù)版本5.7+,可以利用多線程復(fù)制的方式可以很大程度降低復(fù)制延遲,同時(shí),對(duì)復(fù)制延遲特別敏感的另一個(gè)備選方案,是semi-sync半同步復(fù)制,基本上無延遲,不過事務(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ù)制以及讀寫,并且可保障數(shù)據(jù)庫(kù)的服務(wù)高可用及數(shù)據(jù)一致性,基于Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster(簡(jiǎn)稱PXC)。
目前PXC用的會(huì)比較多一些,數(shù)據(jù)嚴(yán)格一致性,尤其適合電商類應(yīng)用,不過PXC也是有其局限性的,如果并發(fā)事務(wù)量很大的話,建議采用InfiniBand網(wǎng)絡(luò),降低網(wǎng)絡(luò)延遲,因?yàn)镻XC存在寫擴(kuò)大以及短板效應(yīng),并發(fā)效率會(huì)有較大損失,類似semi-sync半同步復(fù)制,Gelera實(shí)際只能用三個(gè)節(jié)點(diǎn),網(wǎng)絡(luò)抖動(dòng)造成的性能和穩(wěn)定性習(xí)慣性問題
基于Group Replication方案
通過Paxos協(xié)議提供數(shù)據(jù)庫(kù)集群節(jié)點(diǎn)數(shù)據(jù)強(qiáng)一致保證,MGR準(zhǔn)確來說是MySQL官方推出的高可用解決方案,基于原生復(fù)制技術(shù),并以插件的方式提供,并且集群間所有節(jié)點(diǎn)可寫入,解決了單個(gè)集群的寫入性能,所有節(jié)點(diǎn)都能讀寫,解決網(wǎng)絡(luò)分區(qū)導(dǎo)致的腦裂問題,提升復(fù)制數(shù)據(jù)的可靠性,不過現(xiàn)實(shí)還是有些殘酷,目前嘗鮮的并不是很多,同時(shí)僅支持InnoDB表,并且每張表一定要有一個(gè)主鍵,用于做write set的沖突檢測(cè),必須打開GTID特性,二進(jìn)制日志格式必須設(shè)置為ROW,用于選主與write set
COMMIT可能會(huì)導(dǎo)致失敗,類似于快照事務(wù)隔離級(jí)別的失敗場(chǎng)景,目前一個(gè)MGR集群最多支持9個(gè)節(jié)點(diǎn),不支持外鍵于save point特性,無法做全局間的約束檢測(cè)與部分部分回滾,二進(jìn)制日志不支持binlog event checksum
基于canal方案
對(duì)于數(shù)據(jù)庫(kù)的實(shí)時(shí)同步,阿里巴巴專門有一個(gè)開源項(xiàng)目,即otter來實(shí)現(xiàn)分布式數(shù)據(jù)庫(kù)的同步復(fù)制,其核心思想仍然是通過獲取數(shù)據(jù)庫(kù)的增量數(shù)據(jù)日志,來進(jìn)行準(zhǔn)實(shí)時(shí)的同步復(fù)制。因此otter本身又依賴于另外一個(gè)開源項(xiàng)目即canal,該項(xiàng)目重點(diǎn)則是獲取增量數(shù)據(jù)庫(kù)同步日志信息。
當(dāng)前otter的重點(diǎn)是實(shí)現(xiàn)mysql間的數(shù)據(jù)庫(kù)同步復(fù)制,基本即利用的類似技術(shù)來實(shí)現(xiàn)兩個(gè)mysql數(shù)據(jù)庫(kù)間的雙向同步數(shù)據(jù)庫(kù)復(fù)制。要注意這個(gè)雙向本身指既可以A->B,也可以從B->A,在某個(gè)時(shí)間節(jié)點(diǎn)本身是單向的。
主從復(fù)制分成三步:
master將改變記錄到二進(jìn)制日志(binary log)中(這些記錄叫做二進(jìn)制日志事件,binary log events,可以通過show binlog events進(jìn)行查看);
slave將master的binary log events拷貝到它的中繼日志(relay log);
slave重做中繼日志中的事件,將改變反映它自己的數(shù)據(jù)。
canal原理相對(duì)比較簡(jiǎn)單:
canal模擬mysql slave的交互協(xié)議,偽裝自己為mysql slave,向mysql master發(fā)送dump協(xié)議
mysql master收到dump請(qǐng)求,開始推送binary log給slave(也就是canal)
canal解析binary log對(duì)象(原始為byte流)
更多參考 https://github.com/alibaba/canal
總結(jié)
以上所述是小編給大家介紹的MySQL 雙活同步復(fù)制四種解決方案,希望對(duì)大家有所幫助,如果大家有任何疑問請(qǐng)給我留言,小編會(huì)及時(shí)回復(fù)大家的。在此也非常感謝大家對(duì)腳本之家網(wǎng)站的支持!
您可能感興趣的文章:- MySQL主從復(fù)制的原理及配置方法(比較詳細(xì))
- mysql中復(fù)制表結(jié)構(gòu)的方法小結(jié)
- MySQL復(fù)制表結(jié)構(gòu)和內(nèi)容到另一張表中的SQL語(yǔ)句
- MySQL快速?gòu)?fù)制數(shù)據(jù)庫(kù)數(shù)據(jù)表的方法
- Mysql主從復(fù)制(master-slave)實(shí)際操作案例
- mysql主從同步復(fù)制錯(cuò)誤解決一例
- mysql跨數(shù)據(jù)庫(kù)復(fù)制表(在同一IP地址中)示例
- mysql同步復(fù)制搭建方法指南詳細(xì)步驟
- 簡(jiǎn)單講解MySQL的數(shù)據(jù)庫(kù)復(fù)制方法
- MySQL 數(shù)據(jù)庫(kù)雙向鏡像、循環(huán)鏡像(復(fù)制)
- mysql 復(fù)制原理與實(shí)踐應(yīng)用詳解