MySQL中AFTER_SYNC/AFTER_COMMIT的過程分析

本篇內(nèi)容主要講解“MySQL中AFTER_SYNC/AFTER_COMMIT的過程分析”，感興趣的朋友不妨來看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“MySQL中AFTER_SYNC/AFTER_COMMIT的過程分析”吧!

MySQL 5.7增強(qiáng)了半同步復(fù)制，rpl_semi_sync_master_wait_point增加了AFTER_SYNC的值，由該參數(shù)AFTER_SYNC/AFTER_COMMIT兩個(gè)值選擇是否啟用增強(qiáng)半同步.
mysql> SET rpl_semi_sync_master_wait_point= AFTER_SYNC;  開啟了mysql 5.7增強(qiáng)半同步，5.7默認(rèn)就是開啟的；
mysql> SET rpl_semi_sync_master_wait_point= AFTER_COMMIT;   5.6的半同步方式；           
當(dāng)半同步模式為 AFTER_COMMIT時(shí):
過程分析如下：
        1 > session 發(fā)出commit請(qǐng)求
        2 > flush binlog and fsync binlog
        3 > InnoDB 引擎層 commit 
        4 > 發(fā)送binlog到SLAVE，等待slave發(fā)送ack確認(rèn)
        5 > slave 接受binlog 寫入relay log ，刷盤完成發(fā)送ack確認(rèn)包給master
        6 > master 返回 commit ok 信息給session
        
        另外 (master 等待事務(wù)A 的 ACK的時(shí)候宕機(jī)，此時(shí)新事務(wù)B在宕機(jī)之前開啟)：
        1> binlog 未發(fā)送到從庫(kù):
            事務(wù)B獲取到事務(wù)A提交的內(nèi)容， 此時(shí)宕機(jī)故障切換到slave，事務(wù)B獲取到的內(nèi)容卻丟失了。事務(wù)A commit沒有收到反饋信息(則需要業(yè)務(wù)判斷了)。
        2> binlog 已經(jīng)發(fā)送給從庫(kù) :
            事務(wù)B獲取到事務(wù)A提交的內(nèi)容，故障切換到salve ，B仍然獲取到A提交的內(nèi)容，沒毛病。事務(wù)A commit沒有收到反饋信息，若重新執(zhí)行該事務(wù)，則相當(dāng)于執(zhí)行兩次A事務(wù)(則需要業(yè)務(wù)判斷了)。


當(dāng)半同步模式為 AFTER_SYNC(5.7版本推薦使用)時(shí):
過程分析如下：
           1 > session 發(fā)出commit請(qǐng)求
           2 > flush binlog and fsync binlog
           3 > 發(fā)送binlog到SLAVE，等待slave發(fā)送ack確認(rèn)
           4 > slave 接受binlog 寫入relay log ，刷盤完成發(fā)送ack確認(rèn)包給master
           5 > InnoDB 引擎層 commit 
           6 > master 返回 commit ok 信息給session


           另外(master 等待事務(wù)A 的 ACK的時(shí)候宕機(jī)，此時(shí)新事務(wù)B在宕機(jī)之前開啟)：
           1> 事務(wù)B讀取不到事務(wù)A的內(nèi)容，因?yàn)槭聞?wù)A的ENGINE層還沒有提交(無損復(fù)制)

dump thread過程分析:
 mysql5.6版本之前：
        1> master dump thread 發(fā)送binlog events 給 slave 的IO thread，等待 slave 的ack回包
        2> slave 接受binlog events 寫入redo log ，返回 ack 包給master dump thread
        3> master dump thread 收到ack包 ，給session返回commit ok，然后繼續(xù)發(fā)送寫一個(gè)事務(wù)的binlog。

mysql5.7之后新增ack線程：
        1> master dump thread 發(fā)送binlog events 給 slave 的IO thread，開啟ack線程等待 slave 的ack回包，dump 線程繼續(xù)向slaveIO thread發(fā)送下一個(gè)事務(wù)的binlog。
        2> slave 接受binlog events 寫入redo log ，返回 ack 包給master ack線程，然后給session返回commit ok。


過程總結(jié):
Master在收到slave的應(yīng)答后才Commit事務(wù)--after_sync(5.6上Master在commit后，才等待Slave的應(yīng)答--after commit).
因此在確認(rèn)事務(wù)復(fù)制到Slave上之前，并發(fā)的事務(wù)看不到當(dāng)前事務(wù)的數(shù)據(jù).
當(dāng)Master出現(xiàn)故障時(shí),所有已經(jīng)提交的事務(wù)都復(fù)制到了Slave上.
缺省采用無數(shù)據(jù)丟失的應(yīng)答等待機(jī)制after_sync。用戶也可以選擇使用5.6的應(yīng)答等待機(jī)制after_commit

設(shè)置方法:
mysql> SET rpl_semi_sync_master_wait_point= AFTER_SYNC;

Master接收到N個(gè)slave的應(yīng)答后，才commit 事務(wù).
用戶可以設(shè)置應(yīng)答Slave的數(shù)量:
mysql> SET GLOBAL rpl_semi_sync_master_wait_for_slave_count= N；

到此，相信大家對(duì)“MySQL中AFTER_SYNC/AFTER_COMMIT的過程分析”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！