MySQL中AFTER_SYNC/AFTER_COMMIT的過程分析

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

MySQL 5.7增強了半同步復制，rpl_semi_sync_master_wait_point增加了AFTER_SYNC的值，由該參數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的半同步方式；           
當半同步模式為 AFTER_COMMIT時:
過程分析如下：
        1 > session 發出commit請求
        2 > flush binlog and fsync binlog
        3 > InnoDB 引擎層 commit 
        4 > 發送binlog到SLAVE，等待slave發送ack確認
        5 > slave 接受binlog 寫入relay log ，刷盤完成發送ack確認包給master
        6 > master 返回 commit ok 信息給session
        
        另外 (master 等待事務A 的 ACK的時候宕機，此時新事務B在宕機之前開啟)：
        1> binlog 未發送到從庫:
            事務B獲取到事務A提交的內容， 此時宕機故障切換到slave，事務B獲取到的內容卻丟失了。事務A commit沒有收到反饋信息(則需要業務判斷了)。
        2> binlog 已經發送給從庫 :
            事務B獲取到事務A提交的內容，故障切換到salve ，B仍然獲取到A提交的內容，沒毛病。事務A commit沒有收到反饋信息，若重新執行該事務，則相當于執行兩次A事務(則需要業務判斷了)。


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


           另外(master 等待事務A 的 ACK的時候宕機，此時新事務B在宕機之前開啟)：
           1> 事務B讀取不到事務A的內容，因為事務A的ENGINE層還沒有提交(無損復制)

dump thread過程分析:
 mysql5.6版本之前：
        1> master dump thread 發送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，然后繼續發送寫一個事務的binlog。

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


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

設置方法:
mysql> SET rpl_semi_sync_master_wait_point= AFTER_SYNC;

Master接收到N個slave的應答后，才commit 事務.
用戶可以設置應答Slave的數量:
mysql> SET GLOBAL rpl_semi_sync_master_wait_for_slave_count= N；

到此，相信大家對“MySQL中AFTER_SYNC/AFTER_COMMIT的過程分析”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！