MySQL中的两阶段提交详解(2PC)

引言

在InnoDB存储引擎中，当启用二进制日志（Binlog）且执行事务提交时，会触发两阶段提交（2PC）过程，以确保数据的一致性和持久化安全。

该过程首先将数据更新写入redo log buffer和Binlog缓存，然后通过分阶段的日志写入和持久化操作，实现事务的准备与提交状态转变。

两阶段提交机制不仅协调了InnoDB的事务日志与Binlog之间的同步，还依赖于关键配置参数如sync_binlog和innodb_flush_log_at_trx_commit，这些参数分别控制Binlog和redo log的写入与持久化策略。

本文将围绕两阶段提交的具体流程及相关配置，深入分析其在保证事务原子性和持久性中的核心作用。

两阶段提交过程

当在 InnoDB 中执行事务，并且启用了 Binlog 时，提交事务时会触发两阶段提交过程。

• 当有数据需要更新的时候，InnoDB 引擎就会先把记录写到redo log buffer以及binlog cache（线程独有的），并更新内存（change buffer），这个时候更新就算完成了。
• 如果是唯一索引更新操作会写入到redo log buffer，普通索引的更新操作会先写入到change buffer，在合适的时机merge到redo log。
• 事务提交时写入 redo log 并变成 prepare 状态。（一阶段）
• 再把 binlog cache 写到 binlog 文件中，最后 redo log 变成 commit 状态。（二阶段）

sync_binlog配置

sync_binlog 用于控制commit时binlog的持久化，write表示将binlog cache中的日志，写入到文件系统的 page cache，fsync将表示数据持久化到磁盘。

• sync_binlog=0 的时候，表示每次提交事务都只 write，不 fsync。（5.7及以前默认值）
• sync_binlog=1 的时候，表示每次提交事务都会执行 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。

总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。

最新评论