三大日志

redolo(重做日志)，属物理日志：记录事务的更新内容，在MySQL重启时恢复数据库。

MySQL实例挂了/服务器宕机，重启

基本数据更新+写redolog+刷盘过程

• 刷盘策略提供，innodb_flush_log_at_trx_commit参数，0，1，2
• 0，事务提交时不刷盘
• 1，事务提交时刷盘。从redo log buffer直接刷到redo文件
• 2，事务提交时，只把redo log buffer 内容写到 page cash 中

此外，默认刷盘，后台有一个线程，每1秒，把redo log buffer 内容写到 cash page中，刷一次

总体来看：刷盘策略+默认刷盘

• 0，可能会丢失一秒数据
• 1，
  • 只要事务提交成功，redolog必然完整，没有数据丢失
  • 如果事务期间MySQL挂了/服务器宕机，redolog日志会丢失，但是事务没提交，没数据损失
• 2，
  • 提交成功，写入page cash
  • 事务期间MySQL挂了无损失，服务器宕机损失1秒数据

日志文件组

硬盘上存储的 redo log 日志文件不只一个，而是以一个日志文件组的形式出现的，每个的redo日志文件大小都是一样的。

比如可以配置为一组4个文件，每个文件的大小是 1GB，整个 redo log 日志文件组可以记录4G的内容。

它采用的是环形数组形式，从头开始写，写到末尾又回到头循环写，如下图所示。

在个日志文件组中还有两个重要的属性，分别是 write pos、checkpoint

• write pos 是当前记录的位置，一边写一边后移
• checkpoint 是当前要擦除的位置，也是往后推移

每次刷盘 redo log 记录到日志文件组中，write pos 位置就会后移更新。

每次 MySQL 加载日志文件组恢复数据时，会清空加载过的 redo log 记录，并把 checkpoint 后移更新。

write pos 和 checkpoint 之间的还空着的部分可以用来写入新的 redo log 记录。

如果 write pos 追上 checkpoint ，表示日志文件组满了，这时候不能再写入新的 redo log 记录，MySQL 得停下来，清空一些记录，把 checkpoint 推进一下。

2

binlog(归档日志)，属逻辑日志：记录事务中的sql语句，保证MySQL集群的数据一致性

回滚日志undo log

实现回滚机制，实现MVCC机制

事务期间的修改，会先记录到undolog，然后再执行操作。

• 期间遇到异常，利用undolog 中的信息将数据回滚到修改之前。
• undolog先于数据持久化到磁盘上。 这样就保证了即使遇到数据库突然宕机等情况，当用户再次启动数据库的时候，数据库还能够通过查询回滚日志来回滚将之前未完成的事务。

另外，MVCC 的实现依赖于：隐藏字段、Read View、undo log。在内部实现中，InnoDB 通过数据行的 DB_TRX_ID 和 Read View 来判断数据的可见性，如不可见，则通过数据行的 DB_ROLL_PTR 找到 undo log 中的历史版本。每个事务读到的数据版本可能是不一样的，在同一个事务中，用户只能看到该事务创建 Read View 之前已经提交的修改和该事务本身做的修改

# 总结

MySQL InnoDB 引擎使用 redo log(重做日志) 保证事务的持久性，使用 undo log(回滚日志) 来保证事务的原子性。

MySQL数据库的数据备份、主备、主主、主从都离不开binlog，需要依靠binlog来同步数据，保证数据一致性。