MySQL redo log、undo log、binlog

MySQL是一个广泛使用的关系型数据库管理系统，它通过一系列的日志来保证数据的一致性和持久性。在MySQL中，有三个重要的日志组件，它们分别是redo log（重做日志）、undo log（回滚日志）和binlog（二进制日志）。在下面的博客内容中，我将介绍这三个组件的实现原理。

MySQL Redo Log（重做日志）

重做日志（redo log）是MySQL的一种事务日志，它用于恢复已经提交的事务对数据库所做的修改。它的实现原理如下：

持久性：重做日志是以一种顺序追加的方式写入到磁盘上的一个特殊文件中，这种方式可以提高写入性能。重做日志的写入是通过写入日志缓冲区（log buffer）来完成的，当事务提交时，相关的重做日志记录会被刷新到磁盘上的重做日志文件。
循环写入：重做日志采用循环写入的方式，即当写满了日志文件后，会回到文件开头继续写入，这样可以循环利用已经写满的空间。重做日志会定期进行检查点（checkpoint），将已经提交的事务的日志记录持久化到磁盘上，并释放相应的空间。
崩溃恢复：当数据库发生崩溃或意外断电等情况时，MySQL可以利用重做日志进行崩溃恢复。在数据库重新启动时，通过重做日志中记录的操作，可以将未持久化到磁盘上的事务修改重新应用到数据库中，从而恢复数据库到崩溃之前的状态。

MySQL Undo Log（回滚日志）

回滚日志（undo log）是MySQL的另一种事务日志，它用于实现事务的原子性和一致性。它的实现原理如下：

事务回滚：当一个事务需要回滚时，MySQL可以利用回滚日志来撤销该事务对数据库所做的修改。回滚日志中记录了每个事务所做的修改操作的逆操作，通过撤销这些逆操作，可以将数据库恢复到事务开始之前的状态。
MVCC支持：回滚日志还用于支持MySQL的多版本并发控制（MVCC）机制。在MVCC中，每个事务在开始时都会创建一个对应的回滚日志，用于存储该事务所做的修改。其他事务在读取数据时，会根据回滚日志中的信息来判断是否可以看到该数据的修改。
垃圾回收：回滚日志中的记录并不是永久存储的，一旦事务提交或回滚完成，相应的回滚日志记录就可以被清除。MySQL会定期进行垃圾回收操作，将已经不再需要的回滚日志记录删除，以释放空间。

MySQL Binlog（二进制日志）

二进制日志（binlog）是MySQL用于记录数据库的所有修改操作的日志。它的实现原理如下：

格式与记录：二进制日志以一种特定的格式记录了数据库的修改操作，包括对表的插入、更新和删除等操作。每个记录都包含了操作类型、影响的表和修改的数据等信息。
复制与恢复：二进制日志可以用于数据库的备份和恢复。通过将二进制日志应用到一个空的MySQL实例中，可以将该实例恢复到与原始实例相同的状态。二进制日志还可以用于数据库的复制，即将一个MySQL实例的修改操作同步到其他实例上。
断点续传：二进制日志支持断点续传的功能。当数据库出现异常崩溃或意外断电时，可以通过二进制日志将数据库恢复到崩溃之前的状态，并继续之后的操作，从而实现断点续传的效果。

总结起来，MySQL的redo log、undo log和binlog是三个重要的日志组件，它们分别用于数据库的恢复、回滚和备份等功能。它们的实现原理有所不同，但都起着保证数据一致性和持久性的重要作用。

实现日志后的更新流程

在这里插入图片描述

数据写过程：上图
可能存在数据丢失：看binlog和redolog日志的写入机制
如何保证一定不丢失：使用
WAL机制

基于2PC的一致性保障

保证binlog和redolog的一致性

假设Redo Log刷入成功了，但是还没来得及刷入Binlog MySQL就挂了。此时重启之后会发现Redo Log并没有Commit标识，此时根据记录的XA事务找到这个事务，进行回滚。
如果Redo Log刷入成功，而且Binlog也刷入成功了，但是还没有来得及将Redo Log从Prepare改成Commit MySQL就挂了，此时重启会发现虽然Redo Log没有Commit标识，但是通过XID查询到的Binlog却已经成功刷入磁盘了。
此时，虽然Redo Log没有Commit标识，MySQL也要提交这个事务。因为Binlog一旦写入，就可能会被从库或者任何消费Binlog的消费者给消费。如果此时MySQL不提交事务，则可能造成数据不一致。而且目前Redo Log和Binlog从数据层面上，其实已经Ready了，只是差个标志位。

在这里插入图片描述
Prepare阶段，将Redo Log写入文件，并刷入磁盘，记录上内部XA事务的ID，同时将Redo Log状态设置为Prepare。Redo Log写入成功后，再将Binlog同样刷入磁盘，记录XA事务ID。