欧美97色伦欧美一区二区日韩,国产福利片在线观看,freexxx性欧美vide0高清,西西亚洲,日本欧美国产精品第一页久久,成人18免费软件

當前位置： 維易PHP培訓學院 > MYSQL教程 > 內容正文

Mysql應用簡單談談MySQL的半同步復制

作者：VEPHP   時間 2017-09-28

《Mysql應用簡單談談MySQL的半同步復制》要點：
本文介紹了Mysql應用簡單談談MySQL的半同步復制，希望對您有用。如果有疑問，可以聯系我們。

簡介MYSQL應用

MySQL通過復制(Replication)實現存儲系統的高可用.目前,MySQL支持的復制方式有：MYSQL應用

  1. 異步復制(Asynchronous Replication)：原理最簡單,性能最好.但是主備之間數據不一致的概率很大.
  2. 半同步復制(Semi-synchronous Replication)：相比異步復制,半同步復制犧牲了一定的性能,提升了主備之間數據的一致性(有一些情況還是會出現主備數據不一致).
  3. 組復制(Group Replication)：基于Paxos算法實現分布式數據復制的強一致性.只要大多數機器存活就能保證系統可用.相比半同步復制,Group Replication的數據一致性和系統可用性更高.

本文主要討論MySQL半同步復制.MYSQL應用

半同步復制的基本流程MYSQL應用

MySQL半同步復制的實現是建立在MySQL異步復制的基礎上的.MySQL支持兩種略有不同的半同步復制：AFTER_SYNC和AFTER_COMMIT(受rpl_semi_sync_master_wait_wait_point控制).MYSQL應用

開啟半同步復制時,Master在返回之前會等待Slave的響應或超時.當Slave超時時,半同步復制退化成異步復制.這也是MySQL半同步復制存在的一個問題.本文不討論Salve超時的情形(不討論異步復制).MYSQL應用

半同步復制AFTER_SYNC模式的基本流程MYSQL應用

AFTER_SYNC模式是MySQL 5.7才支持的半同步復制方式,也是MySQL5.7默認的半同步復制方式：MYSQL應用

  • Prepare the transaction in the storage engine(s).
  • Write the transaction to the binlog, flush the binlog to disk.
  • Wait for at least one slave to acknowledge the reception for the binlog events for the transaction.
  • Commit the transaction to the storage engine(s).

半同步復制AFTER_COMMIT模式的基本流程MYSQL應用

MySQL 5.5和5.6的半同步復制只支持AFTER_COMMIT：MYSQL應用

  • Prepare the transaction in the storage engine(s).
  • Write the transaction to the binlog, flush the binlog to disk.
  • Commit the transaction to the storage engine(s).
  • Wait for at least one slave to acknowledge the reception for the binlog events for the transaction.

AFTER_SYNC和AFTER_COMMIT兩種方式的小結MYSQL應用

AFTER_SYNC： 日志復制到Slave之后,Master再commit.
所有在master上commit的事務都已經復制到slave.
所有已經復制到slave的事務在master不一定commit了(比如,master將日志復制到slave之后,在commit之前宕機了)
MYSQL應用

AFTER_COMMIT：Master commit之后再將日志復制到Slave.
所有master上commit的事務不一定復制到slave.(比如,master commit之后,還沒來得及將日志復制到slave就宕機了)
所有已經復制到slave的事務在master上一定commit了.
很明顯,AFTER_COMMIT在master宕機的情況下,無法保證數據的一致性(master commit之后,還沒來得及將日志復制到slave就宕機了).本文接下來只討論AFTER_SYNC模式.
MySQL5.7.3開始支持配置半同步復制等待Slave應答的個數：rpl_semi_sync_master_wait_slave_count .
MYSQL應用

AFTER_SYNC模式下的異常情況分析MYSQL應用

異常情況1：master宕機后,主備切換.MYSQL應用

master執行事務T,在將事務T的binlog刷到硬盤之前,master發生宕機.slave升級為master.master重啟后,crash recovery會對事務T進行回滾.主備數據一致.MYSQL應用

master執行事務T,在將事務T的binlog刷到硬盤之后,收到slave的ACK之前,master發生宕機(存在pendinglog).slave升級為master.MYSQL應用

2.1 slave還沒有收到事務T的binlog,master重啟后,crash recovery會直接提交pendinglog.主備數據不一致.MYSQL應用

2.2 slave已經收到事務T的binlog.主備數據一致.MYSQL應用

異常情況2：master宕機后,不切換主機.只需考慮異常情況1中的2.1.MYSQL應用

master重啟后,直接提交pendinglog,此時,主備數據不一致：MYSQL應用

slave連接上master,通過異步復制的方式獲得事務T的binlog.主備數據一致.
slave還沒來得及復制事務T的binlog,如果master又發生宕機,磁盤損壞.主備數據不一致,事務T的數據丟失.
異常情況處理MYSQL應用

從上面異常情況的簡單分析我們得知,半同步復制需要處理master宕機后重啟存在pendinglog(slave沒有應答的binlog)的特殊情況.MYSQL應用

針對master宕機后,不進行主備切換的情形：
MYSQL應用

在crash recovery之后,master等到slave的連接和復制,直到至少有一個slave復制了所有已提交的事務的binlog.(SHOW MASTER STATUS on master and SELECT master_pos_wait()? on slave).MYSQL應用

針對master宕機后,進行主備切換的情形：
MYSQL應用

舊master重啟后,在crash recovery時,對pendinglog進行回滾.(人工截斷master的binlog未復制的部分?)MYSQL應用

思考MYSQL應用

為什么master重啟之后,crash recovery的過程中,是直接commit pendinglog,而不是重試請求slave的應答呢?MYSQL應用

MySQL的異步復制和半同步復制都是由slave觸發的,slave主動去連接master同步binlog.MYSQL應用

沒有發生主備切換,機器重啟后無法知道哪臺機器是slave.
如果發生主備切換,它已經不是master了,則不會再有slave連上來.如果繼續等待,則無法正常運行.
MYSQL應用

總結MYSQL應用

MySQL半同步復制存在以下問題：MYSQL應用

  1. 當Slave超時時,會退化成異步復制.
  2. 當Master宕機時,數據一致性無法保證,需要人工處理.
  3. 復制是串行的.

正因為MySQL在主備數據一致性存在著這些問題,影響了互聯網業務7*24的高可用服務,因此各大公司紛紛祭出自己的“補丁”：騰訊的TDSQL、微信的PhxSQL、阿里的AliSQL、網易的InnoSQL.MYSQL應用

MySQL官方已經在MySQL5.7推出新的復制模式――MySQL Group Replication.MYSQL應用

參考文獻MYSQL應用

MySQL半同步復制的數據一致性探討MYSQL應用

MySQL High Availability SolutionsMYSQL應用

Loss-less Semi-Synchronous Replication on MySQL 5.7.2MYSQL應用

Enhanced semisync replicationMYSQL應用

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/5214.html


    標簽：