MySQL日志文件系统

redo log

redo log是实现在数据引擎层的，记录的是物理日志，属于物理变更，记录了关于每一个数据页是如何发生改变的。

作用：确保事务的持久性。防止在DB发生故障时，由于脏页未及时写入磁盘导致数据的丢失；在MySQL重启后能够根据redo log进行重做，从而达到事务的持久化。

存储方式：每个InnoDB至少有个redo log文件组，每个文件组下面至少有2个redo log文件，文件组下面的多个是循环写的。相关的参数如下：

1. innodb_log_file_size:每个redo log的大小；
2. innodb_log_files_in_group:每个redo log文件组中文件的数量；

写入时间：redo log并不是在事务提交之后才写入的，而是在事务开始的时候就已经开始写入redo log，随着事务的执行，不断的写入redo log。

释放时间：当脏页被刷入磁盘之后，redo log中相对应占用的空间就可以释放掉了。

具体过程：
InnoDB中存在有缓存池（buffer pool，简称bp），bp中是以页为单位进行管理的，每个页默认的大小是16KB，对DB的任何操作首先会作用于bp中。当修改一个数据库中的记录时，InnoDB会从磁盘中读取对应的页到缓冲池中，然后直接更改缓冲页，并将页标记为脏页（即缓冲页的数据与磁盘的数已经不一致，相反，一直的叫干净页），放置到Flush list，等待Master Thread或后台其他线程刷新到磁盘中。这样的好处是可以避免每次对磁盘进行随机IO，提高数据库的性能，将对页的更改merge到一次IO操作。
此时就会有个问题，当脏页还没来得及刷新到磁盘的时候，DB挂了，此时脏页的数据就丢失了。为了避免这个问题，InnoDB将所有对页面的修改先写入到一个专门的文件，并在数据库重启的时候，从该文件中读取数据进行恢复操作，就可以恢复到DB挂之前的状态，这个文件就是redo log。这也叫做WAL技术（write ahead log策略），先写redo log，在写页，如果DB挂了，通过重组日志完成数据的恢复。

当然，直接写磁盘的redo log的性能也挺低效的，因此，Innodb会先写入redo log buffer中，然后再根据一定的策略写入到磁盘中，这个buffer默认的大小是8MB。刷新的策略：

1. Master Thread每一秒写入磁盘redo log；
2. 每个事务提交时写入磁盘redo log；
3. 当buffer空间小于1/2时，写入redo log；

bin log

bin log，即二进制日志，记录的是逻辑日志，是实现在Server层，因此支持InnoDB、MYISAM等存储引擎，它记录的是数据库执行更改的操作，并以二进制的形式保存在磁盘中。

作用：它可以用来作数据库增量备份、恢复、MySQL主从复制等。
写入时间：事务提交的时候会写入，因此对于开启binlog的数据库来说，大事务的提交会显得比较慢。

binlog的3种格式：

1. 基于SQL语句的复制（statement-based replication, SBR）
2. 基于行的模式，记录行的更改情况。（row-based replication, RBR）
3. 混合模式复制，以上2者的结合。（mixed-based replication, MBR）

crash-safe

通过2PC提交解决redo log和bin log的问题

所谓的crash-safe，是能够在DB挂了以后保证以下点：

1. 所有已提交的事务能够自动恢复；
2. 所有未提交的事务能够自动回滚；

没有打开bin log

InnoDB通过redo log和undo log来保证以上两点。
为了保证提交事务的crash-safe，InnoDB需要在事务提交的时候，redo log写入磁盘，当然这回损失掉一部分性能。
在DB重启之后，所有已提交的事务通过redo log进行恢复，所有已经prepare的但未commit的事务会应用undo log进行rollback。此时连接DB时就能看到已经提交的数据存在数据库内，未提交被回滚地数据需要重新执行。

打开了bin log

如果DB只有redo log的话，那么在DB挂了以后，可以直接通过redo log来恢复未保存的脏页。但如果redo log和bin log都存在的时候，情况就不一样了，因为2部分都是独立处理的逻辑。下面来说可能出现的情况。

1. 先写redo log，再写bin log。DB在写完redo log，还没写完bin log，DB挂了。前面说过，即使DB挂了，redo log也可以把数据恢复回来。但是由于bin log还没写完，DB就挂了，那么bin log就会少了一部分数据，那么当DB重启之后，用bin log去同步从库，由于主库通过redo log恢复了数据，这时候主从就会出现不一致。
2. 先写bin log，再写redo log。DB在写完bin log，还没写完redo log，DB挂了。DB重启之后，redo log没法把数据恢复回来，但bin log中已经有了这部分数据，那么从库就会多了部分数据，这时候主从也会出现不一致。

InnoDB为了解决这个，使用2PC方法来保证不会出现不一致。

update T set c+=1 where id =1

2PC中，一个事务的提交经过以下几个步骤：

1. prepare阶段：事务成功执行，生成xid信息（XA事务），并写入redo log和undo log，同时更改页数据生成脏页，将事务状态设置为TRX_PREPARED，并将redo log写入磁盘；
2. commit阶段：写入bin log，写入bin log的同时会将上面的xid信息(xid_event_log)记录下来，由于bin log只有在事务确认提交的时候才会写入，因此如果写入了bin log，表示事务确实是要提交的，回滚的事务是不会写入。
3. 调用引擎的commit操作完成事务的提交，会清除undo log，刷新redo log，并将事务状态设为TRX_NOT_STARTED状态。

为了保证数据的安全性，以上3步都需要调用fsync将数据刷写到磁盘中。

如果DB挂了，DB会在重启的时候进行崩溃恢复操作，存储引擎中处于prepare状态的事务会去查询该事物是否在bin log已经提交，如果存在，则在存储引擎内提交该事务，否则回滚该事务。比如，DB在第1步和第2步之间挂了，此时处于prepare的事务还没来得及提交到bin log，因此该事务在DB重启之后会被回滚；当奔溃发生在第2步和第3步之间，此时该事务在DB重启之后会提交，此时存储引擎和bin log都存在这个事务了。

Reference

1. 02 | 日志系统：一条SQL更新语句是如何执行的？
2. # 说说MySQL中的Redo log Undo log都在干啥
   
3. # MySQL 中Redo与Binlog顺序一致性问题