2PC在MySQL数据库中的应用及rodolog和binlog日志

2PC可以保证数据库中redo log和binlog两个日志的一致性，要么都成功，要么都失败。

介绍MySQL两阶段提交之前，先介绍一下Redo Log和Binlog

redo log:

在MySQL中如果每次更新都需要写进磁盘，然后磁盘也要找到那条记录，然后在更新，整个过程IO成本、查找成本都很高，因此引入了 redo log。这里用到了MySQL中的WAL技术，Write-AheadLogging，它的关键点是先写日志，再写磁盘。

具体来说就是，当需要更新一条数据时，InnoDB引擎会先把记录写进redo log中，并更新内存，这个时候就算完成。同时InnoDB会在空闲的时候将这个记录写进磁盘。

redo log是固定大小，从头开始写入，写到尾部就又回到开头循环写。指针writepos记录当前位置，checkpoint是要擦除的位置，当两者之间有空余位置，即可继续更新，当满了后，就需要checkpoint擦除数据后继续更新。

有了redolog，InnoDB就可以保证数据库即使发生异常重启，之前提交的记录也不会丢失。

binlog:

MvSQL有两块组成:server层，主要负责MySQL能层面的事情:引擎层，负责存储相关的事情，redo log就是InnoDB特有的日志。而 server层也有自己的日志，就是binlog。

redolog和binlog的区别:

（1）redolog是InnoDB特有的，binlog是MySQL的server层实现的，所有引擎都有
（2）redolog是物理日志，记录的是“在某个数据页上做了什么操作”;binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给ID=2这一行的c字段加1"。
（3）redo log是循环写的，空间固定会用完:binlog是可以追加写入的，“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
在更新一条数据时，会先执行，然后写入redo log中，redo log进入prepare状态，执行器执行完成。然后执行器生成这个操作的binlog，并写入磁盘。然后提交commit，更新完成。

两阶段提交在MySQL数据库中的应用:

redo log和binlog是两个独立的逻辑，如果不用两阶段提交，那么就会先写redolog，后写binlog，或者反过来的顺序写。看看会有什么问题。把数据0更新到1。

（1）先写redolog，后写binlog:假设redolog在写完后，系统崩溃了，binlog还未完成，因为redo log写完了，数据依然可以恢复到之前的状态。但是当我们需要使用binlog来恢复临时库时，binlog中并没有这条记录，那么恢复后的值就会和之前的不同，本应该是1，但是结果是0。

（2）先写binlog，后写redo log:同样的假设，binlog写完，系统崩溃，redolog未完成。这个时候系统崩溃，由于没有完成redolog，那么就不能恢复到执行结果后的数据，依然是没有执行这条语句前的数，但是binloa已经写入，那么同样使用binlog恢复临时表时，数据就会与之前的不同。本应该是0，但是结果是1。

因此两阶段提交保证了两个日志的一致性，要么都成功，要么都失败。可以对照zookeeper的2PC理解。

(34条消息) Zookeeper 2PC and 3PC_Java运动猿的博客-CSDN博客https://blog.csdn.net/m0_51697147/article/details/127481809