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

東豐網(wǎng)站制作公司哪家好，找成都創(chuàng)新互聯(lián)公司！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站設(shè)計等網(wǎng)站項目制作，到程序開發(fā)，運營維護。成都創(chuàng)新互聯(lián)公司2013年開創(chuàng)至今到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設(shè)就選成都創(chuàng)新互聯(lián)公司。

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


           另外(master 等待事務(wù)A 的 ACK的時候宕機，此時新事務(wù)B在宕機之前開啟)：
           1> 事務(wù)B讀取不到事務(wù)A的內(nèi)容，因為事務(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ā)送寫一個事務(wù)的binlog。

mysql5.7之后新增ack線程：
        1> master dump thread 發(fā)送binlog events 給 slave 的IO thread，開啟ack線程等待 slave 的ack回包，dump 線程繼續(xù)向slaveIO thread發(fā)送下一個事務(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).
因此在確認事務(wù)復(fù)制到Slave上之前，并發(fā)的事務(wù)看不到當(dāng)前事務(wù)的數(shù)據(jù).
當(dāng)Master出現(xiàn)故障時,所有已經(jīng)提交的事務(wù)都復(fù)制到了Slave上.
缺省采用無數(shù)據(jù)丟失的應(yīng)答等待機制after_sync。用戶也可以選擇使用5.6的應(yīng)答等待機制after_commit

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

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

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