MYSQL之 GroupCommit
組提交(group commit)是MYSQL處理日誌的一種最佳化方式,主要為了解決寫日誌時頻繁刷磁碟的問題。組提交伴隨著MYSQL的發展不斷最佳化,從最初只支援redo log 組提交,到目前5.6官方版本同時支援redo log 和binlog組提交。組提交的實現大大提高了mysql的事務處理效能,下文將以innodb 儲存引擎為例,詳細介紹組提交在各個階段的實現原理。
redo log的組提交
WAL(Write-Ahead-Logging)是實現事務永續性的一個常用技術,基本原理是在提交事務時,為了避免磁碟頁面的隨機寫,只需要保證事務的redo log寫入磁碟即可,這樣可以透過redo log的順序寫代替頁面的隨機寫,並且可以保證事務的永續性,提高了資料庫系統的效能。雖然WAL使用順序寫替代了隨機寫,但是,每次事務提交,仍然需要有一次日誌刷盤動作,受限於磁碟IO,這個操作仍然是事務併發的瓶頸。
組提交思想是,將多個事務redo log的刷盤動作合併,減少磁碟順序寫。Innodb的日誌系統裡面,每條redo log都有一個LSN(Log Sequence Number),LSN是單調遞增的。每個事務執行更新操作都會包含一條或多條redo log,各個事務將日誌複製到log_sys_buffer時(log_sys_buffer 透過log_mutex
保護),都會獲取當前最大的LSN,因此可以保證不同事務的LSN不會重複。那麼假設三個事務Trx1,Trx2和Trx3的日誌的最大LSN分別為LSN1,LSN2,LSN3(LSN1<LSN2<LSN3),它們同時進行提交,那麼如果Trx3日誌先獲取到log_mutex進行落盤,它就可以順便把[LSN1---LSN3]這段日誌也刷了,這樣Trx1和Trx2就不用再次請求磁碟IO。組提交的基本流程如下:
-
獲取 log_mutex
-
若flushed_to_disk_lsn>=lsn,表示日誌已經被刷盤,跳轉5
-
若 current_flush_lsn>=lsn,表示日誌正在刷盤中,跳轉5後進入等待狀態
-
將小於LSN的日誌刷盤(flush and sync)
-
退出log_mutex
備註:lsn表示事務的lsn,flushed_to_disk_lsn和current_flush_lsn分別表示已刷盤的LSN和正在刷盤的LSN。
redo log 組提交最佳化
我們知道,在開啟binlog的情況下,prepare階段,會對redo log進行一次刷盤操作(innodb_flush_log_at_trx_commit=1),確保對data頁和undo 頁的更新已經重新整理到磁碟;commit階段,會進行刷binlog操作(sync_binlog=1),並且會對事務的undo log從prepare狀態設定為提交狀態(可清理狀態)。透過兩階段提交方式(innodb_support_xa=1),可以保證事務的binlog和redo log順序一致。二階段提交過程中,mysql_binlog作為協調者,各個儲存引擎和mysql_binlog作為參與者。故障恢復時,掃描最後一個binlog檔案(在flush階段,判斷binlog是否超過閥值,進行rotate binlog檔案,rotate的binlog檔案中對應的事務一定是已經提交的,處於prepared的事務的binlog還沒有刷進來,因為還沒進入ordered_commit函式),提取其中的xid;重做檢查點以後的redo日誌,讀取事務的undo段資訊,蒐集處於prepare階段的事務連結串列,將事務的xid與binlog中的xid對比,若存在,則提交,否則就回滾。
透過上述的描述可知,每個事務提交時,都會觸發一次redo flush動作,由於磁碟讀寫比較慢,因此很影響系統的吞吐量。淘寶童鞋做了一個最佳化,將prepare階段的刷redo動作移到了commit(flush-sync-commit)的flush階段之前,保證刷binlog之前,一定會刷redo。這樣就不會違背原有的故障恢復邏輯。移到commit階段的好處是,可以不用每個事務都刷盤,而是leader執行緒幫助刷一批redo。如何實現,很簡單,因為log_sys->lsn始終保持了當前最大的lsn,只要我們刷redo刷到當前的log_sys->lsn,就一定能保證,將要刷binlog的事務redo日誌一定已經落盤。透過延遲寫redo方式,實現了redo log組提交的目的,而且減少了log_sys->mutex的競爭。目前這種策略已經被官方mysql5.7.6引入。
兩階段提交
在單機情況下,redo log組提交很好地解決了日誌落盤問題,那麼開啟binlog後,binlog能否和redo log一樣也開啟組提交?首先開啟binlog後,我們要解決的一個問題是,如何保證binlog和redo log的一致性。因為binlog是Master-Slave的橋樑,如果順序不一致,意味著Master-Slave可能不一致。MYSQL透過兩階段提交很好地解決了這一問題。Prepare階段,innodb刷redo log,並將回滾段設定為Prepared狀態,binlog不作任何操作;commit階段,innodb釋放鎖,釋放回滾段,設定提交狀態,binlog刷binlog日誌。出現異常,需要故障恢復時,若發現事務處於Prepare階段,並且binlog存在則提交,否則回滾。透過兩階段提交,保證了redo log和binlog在任何情況下的一致性。
binlog的組提交
回到上節的問題,開啟binlog後,如何在保證redo log-binlog一致的基礎上,實現組提交。因為這個問題,5.6以前,mysql在開啟binlog的情況下,無法實現組提交,透過一個臭名昭著的prepare_commit_mutex,將redo log和binlog刷盤序列化,序列化的目的也僅僅是為了保證redo log-Binlog一致,但這種實現方式犧牲了效能。這個情況顯然是不能容忍的,因此各個mysql分支,mariadb,facebook,perconal等相繼出了補丁改進這一問題,mysql官方版本5.6也終於解決了這一問題。由於各個分支版本解決方法類似,我主要透過分析5.6的實現來說明實現方法。
binlog組提交的基本思想是,引入佇列機制保證innodb commit順序與binlog落盤順序一致,並將事務分組,組內的binlog刷盤動作交給一個事務進行,實現組提交目的。binlog提交將提交分為了3個階段,FLUSH階段,SYNC階段和COMMIT階段。每個階段都有一個佇列,每個佇列有一個mutex保護,約定進入佇列第一個執行緒為leader,其他執行緒為follower,所有事情交由leader去做,leader做完所有動作後,通知follower刷盤結束。binlog組提交基本流程如下:
FLUSH 階段
1) 持有Lock_log mutex [leader持有,follower等待]
2) 獲取佇列中的一組binlog(佇列中的所有事務)
3) 將binlog buffer到I/O cache
4) 通知dump執行緒dump binlog
SYNC階段
1) 釋放Lock_log mutex,持有Lock_sync mutex[leader持有,follower等待]
2) 將一組binlog 落盤(sync動作,最耗時,假設sync_binlog為1)
COMMIT階段
1) 釋放Lock_sync mutex,持有Lock_commit mutex[leader持有,follower等待]
2) 遍歷佇列中的事務,逐一進行innodb commit
3) 釋放Lock_commit mutex
4) 喚醒佇列中等待的執行緒
說明:由於有多個佇列,每個佇列各自有mutex保護,佇列之間是順序的,約定進入佇列的一個執行緒為leader,因此FLUSH階段的leader可能是SYNC階段的follower,但是follower永遠是follower。
透過上文分析,我們知道MYSQL目前的組提交方式解決了一致性和效能的問題。透過二階段提交解決一致性,透過redo log和binlog的組提交解決磁碟IO的效能。下面我整理了Prepare階段和Commit階段的框架圖供各位參考。
參考文件
http://mysqlmusings.blogspot.com/2012/06/binary-log-group-commit-in-mysql-56.html
http://blog.chinaunix.net/uid-26896862-id-3432594.html
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31383567/viewspace-2219170/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MySQL/InnoDB和GroupCommit(2)MySqlMIT
- MySQL(六):MySQL之MVCCMySqlMVC
- 重返MySQL之MySQL基礎MySql
- mysql之MHAMySql
- MySQL之索引MySql索引
- mysql之\cMySql
- MySQL之vacharMySql
- MySQL之order byMySql
- MySQL 之 ORDER BY FIELDMySql
- MySQL 之 USINGMySql
- mysql之 redo logMySql
- MySQL 之變數MySql變數
- MySQL之swap配置MySql
- MySQL之in與existsMySql
- MySQL之timestampMySql
- javaertogo之mysql操作JavaGoMySql
- MySQL預設資料庫之mysql庫MySql資料庫
- MySQL基礎之MySQL 5.7 新增配置MySql
- MySQL錯誤之mysql.slave_master_infoMySqlAST
- 【MySQL】MySQL 5.6 引數之 extra_portMySql
- 【Mysql】mysql公開課之-mysql5.7複製特性MySql
- MySQL Study之–Mysql啟動失敗“mysql.host”薦MySql
- 18 . Go之操作MysqlGoMySql
- MySQL之MGR白名單MySql
- MySQL8.0之XtraBackupMySql
- MySQL 之 show processlist 神器MySql
- MySQL之表聯結MySql
- mysql索引之字首索引MySql索引
- MySQL之臨時表MySql
- Mysql之案例分析(一)MySql
- 精通MySQL之鎖篇MySql
- MySQL學習之索引MySql索引
- MySql之EXPLAN詳解MySql
- TarsCpp 元件之 MySQL 操作元件MySql
- mysql安全之loginpathMySql
- Mysql之新增innodb支援MySql
- mysql replication之GTIDMySql
- mysql之select into outfileMySql