mysqlupdate会自动加锁吗_MySQL意外宕机不难解决，数据会丢么？但你真的懂数据恢复吗？...

来源&＃xff1a;sq.163yun.com/blog/article/172546631668785152

InnoDB如果发生意外宕机了&＃xff0c;数据会丢么&＃xff1f;

对于这个问题&＃xff0c;稍微了解一点MySQL知识的人&＃xff0c;都会斩钉截铁的回答&＃xff1a;不会&＃xff01;

为什么&＃xff1f;

他们也会毫不犹豫地说&＃xff1a;因为有重做日志(redo log)&＃xff0c;数据可以通过redo log进行恢复。

回答得很好&＃xff0c;那么InnoDB怎样通过redo log进行数据恢复的&＃xff0c;具体的流程是怎样的&＃xff1f;

估计能说清楚这个问题的人所剩不多了&＃xff0c;更深入一点&＃xff1a;除了redo log&＃xff0c;InnoDB在恢复过程中&＃xff0c;还需要其他信息么&＃xff1f;比如是否需要binlog参与&＃xff1f;undo日志在恢复过程中又会起到什么作用&＃xff1f;

到这里&＃xff0c;可能很多人会变得疑惑起来&＃xff1a;数据恢复跟undo有半毛钱的关系&＃xff1f;

其实&＃xff0c;InnoDB的数据恢复是一个很复杂的过程&＃xff0c;这个恢复过程需要redo log、binlog、undo log等参与。这里把InnoDB的恢复过程主要划分为两个阶段:

第一阶段主要依赖于redo log的恢复&＃xff1b;

而第二阶段&＃xff0c;恰恰需要binlog和undo log的共同参与。

接下来&＃xff0c;我们来具体了解下整个恢复的过程&＃xff1a;

一、依赖redo log进行恢复

第一阶段&＃xff0c;数据库启动后&＃xff0c;InnoDB会通过redo log找到最近一次checkpoint的位置&＃xff0c;然后根据checkpoint相对应的LSN开始&＃xff0c;获取需要重做的日志&＃xff0c;接着解析获取的日志并且保存到一个哈希表中&＃xff0c;最后通过遍历哈希表中的redo log信息&＃xff0c;读取相关页进行恢复。

InnoDB的checkpoint信息保存在日志文件中&＃xff0c;即ib_logfile0的开始2048个字节中&＃xff0c;checkpoint有两个&＃xff0c;交替更新&＃xff0c;checkpoint与日志文件的关系如下图&＃xff1a;

(checkpoint位置)

checkpoint信息分别保存在ib_logfile0的512字节和1536字节处&＃xff0c;每个checkpoint默认大小为512字节&＃xff0c;InnoDB的checkpoint主要由3部分信息组成&＃xff1a;

checkpoint no&＃xff1a;主要保存的是checkpoint号&＃xff0c;因为InnoDB有两个checkpoint&＃xff0c;通过checkpoint号来判断哪个checkpoint更新。

checkpoint lsn&＃xff1a;主要记录了产生该checkpoint是flush的LSN&＃xff0c;确保在该LSN前面的数据页都已经落盘&＃xff0c;不再需要通过redo log进行恢复。

checkpoint offset&＃xff1a;主要记录了该checkpoint产生时&＃xff0c;redo log在ib_logfile中的偏移量&＃xff0c;通过该offset位置就可以找到需要恢复的redo log开始位置。

通过以上checkpoint的信息&＃xff0c;我们可以简单得到需要恢复的redo log的位置&＃xff0c;然后通过顺序扫描该redo log来读取数据&＃xff0c;比如我们通过checkpoint定位到开始恢复的redo log位置在ib_logfile1中的某个位置&＃xff0c;那么整个redo log扫描的过程可能是这样的&＃xff1a;

(redo log扫描过程)

Step 1&＃xff1a;从ib_logfile1的指定位置开始读取redo log&＃xff0c;每次读取4 * page_size的大小&＃xff0c;这里我们默认页面大小为16K&＃xff0c;所以每次读取64K的redo log到缓存中&＃xff0c;redo log每条记录(block)的大小为512字节。

Step 2&＃xff1a;读取到缓存中的redo log通过解析、验证等一系列过程后&＃xff0c;把redo log的内容部分保存到用于恢复的缓存recv_sys->buf&＃xff0c;保存到恢复缓存中的每条信息主要包含两部分&＃xff1a;(space&＃xff0c;offset)组成的位置信息和具体redo log的内容&＃xff0c;我们称之为body。

Step 3&＃xff1a;同时保存在恢复缓存中的redo信息会根据(space&＃xff0c;offset)计算一个哈希值后保存到一个哈希表(recv_sys->addr_hash)中&＃xff0c;相同哈希值、不同(space&＃xff0c;offset)用链表存储&＃xff0c;相同的(space&＃xff0c;offset)用列表保存&＃xff0c;可能部分事务比较大&＃xff0c;redo信息一个block不能保存&＃xff0c;所以&＃xff0c;每个body中可以用链表链接多body的值。

redo log被保存到哈希表中之后&＃xff0c;InnoDB就可以开始进行数据恢复&＃xff0c;只需要轮询哈希表中的每个节点获取redo信息&＃xff0c;根据(space&＃xff0c;offset)读取指定页面后进行日志覆盖。

在上面整个过程中&＃xff0c;InnoDB为了保证恢复的速度&＃xff0c;做了几点优化&＃xff1a;

在根据(space&＃xff0c;offset)读取数据页信息到buffer pool的时候&＃xff0c;InnoDB不是只读取一张页面&＃xff0c;而是读取相邻的32张页面到buffer pool。这里有个假设&＃xff0c;InnoDB认为&＃xff0c;如果一张页面被修改了&＃xff0c;那么其周围的一些页面很有可能也被修改了&＃xff0c;所以一次性连续读入32张页面可以避免后续再重新读取。

在MySQL5.7版本以前&＃xff0c;InnoDB恢复时需要依赖数据字典&＃xff0c;因为InnoDB根本不知道某个具体的space对应的ibd文件是哪个&＃xff0c;这些信息都是数据字典维护的。而且在恢复前&＃xff0c;需要把所有的表空间全部打开&＃xff0c;如果库中有数以万计的表&＃xff0c;把所有表打开一遍&＃xff0c;整个过程就会很慢。那么MySQL5.7在这上面做了哪些改进呢&＃xff1f;

其实很简单&＃xff0c;针对上面的问题&＃xff0c;InnoDB在redo log中增加了两种redo log的类型来解决。

MLOG_FILE_NAME

用于记录在checkpoint之后&＃xff0c;所有被修改过的信息(space&＃xff0c;filepath)&＃xff1b;

MLOG_CHECKPOINT

则用于标志MLOG_FILE_NAME的结束。

上面两种redo log类型的添加&＃xff0c;完美解决了前面遗留的问题&＃xff0c;redo log中保存了后续需要恢复的space和filepath对。所以&＃xff0c;在恢复的时候&＃xff0c;只需要从checkpoint的位置一直往后扫描到MLOG_CHECKPOINT的位置&＃xff0c;这样就能获取到需要恢复的space和filepath。在恢复过程中&＃xff0c;只需要打开这些ibd文件即可。当然由于space和filepath的对应关系通过redo存了下来&＃xff0c;恢复的时候也不再依赖数据字典。

这里需要强调的是MLOG_CHECKPOINT在每个checkpoint点中最多存在一次&＃xff0c;如果出现多次MLOG_CHECKPOINT类型的日志&＃xff0c;则说明redo已经损坏&＃xff0c;InnoDB会报错。

最多存在一次&＃xff0c;那么会不会有不存在的情况&＃xff1f;

答案是肯定的&＃xff0c;在每次checkpoint过后&＃xff0c;如果没有发生数据更新&＃xff0c;那么MLOG_CHECKPOINT就不会被记录。所以只要查找下redo log最新一个checkpoint后的MLOG_CHECKPOINT是否存在&＃xff0c;就能判定上次MySQL是否正常关机。

5.7版本的MySQL在InnoDB进行恢复的时候&＃xff0c;也正是这样做的&＃xff0c;MySQL5.7在进行恢复的时候&＃xff0c;一般情况下需要进行最多3次的redo log扫描&＃xff1a;

1、首先对redo log的扫描&＃xff0c;主要是为了查找MLOG_CHECKPOINT&＃xff0c;这里并不进行redo log的解析。如果你没有找到MLOG_CHECKPOINT&＃xff0c;则说明InnoDB不需要进行recovery&＃xff0c;后面的两次扫描可以省略&＃xff1b;如果找到了MLOG_CHECKPOINT&＃xff0c;则获取MLOG_FILE_NAME到指定列表&＃xff0c;后续只需打开该链表中的表空间即可。

2、下一步的扫描是在第一次找到MLOG_CHECKPOINT基础之上进行的&＃xff0c;该次扫描会把redo log解析到哈希表中&＃xff0c;如果扫描完整个文件&＃xff0c;哈希表还没有被填满&＃xff0c;则不需要第三次扫描&＃xff0c;直接进行recovery就结束。

3、最后是在第二次基础上进行的&＃xff0c;第二次扫描把哈希表填满后&＃xff0c;还有redo log剩余&＃xff0c;则需要循环进行扫描&＃xff0c;哈希表满后立即进行recovery&＃xff0c;直到所有的redo log被apply完为止。

redo log全部被解析并且apply完成&＃xff0c;整个InnoDB recovery的第一阶段也就结束了&＃xff0c;在该阶段中&＃xff0c;所有已经被记录到redo log但是没有完成数据刷盘的记录都被重新落盘。

然而&＃xff0c;InnoDB单靠redo log的恢复是不够的&＃xff0c;这样还是有可能会丢失数据(或者说造成主从数据不一致)。

因为在事务提交过程中&＃xff0c;写binlog和写redo log提交是两个过程&＃xff0c;写binlog在前而redo提交在后&＃xff0c;如果MySQL写完binlog后&＃xff0c;在redo提交之前发生了宕机&＃xff0c;这样就会出现问题&＃xff1a;binlog中已经包含了该条记录&＃xff0c;而redo没有持久化。binlog已经落盘就意味着slave上可以apply该条数据&＃xff0c;redo没有持久化则代表了master上该条数据并没有落盘&＃xff0c;也不能通过redo进行恢复。

这样就造成了主从数据的不一致&＃xff0c;换句话说主上丢失了部分数据&＃xff0c;那么MySQL又是如何保证在这样的情况下&＃xff0c;数据还是一致的&＃xff1f;这就需要进行第二阶段恢复。

二、binlog和undo log共同参与

前面提到&＃xff0c;在第二阶段恢复中&＃xff0c;需要用到binlog和undo log&＃xff0c;下面我们就来看下具体的恢复逻辑是怎样的&＃xff1f;

其实该阶段的恢复中&＃xff0c;也被划分成两部分&＃xff1a;第一部分&＃xff0c;根据binlog获取所有可能没有提交事务的xid列表&＃xff1b;第二部分&＃xff0c;根据undo中的信息构造所有未提交事务链表&＃xff0c;最后通过上面两部分协调判断事务是否可以提交。

(根据binlog获取xid列表)

如上图所示&＃xff0c;MySQL在第二阶段恢复的时候&＃xff0c;先会去读取最后一个binlog文件的所有event信息&＃xff0c;然后把xid保存到一个列表中&＃xff0c;然后进行第二部分的恢复&＃xff0c;如下&＃xff1a;

(基于undo构造事务链表)

我们知道&＃xff0c;InnoDB当前版本有128个回滚段&＃xff0c;每个回滚段中保存了undo log的位置指针&＃xff0c;通过扫描undo日志&＃xff0c;我们可以构造出还未被提交的事务链表(存在于insert_undo_list和update_undo_lsit中的事务都是未被提交的)&＃xff0c;所以通过起始页(0&＃xff0c;5)下的solt信息可以定位到回滚段&＃xff0c;然后根据回滚段下的undo的slot定位到undo页&＃xff0c;把所有的undo信息构建一个undo_list&＃xff0c;然后通过undo_list再创建未提交事务链表trx_sys->trx_list。

基于上面两步&＃xff0c; 我们已经构建了xid列表和未提交事务列表&＃xff0c;那么在这些未提交事务列表中的事务&＃xff0c;哪些需要被提交&＃xff1f;哪些又该回滚&＃xff1f;

判断条件很简单&＃xff1a;凡是xid在通过binlog构建的xid列表中存在的事务&＃xff0c;都需要被提交。换句话说&＃xff0c;所有已经记录binlog的事务&＃xff0c;需要被提交&＃xff0c;而剩下那些没有记录binlog的事务&＃xff0c;则需要被回滚。

三、回顾优化

通过上述两个阶段的数据恢复&＃xff0c;InnoDB才最终完成整个recovery过程&＃xff0c;回过头来我们再想想&＃xff0c;在上述两个阶段中&＃xff0c;是否还有优化空间&＃xff1f;比如第一阶段&＃xff0c;在构造完哈希表后&＃xff0c;事务的恢复是否可以并发进行&＃xff1f;理论上每个hash node是根据(space&＃xff0c;offset)生成的&＃xff0c;不同的hash node之间不存在冲突&＃xff0c;可以并行进行恢复。

或者在根据哈希表进行数据页读取时&＃xff0c;每次读取连续32张页面&＃xff0c;这里读取的32张页面&＃xff0c;可能有部分是不需要的&＃xff0c;也同时被读入到Buffer Pool中了&＃xff0c;是否可以在构建一颗红黑树&＃xff0c;根据(space&＃xff0c;offset)组合键进行插入&＃xff0c;这样如果需要恢复的时候&＃xff0c;可以根据红黑树的排序原理&＃xff0c;把所有页面的读取顺序化&＃xff0c;并不需要读取额外的页面。

更多技术干货

MySQL每秒57万的写入&＃xff0c;带你飞 作为面试官&＃xff0c;我是如何甄别应聘者的包装程度 实现故障恢复自动化&＃xff1a;详解Redis哨兵技术 值得收藏&＃xff1a;一份非常完整的MySQL规范 Redis查漏补缺&＃xff1a;最易错过的技术要点大扫盲 Java性能优化的45个细节(珍藏版)

▼ 点击4000G 架构师视频