MySQL系列:innodb源码分析之redo log恢复
在上一篇《innodb源码分析之重做日志结构》中我们知道redo log的基本结构和日志写入步骤,那么redo log是怎么进行数据恢复的呢?在什么时候进行redo log的日志推演呢?redo log的推演只有在数据库异常或者关闭后,数据库重新启动时会进行日志推演,将数据库状态恢复到关闭前的状态。那么这个过程是怎么进行的呢?以下我们逐步来解析。
1.recv_sys_t结构
struct recv_sys_struct { mutex_t mutex; /*保护锁*/ ibool apply_log_recs; /*正在应用log record到page中*/ ibool apply_batch_on; /*批量应用log record标志*/ dulint lsn; ulint last_log_buf_size; byte* last_block; /*恢复时最后的块内存缓冲区*/ byte* last_block_buf_start; /*最后块内存缓冲区的起始位置,因为last_block是512地址对齐的,需要这个变量记录free的地址位置*/ byte* buf; /*从日志块中读取的重做日志信息数据*/ ulint len; /*buf有效的日志数据长度*/ dulint parse_start_lsn; /*开始parse的lsn*/ dulint scanned_lsn; /*已经扫描过的lsn序号*/ ulint scanned_checkpoint_no; /*恢复日志的checkpoint 序号*/ ulint recovered_offset; /*恢复位置的偏移量*/ dulint recovered_lsn; /*恢复的lsn位置*/ dulint limit_lsn; /*日志恢复最大的lsn,暂时在日志重做的过程没有使用*/ ibool found_corrupt_log; /*是否开启日志恢复诊断*/ log_group_t* archive_group; mem_heap_t* heap; /*recv sys的内存分配堆,用来管理恢复过程的内存占用*/ hash_table_t* addr_hash; /*recv_addr的hash表,以space id和page no为KEY*/ ulint n_addrs; /*addr_hash中包含recv_addr的个数*/ };在这个结构中,比较复杂的是addr_hash这个哈希表,这个哈希表是用sapce_id和page_no作为hash key,里面存储有恢复时对应的记录内容。恢复日志在从日志文件中读出后,进行解析成若干个recv_t并存储在哈希表当中。在一个读取解析周期过后,日志恢复会对hash表中的recv_t中的数据写入到ibuf和page中。这里为什么要使用hash表呢?个人觉得是为了同一个page的数据批量进行恢复的缘故,这样可以page减少随机插入和修改。 以下是和这个过程相关的几个数据结构:
/*对应页的数据恢复操作集合*/ struct recv_addr_struct { ulint state; /*状态,RECV_NOT_PROCESSED、RECV_BEING_PROCESSED、RECV_PROCESSED*/ ulint space; /*space的ID*/ ulint page_no; /*页序号*/ UT_LIST_BASE_NODE_T(recv_t) rec_list; hash_node_t addr_hash; }; /*当前的记录操作*/ struct recv_struct { byte type; /*log类型*/ ulint len; /*当前记录数据长度*/ recv_data_t* data; /*当前的记录数据list*/ dulint start_lsn; /*mtr起始lsn*/ dulint end_lsn; /*mtr结尾lns*/ UT_LIST_NODE_T(recv_t) rec_list; }; /*具体的数据体*/ struct recv_data_struct { recv_data_t* next; /*下一个recv_data_t,next的地址后面接了一大块内存,用于存储rec body*/ };他们的内存关系结构图如下:
2.重做日志推演过程的LSN关系
parse_start_lsn = scanned_lsn = recovered_lsn = 检查点的lsn。
在日志完成恢复时:
parse_start_lsn = 检查点的lsn
scanned_lsn = recovered_lsn = log_sys->lsn。
3.日志恢复的主要接口和流程
recv_recovery_from_checkpoint_finish 结束从重做日志组内的checkpoint的数据恢复操作
recv_recovery_from_archive_start 从归档日志文件中进行数据恢复
recv_recovery_from_archive_finish 结束从归档日志中的数据恢复操作
recv_reset_logs 截取重做日志最后一段作为新的重做日志的起始位置,可能会丢失数据。
2.然后调用recv_recovery_from_checkpoint_start,并将最大的LSN作为参数传入函数当中。
3.函数会先最近建立checkpoint的日志组,并读取出对应的checkpoint信息
4.通过checkpoint lsn和传入的最大LSN进行比较,如果相等,不进行日志恢复数据,如果不相等,进行日志恢复。
5.在启动恢复之前,先会同步各个日志组的archive归档状态
6.在开始恢复时,先会从日志文件中读取2M的日志数据到log_sys->buf,然后对这2M的数据进行scan,校验其合法性,而后将去掉block header的日志放入recv_sys->buf当中,这个过程称为scan,会改变scanned lsn.
7.在对2M的日志数据scan后,innodb会对日志进行mtr操作解析,并执行相关的mtr函数。如果mtr合法,会将对应的记录数据按space page_no作为KEY存入recv_sys->addr_hash当中。
8.当对scan的日志数据进行mtr解析后,innodb对会调用recv_apply_hashed_log_recs对整个recv_sys->addr_hash进行扫描,并按照日志相对应的操作进行对应page的数据恢复。这个过程会改变recovered_lsn。
9.如果完成第8步后,会再次从日志组文件中读取2M数据,跳到步骤6继续相对应的处理,直到日志文件没有需要恢复的日志数据。
10.innodb在恢复完成日志文件中的数据后,会调用recv_recovery_from_checkpoint_finish结束日志恢复操作,主要是释放一些开辟的内存。并进行事务和binlog的处理。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。