两阶段提交进阶

上一节我们讲了，两阶段提交逻辑上的表现，其实较为肤浅，并且偏向理论，可能大家都能看懂，但是如果放入实际的mysql应用中并联系事务和日志进行分析，又会怎么样呢？

这次就专门分析两阶段提交在mysql更新操作中的必要性；（定语加的有够多的🏋️‍♂️）；

既然在mysql中，那必然是要知道mysql的更新操作是如何进行的，才能分析两阶段提交为何必要；

对于一个单体数据库中，一个简单的mysql操作通常会分为：

1.解析sql语句并进行优化；

2.开始事务

3.加锁，对更新涉及到的数据加锁

4.执行更新操作并将操作记录到日志中，以支持回滚和恢复

5.提交事务，释放锁，返回结果；

可以看到在这过程中对于更新数据以及日志的操作都是在事务范围内进行的；

接下来分析日志在这个过程中的变化：

二进制日志（Binary Log）的记录：MySQL会将执行的更新操作记录到二进制日志中，这包括对数据的插入、更新和删除操作。二进制日志记录在事务提交之前。Binlog通常用于数据的备份和复制，以及在主从复制架构中用于数据同步。
Redo日志的生成：MySQL会生成Redo日志，记录已经提交的事务对数据的修改。Redo日志用于数据库的崩溃恢复，在数据库重启时，MySQL会根据Redo日志将已提交的事务重新应用到数据库中，确保数据的一致性。称为重做日志
Undo日志的生成：在事务进行过程中，MySQL会生成Undo日志，记录事务对数据的修改前的状态（记录了事务对数据库所做的修改的逆操作）。Undo日志用于事务的回滚操作，在事务回滚时，MySQL会根据Undo日志将数据恢复到事务开始之前的状态。称为撤销日志

我们接着分析，如果使用两阶段提交协议那么对于一个分布式的数据库进行更新操作时，应该按照怎么样的顺序执行呢

在准备阶段

如果没有两阶段提交，一旦在提交阶段发生了故障，可能会导致一些参与者节点已经准备好提交事务，而另一些参与者节点却无法准备就绪。这种情况下，数据可能会处于不一致的状态，从而破坏了数据的一致性和可靠性。

crash阶段（出现错误）：

（在这个过程中，其实redo和undo作用和单体数据库作用是一样的，都是维持单体数据库的持久性和一致性）；

如果没有两阶段提交，一旦在提交阶段发生了故障，可能会导致数据的更新操作部分应用到了数据库中，而另一部分未能成功应用。这种情况下，数据库可能会处于不一致的状态，从而破坏了数据的一致性和可靠性。

成功的话：第二阶段

commit阶段

如果没有两阶段提交，可能会导致已经提交的事务对数据的修改丢失，或者未提交的事务对数据的修改被错误地应用到了数据库中。这种情况下，数据库可能会处于不一致的状态。

其实两阶段提交还有一个重要作用，防止半提交发生时造成的redo日志和binlog日志不统一

例：

整个过程：

从图中可看出，事务的提交过程有两个阶段，就是将 redo log 的写入拆成了两个步骤：prepare 和 commit，中间再穿插写入binlog，具体如下：

prepare 阶段：将 XID（内部 XA 事务的 ID）写入到 redo log，同时将 redo log 对应的事务状态设置为 prepare，然后将 redo log 持久化到磁盘（innodb_flush_log_at_trx_commit = 1 的作用）；
commit 阶段：把 XID 写入到 binlog，然后将 binlog 持久化到磁盘（sync_binlog = 1 的作用），接着调用引擎的提交事务接口，将 redo log 状态设置为 commit，此时该状态并不需要持久化到磁盘，只需要 write 到文件系统的 page cache 中就够了，因为只要 binlog 写磁盘成功，就算 redo log 的状态还是 prepare 也没有关系，一样会被认为事务已经执行成功；

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：/a/552403.html

如若内容造成侵权/违法违规/事实不符，请联系我们进行投诉反馈qq邮箱809451989@qq.com，一经查实，立即删除！