《Mysql應(yīng)用簡單談?wù)凪ySQL的半同步復(fù)制》要點:
本文介紹了Mysql應(yīng)用簡單談?wù)凪ySQL的半同步復(fù)制,希望對您有用。如果有疑問,可以聯(lián)系我們。
簡介MYSQL應(yīng)用
MySQL通過復(fù)制(Replication)實現(xiàn)存儲系統(tǒng)的高可用.目前,MySQL支持的復(fù)制方式有:MYSQL應(yīng)用
本文主要討論MySQL半同步復(fù)制.MYSQL應(yīng)用
半同步復(fù)制的基本流程MYSQL應(yīng)用
MySQL半同步復(fù)制的實現(xiàn)是建立在MySQL異步復(fù)制的基礎(chǔ)上的.MySQL支持兩種略有不同的半同步復(fù)制:AFTER_SYNC和AFTER_COMMIT(受rpl_semi_sync_master_wait_wait_point控制).MYSQL應(yīng)用
開啟半同步復(fù)制時,Master在返回之前會等待Slave的響應(yīng)或超時.當(dāng)Slave超時時,半同步復(fù)制退化成異步復(fù)制.這也是MySQL半同步復(fù)制存在的一個問題.本文不討論Salve超時的情形(不討論異步復(fù)制).MYSQL應(yīng)用
半同步復(fù)制AFTER_SYNC模式的基本流程MYSQL應(yīng)用
AFTER_SYNC模式是MySQL 5.7才支持的半同步復(fù)制方式,也是MySQL5.7默認(rèn)的半同步復(fù)制方式:MYSQL應(yīng)用
半同步復(fù)制AFTER_COMMIT模式的基本流程MYSQL應(yīng)用
MySQL 5.5和5.6的半同步復(fù)制只支持AFTER_COMMIT:MYSQL應(yīng)用
AFTER_SYNC和AFTER_COMMIT兩種方式的小結(jié)MYSQL應(yīng)用
AFTER_SYNC: 日志復(fù)制到Slave之后,Master再commit.
所有在master上commit的事務(wù)都已經(jīng)復(fù)制到slave.
所有已經(jīng)復(fù)制到slave的事務(wù)在master不一定commit了(比如,master將日志復(fù)制到slave之后,在commit之前宕機(jī)了)
MYSQL應(yīng)用
AFTER_COMMIT:Master commit之后再將日志復(fù)制到Slave.
所有master上commit的事務(wù)不一定復(fù)制到slave.(比如,master commit之后,還沒來得及將日志復(fù)制到slave就宕機(jī)了)
所有已經(jīng)復(fù)制到slave的事務(wù)在master上一定commit了.
很明顯,AFTER_COMMIT在master宕機(jī)的情況下,無法保證數(shù)據(jù)的一致性(master commit之后,還沒來得及將日志復(fù)制到slave就宕機(jī)了).本文接下來只討論AFTER_SYNC模式.
MySQL5.7.3開始支持配置半同步復(fù)制等待Slave應(yīng)答的個數(shù):rpl_semi_sync_master_wait_slave_count .
MYSQL應(yīng)用
AFTER_SYNC模式下的異常情況分析MYSQL應(yīng)用
異常情況1:master宕機(jī)后,主備切換.MYSQL應(yīng)用
master執(zhí)行事務(wù)T,在將事務(wù)T的binlog刷到硬盤之前,master發(fā)生宕機(jī).slave升級為master.master重啟后,crash recovery會對事務(wù)T進(jìn)行回滾.主備數(shù)據(jù)一致.MYSQL應(yīng)用
master執(zhí)行事務(wù)T,在將事務(wù)T的binlog刷到硬盤之后,收到slave的ACK之前,master發(fā)生宕機(jī)(存在pendinglog).slave升級為master.MYSQL應(yīng)用
2.1 slave還沒有收到事務(wù)T的binlog,master重啟后,crash recovery會直接提交pendinglog.主備數(shù)據(jù)不一致.MYSQL應(yīng)用
2.2 slave已經(jīng)收到事務(wù)T的binlog.主備數(shù)據(jù)一致.MYSQL應(yīng)用
異常情況2:master宕機(jī)后,不切換主機(jī).只需考慮異常情況1中的2.1.MYSQL應(yīng)用
master重啟后,直接提交pendinglog,此時,主備數(shù)據(jù)不一致:MYSQL應(yīng)用
slave連接上master,通過異步復(fù)制的方式獲得事務(wù)T的binlog.主備數(shù)據(jù)一致.
slave還沒來得及復(fù)制事務(wù)T的binlog,如果master又發(fā)生宕機(jī),磁盤損壞.主備數(shù)據(jù)不一致,事務(wù)T的數(shù)據(jù)丟失.
異常情況處理MYSQL應(yīng)用
從上面異常情況的簡單分析我們得知,半同步復(fù)制需要處理master宕機(jī)后重啟存在pendinglog(slave沒有應(yīng)答的binlog)的特殊情況.MYSQL應(yīng)用
針對master宕機(jī)后,不進(jìn)行主備切換的情形:
MYSQL應(yīng)用
在crash recovery之后,master等到slave的連接和復(fù)制,直到至少有一個slave復(fù)制了所有已提交的事務(wù)的binlog.(SHOW MASTER STATUS on master and SELECT master_pos_wait()? on slave).MYSQL應(yīng)用
針對master宕機(jī)后,進(jìn)行主備切換的情形:
MYSQL應(yīng)用
舊master重啟后,在crash recovery時,對pendinglog進(jìn)行回滾.(人工截斷master的binlog未復(fù)制的部分?)MYSQL應(yīng)用
思考MYSQL應(yīng)用
為什么master重啟之后,crash recovery的過程中,是直接commit pendinglog,而不是重試請求slave的應(yīng)答呢?MYSQL應(yīng)用
MySQL的異步復(fù)制和半同步復(fù)制都是由slave觸發(fā)的,slave主動去連接master同步binlog.MYSQL應(yīng)用
沒有發(fā)生主備切換,機(jī)器重啟后無法知道哪臺機(jī)器是slave.
如果發(fā)生主備切換,它已經(jīng)不是master了,則不會再有slave連上來.如果繼續(xù)等待,則無法正常運行.
MYSQL應(yīng)用
總結(jié)MYSQL應(yīng)用
MySQL半同步復(fù)制存在以下問題:MYSQL應(yīng)用
正因為MySQL在主備數(shù)據(jù)一致性存在著這些問題,影響了互聯(lián)網(wǎng)業(yè)務(wù)7*24的高可用服務(wù),因此各大公司紛紛祭出自己的“補(bǔ)丁”:騰訊的TDSQL、微信的PhxSQL、阿里的AliSQL、網(wǎng)易的InnoSQL.MYSQL應(yīng)用
MySQL官方已經(jīng)在MySQL5.7推出新的復(fù)制模式――MySQL Group Replication.MYSQL應(yīng)用
參考文獻(xiàn)MYSQL應(yīng)用
MySQL半同步復(fù)制的數(shù)據(jù)一致性探討MYSQL應(yīng)用
MySQL High Availability SolutionsMYSQL應(yīng)用
Loss-less Semi-Synchronous Replication on MySQL 5.7.2MYSQL應(yīng)用
Enhanced semisync replicationMYSQL應(yīng)用
轉(zhuǎn)載請注明本頁網(wǎng)址:
http://www.fzlkiss.com/jiaocheng/5214.html