《MySQL5.7性能與數據安全大幅提升的緣由》要點：
本文介紹了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.另外,還有一個用處,就是mysql的5.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::pair<int,my_off_t>result= flush_thread_caches(head);

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的完整代碼如下.

?semisync

通過上面的步驟介紹,我們看到,在binlog文件的最新位置更新的時候,就已經通過signal_update函數發送信號給binlog的dump線程,該線程就可以將事務的binlog同步到從庫,從庫接收到日志之后,就可以relay日志,實現了主從同步.因此,再次重復說明一下,按照上面的解釋,在事務真正提交完成之前就開始發送了binlog已經更新的信號,dump線程收到信號,即可以進行binlog的同步.而semisync的作用是什么呢?

實際上,有沒有semisync機制,上面介紹的mysql的有關事務提交中關于binlog的流程都是一樣的,semisync的作用,只是主從之間的一個確認過程,主庫等待從庫返回相關位置的binlog已經同步到從庫的確認,(而實際實現則是等待dump線程給用戶會話線程一個回復),沒有得到確認之前(或者等待時間達到timeout),事務提交則在該函數(步驟)上等待直至獲得返回.具體執行binlog已經同步到某個位置的的確認函數為repl_semi_report_binlog_sync,函數如下：

int?repl_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)

return?repl_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數據庫大會實錄-MySQL核心參數含義的源碼解析

配置mysql的group replication過程以及遇到的錯誤

mysql的緩存池中的LRU列表實現機制源碼解析

(續)為什么當磁盤IO成瓶頸之后數據庫的性能急劇下降—性能更悲劇篇

為什么當磁盤IO成瓶頸之后數據庫的性能急劇下降

文章來自微信公眾號：數據庫隨筆

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