概述

InnoDB作为事务性引擎，使用write-ahead logging(WAL)机制保证ACID中的Automicity和Durability，使用undo机制保证ACID中的Consistency和Isolation。

WAL和undo的机制

按照WAL和undo的机制，形成以下两个原则：

1、数据块的更改需要先记录redo日志。

2、数据块的更改需要先写入undo。

根据这两个原则，InnoDB更新数据的基本流程可以简单的总结为：

1. 记录需要更改undo record的redo log
2. 记录需要更改data record的redo log
3. 写入redo log
4. 写入undo record
5. 更新data record

InnoDB Recovery

如果MySQL实例异常crash，那么重启过程中首先会进行InnoDB recovery。 即：根据last checkpoint点，顺序读取后面的redo log，按照先前滚，再回滚的原则， 应用所有的redo log。

因为redo record中记录着数据块的地址(space_id+page_no)，所以recovery的过程首先会执行合并相同数据块的操作，以加快recovery的过程。

那么mysql数据库怎么根据space_id找到对应IDB数据文件？ 因为在恢复的过程中，InnoDB只load了redo文件和系统表空间文件，如何查找InnoDB的数据文件呢？

1. InnoDB的数据字典dict_table_t结构中也保存了对应关系，但数据字典受redo保护，recovery的过程中不可用。
2. 扫描datadir的所有数据文件，读取page中保存的space_id，建立space_id和数据文件的对应关系。 MySQL目前采用第二种方式，但带来了一个问题，当设置了innodb_file_per_table后，每一个表对应一个表空间，那么需要读取所有的目录下的所有Innodb数据文件，这样就会严重的影响了recovery的时间。

MySQL 5.7改进策略：

MySQL 5.7中，在redo log中增加了一种新的record类型，即MLOG_FILE_NAME，记录了自last checkpoint以来更改的数据文件的file name。 这样在应用的时候，直接根据文件名就可以找到数据文件。

Oracle的设计机制

Oracle数据库recovery的过程中，有没有这个问题呢？ 答案是没有。

看下Oracle的设计机制:

oracle同样在系统表空间中记录了数据字典，受redo保护，可以通过DBA_开头的表来查询。但Oracle还维护了一个control file，控制文件中记录了database name，redo file，datafile，backup等信息，通过v$开头的表查询。 当Oracle在recovery的过程中，需要数据库在mount状态下，即打开了控制文件，这时数据字典还不可用(DB没有open)，在应用redo log的时候，根据控制文件中的v$datafile，检索file_id和file_name的对应关系。 MySQL是根据datadir，innodb_data_home_dir，innodb_log_group_home_dir等几个目录配置，通过文件系统的查找，找到相应文件的，而Oracle维护了一个集中式的control file管理这些初始加载的文件地址。

后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下~