引言

在InnoDB存儲引擎中，當啟用二進制日志（Binlog）且執(zhí)行事務提交時，會觸發(fā)兩階段提交（2PC）過程，以確保數(shù)據(jù)的一致性和持久化安全。

該過程首先將數(shù)據(jù)更新寫入redo log buffer和Binlog緩存，然后通過分階段的日志寫入和持久化操作，實現(xiàn)事務的準備與提交狀態(tài)轉變。

兩階段提交機制不僅協(xié)調了InnoDB的事務日志與Binlog之間的同步，還依賴于關鍵配置參數(shù)如sync_binlog和innodb_flush_log_at_trx_commit，這些參數(shù)分別控制Binlog和redo log的寫入與持久化策略。

本文將圍繞兩階段提交的具體流程及相關配置，深入分析其在保證事務原子性和持久性中的核心作用。

兩階段提交過程

當在 InnoDB 中執(zhí)行事務，并且啟用了 Binlog 時，提交事務時會觸發(fā)兩階段提交過程。

• 當有數(shù)據(jù)需要更新的時候，InnoDB 引擎就會先把記錄寫到redo log buffer以及binlog cache（線程獨有的），并更新內存（change buffer），這個時候更新就算完成了。
• 如果是唯一索引更新操作會寫入到redo log buffer，普通索引的更新操作會先寫入到change buffer，在合適的時機merge到redo log。
• 事務提交時寫入 redo log 并變成 prepare 狀態(tài)。（一階段）
• 再把 binlog cache 寫到 binlog 文件中，最后 redo log 變成 commit 狀態(tài)。（二階段）

sync_binlog配置

sync_binlog 用于控制commit時binlog的持久化，write表示將binlog cache中的日志，寫入到文件系統(tǒng)的 page cache，fsync將表示數(shù)據(jù)持久化到磁盤。

• sync_binlog=0 的時候，表示每次提交事務都只 write，不 fsync。（5.7及以前默認值）
• sync_binlog=1 的時候，表示每次提交事務都會執(zhí)行 fsync。（8.0及以后默認值）
• sync_binlog=N（N>1）的時候，表示每次提交事務都 write，但累積 N 個事務后才 fsync。

innodb_flush_log_at_trx_commit配置

innodb_flush_log_at_trx_commit 用于控制commit時redo log的持久化。

• innodb_flush_log_at_trx_commit=0 的時候，表示每次事務提交時都只是把 redo log 留在 redo log buffer 中。
• innodb_flush_log_at_trx_commit =1 的時候，表示每次事務提交時都將 redo log 直接持久化到磁盤。（默認值）
• innodb_flush_log_at_trx_commit=2 的時候，表示每次事務提交時都只是把 redo log 寫到 page cache。

總結

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論