redo log 如何确保事务持久性的

1. 预写日志（Write-Ahead Logging, WAL）：

   • redo log采用WAL策略，即在事务提交前，先将修改操作记录到redo log中，然后再修改缓冲区中的数据。这样，即使在事务提交后系统崩溃，也可以通过redo log来恢复数据。

2. 顺序写入：

   • redo log的写入是顺序的，这意味着它是顺序IO，而不是随机IO。顺序IO的性能远高于随机IO，因此可以快速地将日志记录到磁盘上。

3. 事务提交时的刷盘：

   • 当事务提交时，redo log buffer中的数据会被刷到磁盘上的redo log文件中。这一过程称为fsync操作，只有当redo log记录成功持久化后，事务才会被认为是提交成功的。

4. 后台线程的刷盘：

   • 即使事务没有提交，InnoDB也有一个后台线程，大约每1秒会将redo log buffer中的数据刷到磁盘上。这样，即使在事务提交前系统崩溃，也有可能已经将部分redo log数据持久化到磁盘上。

5. redo log的循环使用：

   • redo log文件是循环使用的，当一个日志文件写满后，会切换到下一个日志文件继续写入。旧的日志在新的日志被写满并确认不再需要时会被覆盖。这一过程通过checkpoint机制来管理，确保在覆盖旧日志前，旧日志所对应的修改已经被刷新到数据文件中。

6. 崩溃恢复：

   • 如果MySQL发生崩溃，在重启时，InnoDB存储引擎会通过redo log来恢复未提交的事务。它会读取redo log中的记录，并将这些记录重新应用到数据文件上，确保数据库的完整性和一致性。