805
從源碼探究MySQL5.7高吞吐事務量的背後操手
大家都知道在MySQL中，在事務真正COMMIT之前，會將事務的binlog日誌寫入到binlog文件中。在MySQL的5.7版本中，提供了所謂的無損複製功能，該功能的作用就是在主庫的事務對其他的會話線程可見之前，就將該事務的日誌同步到從庫，保證了事務可以安全地無丟失地複製到從庫。
下麵我們從源碼來分析MySQL的事務提交以及事務在何時將binlog複製到從庫的。
MYSQL_BIN_LOG::ordered_commit，這個是事務在binlog階段提交的核心函數，通過該函數，實現了事務日誌寫入binlog文件，以及觸發dump線程將binlog發送到Slave，在最後的步驟，將事務設置為提交狀態。
我們來分析MYSQL_BIN_LOG::ordered_commit這個函數的核心過程，該函數位於binlog.cc文件中。
源碼分析
MYSQL_BIN_LOG::ordered_commit，這個函數，核心步驟如下：
第一步驟：flush
Stage#1: flushing transactions to binary log:
步驟1 ：將事務的日誌寫入binlog文件的buffer中，函數如下：
process_flush_stage_queue(&total_bytes,&do_rotate, &wait_queue);
從5.6開始，MySQL引入了Group Commit的概念，這樣可以避免每個事務提交都會鎖定一次binlog。
另外，還有一個用處，就是MySQL5.7的基於logical_clock的並行複製。在一個組裏麵（其實是一個隊列），這一組隊列的頭事務是相同的，因此這一組事務的last_committed（上一組的最後一個提交的事務）的事務也是同一個。我們都知道，last_committed相同的事務，是可以在從庫並行relay（重演）的。
該函數process_flush_stage_queue的作用，就是將commit隊列中的線程一個一個地取出，然後執行子函數 flush_thread_caches(head)；循環的代碼如下：將各自線程中的binlog cache寫入到binlog中。
/* Flush thread caches to binary log. */
for (THD *head= first_seen ; head ; head = head->next_to_commit)
{
std::pairresult= flush_thread_caches(head);,my_off_t>
total_bytes+= result.second;
if(flush_error == 1)
flush_error= result.first;
#ifndef DBUG_OFF
no_flushes++;
#endif
}
第二步驟：SYNC to disk
Stage#2: Syncing binary log file to disk
第二步：將binlog file中cache的部分寫入disk.但這個步驟參數sync_binlog起決定性的作用。
我們來看看源碼，除了這些還有哪些細節步驟，聽完源碼分析之後，你應該有新的收獲與理解。在執行真正的將binlog寫到磁盤之前，會進行一個等待，函數如下：
stage_manager.wait_count_or_timeout(opt_binlog_group_commit_sync_no_delay_count,
opt_binlog_group_commit_sync_delay,
Stage_manager::SYNC_STAGE);
等待的時間由MySQL參數文件中的binlog_group_commit_sync_delay，binlog_group_commit_sync_no_delay_count 這兩參數共同決定。第一個表示該事務組提交之前總共等待累積到多少個事務，第二個參數則表示該事務組總共等待多長時間後進行提交，任何一個條件滿足則進行後續操作。
因為有這個等待，可以讓更多事務的binlog通過一次寫binlog文件磁盤來完成提交，從而獲得更高的吞吐量。
接下來，就是執行sync_binlog_file，該函數會用到MySQL參數文件中sync_binlog參數的值，如果為0，則不進行寫磁盤操作，由操作係統決定什麼時候刷盤，如果為1，則強製進行寫磁盤操作。
再接下來，執行update_binlog_end_pos函數，用來更新binlog文件的最後的位置binlog_end_pos，該binlog_end_pos是一個全局的變量。在執行更新該位置之前，先得找到最後一個提交事務的線程（因為是Group Commit，多個事務排隊提交的機製）。因為已經將要提交事務的線程組成了一個鏈表，所以通過從頭到尾找，可以找到最後一個線程。代碼如下：
if(update_binlog_end_pos_after_sync)
{
THD*tmp_thd= final_queue;
while(tmp_thd->next_to_commit != NULL)
tmp_thd= tmp_thd->next_to_commit;
update_binlog_end_pos(tmp_thd->get_trans_pos());
}
接下來，我們來看一下這個函數update_binlog_end_pos。這個函數很簡單，傳入一個pos，然後將其賦值給全局變量binlog_end_pos，接下來就是最核心的一行代碼，signal_update()，發送binlog更新的信號。因此從主庫同步binlog到從庫的dump線程，會接收到這個binlog已有更新的信號，然後啟動dump binlog的流程。
函數update_binlog_end_pos的完整代碼如下：
void update_binlog_end_pos(my_off_tpos)
{
lock_binlog_end_pos();
if (pos >binlog_end_pos)
binlog_end_pos= pos;
signal_update();
unlock_binlog_end_pos();
}
Semi-sync
通過上麵的步驟介紹，我們可以看到在binlog文件的最新位置更新的時候，就已經通過signal_update函數發送信號給binlog的dump線程，該線程就可以將事務的binlog同步到從庫，從庫接收到日誌之後，就可以relay日誌，實現了主從同步。
因此，再次重複說明一下，按照上麵的解釋，在事務真正提交完成之前就開始發送了binlog已經更新的信號，dump線程收到信號，即可以進行binlog的同步。那Semisync的作用是什麼呢？
實際上，有沒有Semisync機製，對上麵介紹的MySQL的有關事務提交中關於binlog的流程都是一樣的。Semisync的作用，隻是主從之間的一個確認過程，主庫等待從庫返回相關位置的binlog已經同步到從庫的確認（而實際實現則是等待dump線程給用戶會話線程一個回複），沒有得到確認之前（或者等待時間達到timeout），事務提交則在該函數（步驟）上等待直至獲得返回。
具體執行binlog已經同步到某個位置的的確認函數為repl_semi_report_binlog_sync，函數如下：
intrepl_semi_report_binlog_sync(Binlog_storage_param *param,
constchar *log_file,
my_off_t log_pos)
{
if(rpl_semi_sync_master_wait_point == WAIT_AFTER_SYNC)
returnrepl_semisync.commitTrx(log_file, log_pos);
return 0;
}
通過觀察上述函數，我們可以看到有個rpl_semi_sync_master_wait_point變量與WAIT_AFTER_SYNC比較，如果不相等，則直接返回，直接返回則表示不需要在此時此刻確認binlog是否已經同步。而這個變量的取值來自於半同步參數semi_sync_master_wait_point的初始設置，我們可以設置為after_sync與after_commit。
這兩個參數含義的區別是：after_sync是在將binlog sync到disk之後（具體是否真正sync由參數sync_binlog的值決定）進行日誌同步確認，而after_commit是將事務完成在InnoDB裏麵提交之後再進行binlog的同步確認。兩者確認的時間點不同，after_sync要早於after_commit。
接下來，我們來看repl_semisync.commitTrx 這個函數，這個函數有兩個傳入參數，一個是binlog文件，一個binlog文件的位移。我們來看這個函數的含義吧。算了，還是直接用源碼的注釋來解釋吧。
上麵的注釋說得相當清楚，就是該commiTRX函數會等待binlog-dump返回已經同步到該位置的報告，如果還沒有同步到該位置，則繼續等待，直到超時返回。
當會話線程收到該函數的返回時，事務的提交過程繼續往下走，直至在InnoDB真正提交。
總結
通過上述對MySQL的事務提交過程中的前段分析，應該可以了解Semi-sync的同步機製與異步機製的區別。
Semi-sync的主從同步機製與異步機製在同步的處理方式上無任何區別，唯一的區別就是Semi-sync在事務提交中段（假如設置為after_sync）或者提交後的階段（after_commit）, 有一個驗證該事務涉及的binlog是否已經同步到從庫。而這個同步驗證，會拉長整個事務的提交時間，因為事務提交在數據庫中幾乎是串行（如果按Group Commit為一個單位，就算是完全地串行），這是影響MySQL吞吐量的關鍵點，當這個關鍵點被拉長，對全局的影響就被放大。雖然僅僅多了這麼一個確認的動作，但主庫處於Semi-sync的同步狀態與異步狀態的吞吐量相比，相差了好幾倍。
上述解釋就是其真正的原因。
大家都知道在MySQL中，在事務真正COMMIT之前，會將事務的binlog日誌寫入到binlog文件中。在MySQL的5.7版本中，提供了所謂的無損複製功能，該功能的作用就是在主庫的事務對其他的會話線程可見之前，就將該事務的日誌同步到從庫，保證了事務可以安全地無丟失地複製到從庫。
下麵我們從源碼來分析MySQL的事務提交以及事務在何時將binlog複製到從庫的。
MYSQL_BIN_LOG::ordered_commit，這個是事務在binlog階段提交的核心函數，通過該函數，實現了事務日誌寫入binlog文件，以及觸發dump線程將binlog發送到Slave，在最後的步驟，將事務設置為提交狀態。
我們來分析MYSQL_BIN_LOG::ordered_commit這個函數的核心過程，該函數位於binlog.cc文件中。
源碼分析
MYSQL_BIN_LOG::ordered_commit，這個函數，核心步驟如下：
第一步驟：flush
Stage#1: flushing transactions to binary log:
步驟1 ：將事務的日誌寫入binlog文件的buffer中，函數如下：
process_flush_stage_queue(&total_bytes,&do_rotate, &wait_queue);
從5.6開始，MySQL引入了Group Commit的概念，這樣可以避免每個事務提交都會鎖定一次binlog。
另外，還有一個用處，就是MySQL5.7的基於logical_clock的並行複製。在一個組裏麵（其實是一個隊列），這一組隊列的頭事務是相同的，因此這一組事務的last_committed（上一組的最後一個提交的事務）的事務也是同一個。我們都知道，last_committed相同的事務，是可以在從庫並行relay（重演）的。
該函數process_flush_stage_queue的作用，就是將commit隊列中的線程一個一個地取出，然後執行子函數 flush_thread_caches(head)；循環的代碼如下：將各自線程中的binlog cache寫入到binlog中。
/* Flush thread caches to binary log. */
for (THD *head= first_seen ; head ; head = head->next_to_commit)
{
std::pairresult= flush_thread_caches(head);,my_off_t>
total_bytes+= result.second;
if(flush_error == 1)
flush_error= result.first;
#ifndef DBUG_OFF
no_flushes++;
#endif
}
第二步驟：SYNC to disk
Stage#2: Syncing binary log file to disk
第二步：將binlog file中cache的部分寫入disk.但這個步驟參數sync_binlog起決定性的作用。
我們來看看源碼，除了這些還有哪些細節步驟，聽完源碼分析之後，你應該有新的收獲與理解。在執行真正的將binlog寫到磁盤之前，會進行一個等待，函數如下：
stage_manager.wait_count_or_timeout(opt_binlog_group_commit_sync_no_delay_count,
opt_binlog_group_commit_sync_delay,
Stage_manager::SYNC_STAGE);
等待的時間由MySQL參數文件中的binlog_group_commit_sync_delay，binlog_group_commit_sync_no_delay_count 這兩參數共同決定。第一個表示該事務組提交之前總共等待累積到多少個事務，第二個參數則表示該事務組總共等待多長時間後進行提交，任何一個條件滿足則進行後續操作。
因為有這個等待，可以讓更多事務的binlog通過一次寫binlog文件磁盤來完成提交，從而獲得更高的吞吐量。
接下來，就是執行sync_binlog_file，該函數會用到MySQL參數文件中sync_binlog參數的值，如果為0，則不進行寫磁盤操作，由操作係統決定什麼時候刷盤，如果為1，則強製進行寫磁盤操作。
再接下來，執行update_binlog_end_pos函數，用來更新binlog文件的最後的位置binlog_end_pos，該binlog_end_pos是一個全局的變量。在執行更新該位置之前，先得找到最後一個提交事務的線程（因為是Group Commit，多個事務排隊提交的機製）。因為已經將要提交事務的線程組成了一個鏈表，所以通過從頭到尾找，可以找到最後一個線程。代碼如下：
if(update_binlog_end_pos_after_sync)
{
THD*tmp_thd= final_queue;
while(tmp_thd->next_to_commit != NULL)
tmp_thd= tmp_thd->next_to_commit;
update_binlog_end_pos(tmp_thd->get_trans_pos());
}
接下來，我們來看一下這個函數update_binlog_end_pos。這個函數很簡單，傳入一個pos，然後將其賦值給全局變量binlog_end_pos，接下來就是最核心的一行代碼，signal_update()，發送binlog更新的信號。因此從主庫同步binlog到從庫的dump線程，會接收到這個binlog已有更新的信號，然後啟動dump binlog的流程。
函數update_binlog_end_pos的完整代碼如下：
void update_binlog_end_pos(my_off_tpos)
{
lock_binlog_end_pos();
if (pos >binlog_end_pos)
binlog_end_pos= pos;
signal_update();
unlock_binlog_end_pos();
}
Semi-sync
通過上麵的步驟介紹，我們可以看到在binlog文件的最新位置更新的時候，就已經通過signal_update函數發送信號給binlog的dump線程，該線程就可以將事務的binlog同步到從庫，從庫接收到日誌之後，就可以relay日誌，實現了主從同步。
因此，再次重複說明一下，按照上麵的解釋，在事務真正提交完成之前就開始發送了binlog已經更新的信號，dump線程收到信號，即可以進行binlog的同步。那Semisync的作用是什麼呢？
實際上，有沒有Semisync機製，對上麵介紹的MySQL的有關事務提交中關於binlog的流程都是一樣的。Semisync的作用，隻是主從之間的一個確認過程，主庫等待從庫返回相關位置的binlog已經同步到從庫的確認（而實際實現則是等待dump線程給用戶會話線程一個回複），沒有得到確認之前（或者等待時間達到timeout），事務提交則在該函數（步驟）上等待直至獲得返回。
具體執行binlog已經同步到某個位置的的確認函數為repl_semi_report_binlog_sync，函數如下：
intrepl_semi_report_binlog_sync(Binlog_storage_param *param,
constchar *log_file,
my_off_t log_pos)
{
if(rpl_semi_sync_master_wait_point == WAIT_AFTER_SYNC)
returnrepl_semisync.commitTrx(log_file, log_pos);
return 0;
}
通過觀察上述函數，我們可以看到有個rpl_semi_sync_master_wait_point變量與WAIT_AFTER_SYNC比較，如果不相等，則直接返回，直接返回則表示不需要在此時此刻確認binlog是否已經同步。而這個變量的取值來自於半同步參數semi_sync_master_wait_point的初始設置，我們可以設置為after_sync與after_commit。
這兩個參數含義的區別是：after_sync是在將binlog sync到disk之後（具體是否真正sync由參數sync_binlog的值決定）進行日誌同步確認，而after_commit是將事務完成在InnoDB裏麵提交之後再進行binlog的同步確認。兩者確認的時間點不同，after_sync要早於after_commit。
接下來，我們來看repl_semisync.commitTrx 這個函數，這個函數有兩個傳入參數，一個是binlog文件，一個binlog文件的位移。我們來看這個函數的含義吧。算了，還是直接用源碼的注釋來解釋吧。
上麵的注釋說得相當清楚，就是該commiTRX函數會等待binlog-dump返回已經同步到該位置的報告，如果還沒有同步到該位置，則繼續等待，直到超時返回。
當會話線程收到該函數的返回時，事務的提交過程繼續往下走，直至在InnoDB真正提交。
總結
通過上述對MySQL的事務提交過程中的前段分析，應該可以了解Semi-sync的同步機製與異步機製的區別。
Semi-sync的主從同步機製與異步機製在同步的處理方式上無任何區別，唯一的區別就是Semi-sync在事務提交中段（假如設置為after_sync）或者提交後的階段（after_commit）, 有一個驗證該事務涉及的binlog是否已經同步到從庫。而這個同步驗證，會拉長整個事務的提交時間，因為事務提交在數據庫中幾乎是串行（如果按Group Commit為一個單位，就算是完全地串行），這是影響MySQL吞吐量的關鍵點，當這個關鍵點被拉長，對全局的影響就被放大。雖然僅僅多了這麼一個確認的動作，但主庫處於Semi-sync的同步狀態與異步狀態的吞吐量相比，相差了好幾倍。
上述解釋就是其真正的原因。
原文發布時間為：2017-04-16
本文來自雲棲社區合作夥伴DBAplus
最後更新：2017-05-16 12:01:22