首页 运维干货《MySQL运维内参》节选 | InnoDB日志管理机制(七)

《MySQL运维内参》节选 | InnoDB日志管理机制(七)

运维派隶属马哥教育旗下专业运维社区,是国内成立最早的IT运维技术社区,欢迎关注公众号:yunweipai
领取学习更多免费Linux云计算、Python、Docker、K8s教程关注公众号:马哥linux运维

引子:

书接上文,在之前六篇讲述了写日志,其实正常情况下,这都是无用功,因为根本用不到。上一节讲到了,在什么情况下会用到日志,以及在什么时候会用到,如何用到等等内容,我们这一节继续讲述,在扫描完成日志之后,如何做数据库恢复工作,里面有什么逻辑,有什么可以改进的地方等等,这都是我们读者要去深思的地方。

《MySQL运维内参》节选 | InnoDB日志管理机制(七)插图

(本书作者在“白家大院”齐聚首)

从这些代码段中可以看到,缓存到HASH表之后,应该是可以找合适的时机去APPLY了,那什么时候呢?我们可以返回去看看函数recv_scan_log_recs的最后,调用了函数recv_apply_hashed_log_recs,那这个就是我们要找的真正做APPLY的函数了。我们详细看一下它的实现。

继续:

从这些代码段中可以看到,缓存到HASH表之后,应该是可以找合适的时机去APPLY了,那什么时候呢?我们可以返回去看看函数recv_scan_log_recs的最后,调用了函数recv_apply_hashed_log_recs,那这个就是我们要找的真正做APPLY的函数了。我们详细看一下它的实现。

UNIV_INTERN void recv_apply_hashed_log_recs(

    ibool   allow_ibuf

)   

{

    /* local vaiables … */

loop:

    recv_sys->apply_log_recs = TRUE;

    recv_sys->apply_batch_on = TRUE;

    /* 遍历HASH表?是的,把HASH表中的每一个桶中的每一个页面,连续处理 */

    for (i = 0; i < hash_get_n_cells(recv_sys->addr_hash); i++) {

        /* 遍历HASH表一个桶中的多个地址 */

        for (recv_addr = static_cast<recv_addr_t*>(

                HASH_GET_FIRST(recv_sys->addr_hash, i));

             recv_addr != 0;

             recv_addr = static_cast<recv_addr_t*>(

                HASH_GET_NEXT(addr_hash, recv_addr))) {

            /* 针对每一个页面,做这个页面上所有的REDO操作 */

            ulint   space = recv_addr->space;

            ulint   zip_size = fil_space_get_zip_size(space);

            ulint   page_no = recv_addr->page_no;

            if (recv_addr->state == RECV_NOT_PROCESSED) {

                mutex_exit(&(recv_sys->mutex));

                if (buf_page_peek(space, page_no)) {

                    buf_block_t*    block;

                    mtr_start(&mtr);

                    block = buf_page_get(

                        space, zip_size, page_no,

                        RW_X_LATCH, &mtr);

                    buf_block_dbg_add_level(

                        block, SYNC_NO_ORDER_CHECK);

                    /* 恢复一个页面的数据,APPLY recv_addr中存储的所有REDO记录,

                    这里使用了一个MTR来恢复。需要注意的是,这个MTR只是用来

                    获取页面时,给这个页面加锁使用的,而不会涉及REDO操作,因为

                    REDO是不需要再写日志的,所以不用担心这个MTR涉及到的日志量

                    太大的问题 */

                    recv_recover_page(FALSE, block);

                    mtr_commit(&mtr);

                } else {

                    /* 这里的操作是,如果上面的buf_page_peek没有在Buffer Pool中

                    找到这个页面,那这里就从文件中将这个页面载入到Buffer Pool,

                    并且预读32个页面以提高性能。恢复方法与是一样的。*/

                    recv_read_in_area(space, zip_size, page_no);

                }

                mutex_enter(&(recv_sys->mutex));

            }

        }

    }

    /* Wait until all the pages have been processed */

    while (recv_sys->n_addrs != 0) {

        mutex_exit(&(recv_sys->mutex));

        os_thread_sleep(500000);

        mutex_enter(&(recv_sys->mutex));

    }

    /* Wait for any currently run batch to end. 

    如注释所述,如果上面的操作做完了,则需要保证这些日志APPLY之后

    要在ibdata及ibd(s)中落地,此时就会将Buffer Pool中全部的脏页刷一遍

    以保证已经处理的这些日志失效。可能有人会问,如果在恢复的过程中,假设

    就是这里吧,还没有做刷盘操作,数据库又挂了,那怎么办?

    其实没事儿,整个恢复过程,日志也没有写,只是扫描了一遍,并且有可能在

    Buffer Pool中已经写了很多页面,有可能这些页面已经因为LRU已经刷过

    了,但这些操作是可重入的,也就是说,数据库再起来,可以重新做一次REDO

    操作,直到做成功为止。*/

    success = buf_flush_list(ULINT_MAX, LSN_MAX, NULL);

    recv_sys->apply_log_recs = FALSE;

    recv_sys->apply_batch_on = FALSE;

    /* 将HASH表中缓存的所有内容清空 */

    recv_sys_empty_hash();

    mutex_exit(&(recv_sys->mutex));

}

到这里,我们应该已经清楚了REDO数据库恢复的整个过程,并且可以返回到函数recv_recovery_from_checkpoint_start_func中,看一下最后的说明,做完REOD之后,做一次检查点以说明这次数据库恢复已经完成。

但这里我又有话说了,各位同学有没有发现一个细节,那就是InnoDB在辛辛苦苦的将所有日志分析并且根据不同页面通过HASH表存储之后,我们特别要注意下面两点特征:

  1. 对于同一个页面的REDO记录,必然是存储在同一个HASH桶中的。
  2. 对于某一个页面的所有日志记录,是按照先后顺序来管理的。

这两个特征非常重要,因为我们知道,REDO日志的APPLY,与顺序有关系,LSN小的,必定要比LSN大的先做APPLY,不然有可能造成数据的覆盖。但这有一个前提就是同一个页面,不同页面之间是不存在这样的问题的。

那我们想想,是不是只需要保证,同一个页面的日志顺序执行其所有的日志记录即可,而不同页面就没必要守这个规则了,答案是肯定的。

那目前InnoDB难道不是这样做的么?上面代码中我们已经看到了,他是用了一个两层循环,扫描了整个HASH表,慢慢的一条条的做REDO恢复。基于上面的分析,其实可以大胆的想象的一下,REDO恢复可以实现并行恢复。按照桶的下标为键值分配线程,那这样同一个桶必然会分到同一个线程中去做,这样自然保证了同一个页面的执行顺序,而不同的桶之间的页面是没有关系的,自然就可以并行恢复了。

啊?可以这样?这个想法,可能会让那些把日志文件设置的很大,又经常出现机器宕机问题的同学(上面已经提到了他们)心潮澎湃,这样性能提升的不只一点点了。

还是那句话,这个是需要把日志文件设置很大,并且经常出现宕机时,优化效果才明显。有需求,就能解决,我们希望这个优化会出现在某个版本中,少一些浪费的时间。

到现在为止,REDO日志的恢复就做完了,到这个时候,才真正体现了这个“累赘”的价值,感谢有你!

上面所讲的,是使用REDO日志来恢复数据库的过程,在它做完之后,整个数据库就是完整的了,已经保证了所有的数据库表都没有丢数据的情况,所有的数据库页面也已经是完整的了。假设此时对数据库做DML操作,也已经是可以的了,但还有一个问题没有处理,那就是此时的数据库,存在脏数据。因为有些事务没有提交,但数据已经存在了(举一个例子,事务在做的过程中,日志已经写完并刷盘,就是没有提交,此时数据库挂了),那根据事务的ACID特性,这样的数据就不应该存在,此时InnoDB需要做的就是把这些事务回滚掉,这就用到了我们下面将要讲的“数据库回滚”。

数据库

(神形兼备啊,另外那种霸气也流露出来了)

数据库回滚

回滚段的管理,也是有一个入口位置用来存储回滚段的管理信息的,在InnoDB中,是用第6个页面(5号)来管理的,这个页面是专门用来存储事务相关的信息的,我们先看看其页面格式:

/** Transaction system header */

/*————————————————————- @{ */

#define TRX_SYS_TRX_ID_STORE    0   /*!< the maximum trx id or trx

                    number modulo

                    TRX_SYS_TRX_ID_UPDATE_MARGIN

                    written to a file page by any

                    transaction; the assignment of

                    transaction ids continues from

                    this number rounded up by

                    TRX_SYS_TRX_ID_UPDATE_MARGIN

                    plus

                    TRX_SYS_TRX_ID_UPDATE_MARGIN

                    when the database is

                    started */

#define TRX_SYS_FSEG_HEADER 8   /*!< segment header for the

                    tablespace segment the trx

                    system is created into */

#define TRX_SYS_RSEGS       (8 + FSEG_HEADER_SIZE)

                    /*!< the start of the array of

                    rollback segment specification

                    slots */

上面定义的是第6号页面中存储的信息及其对应的位置,每一项的详细意义如下:

  1. TRX_SYS_TRX_ID_STORE:用来存储事务号,在每次新启动一个事务时,都会去检查当前最大事务号是不是达到了TRX_SYS_TRX_ID_WRITE_MARGIN(256)的倍数,如果达到了,就会将最大的事务号写入到这个位置,在下次启动时,将这个值取出来,再加上一个步长(TRX_SYS_TRX_ID_WRITE_MARGIN),来保证事务号的唯一性,其实就是一个经典的取号器的实现原理。
  2. TRX_SYS_FSEG_HEADER:用来存储事务段信息。
  3. TRX_SYS_RSEGS:这是一个数组,InnoDB有128个回滚段,那这个数组的长度就是128,每一个元素占用8个字节,对应的一个回滚段存储的内容包括回滚段首页面的表空间ID号及页面号。

而针对每一个回滚段,即上面数组中的一个元素,也有其自己的存储格式,代码中的宏定义如下:

#define TRX_RSEG_MAX_SIZE   0   /* Maximum allowed size for rollback

                    segment in pages */

#define TRX_RSEG_HISTORY_SIZE   4   /* Number of file pages occupied

                    by the logs in the history list */

#define TRX_RSEG_HISTORY    8   /* The update undo logs for committed

                    transactions */

#define TRX_RSEG_FSEG_HEADER    (8 + FLST_BASE_NODE_SIZE)

                    /* Header for the file segment where

                    this page is placed */

#define TRX_RSEG_UNDO_SLOTS (8 + FLST_BASE_NODE_SIZE + FSEG_HEADER_SIZE)

                    /* Undo log segment slots */

上面这些信息的存储,是从页面偏移38的位置开始的,在这个位置之前,存储的是文件管理的信息(讲参考索引管理相关章节),从38开始,存储了上面5个信息,它们的意义分别如下:

  1. TRX_RSEG_MAX_SIZE:回滚段管理页面的总数量,即所有undo段页面之和,一般为ULINT_MAX,即无上限。
  2. TRX_RSEG_HISTORY_SIZE:这个表来表示当前InnoDB中,在History List中有多少页面,即需要做PURGE的回滚段页面个数。
  3. TRX_RSEG_HISTORY:这个用来存储History List的链表首地址,事务提交之后,其对应的回滚段如果还不能PURGE,那都会加入到这个链表中。
  4. TRX_RSEG_FSEG_HEADER:这个用来存储回滚段的Inode位置信息,通过这个地址,就可以找到这个段的详细信息。
  5. TRX_RSEG_UNDO_SLOTS:这个位置所存储的是一个数组,长度为1024,每一个元素是一个页面号,初始化为FIL_NULL,即空页面。

这5个信息,存储了一个回滚段的信息,最后一个位置的数组,就是用来真正存储回滚段的位置,我们后面会讲到这128*1024个槽是如何使用的。

根据上面的讲述,我们现在已经知道所有回滚段的存储架构了,如下图所示:

存储架构

现在就可以知道,InnoDB中支持的回滚段总共有128*1024=131072个,TRX_RSEG_UNDO_SLOTS数组的每个元素指向一个页面,这个页面对应一个段,页面号就是段首页的页面号。

在每一个事务开始的时候,都会分配一个rseg,就是从长度为128的数组中,根据最近使用的情况,找到一个临近位置的rseg,在这个事务的生命周期内,被分配的rseg就会被这个事务所使用。

在事务执行过程中,会产生两种回滚日志,一种是INSERT的UNDO记录,一种是UPDATE的UNDO记录,可能有人会问DELETE哪去了?其实是包含在UPDATE的回滚记录中的,因为InnoDB把UNDO分为两类,一类就是新增,也就是INSERT,一类就是修改,就是UPDATE,分类的依据就是事务提交后要不要做PURGE操作,因为INSERT是不需要PURGE的,只要事务提交了,那这个回滚记录就可以丢掉了,而对于更新和删除操作而言,如果事务提交了,还需要为MVCC服务,那就需要将这些日志放到History List中去,等待去做PURGE,以及MVCC的多版本查询等,所以分为两类。

所以,一个事务被分配了一个rseg之后,通常情况下,如果一个事务中既有插入,又有更新(或删除),那这个事务就会对应两个UNDO段,即在一个rseg的1024个槽中,要使用两个槽来存储这个事务的回滚段,一个是插入段,一个是更新段。

在事务要存储回滚记录的时候,事务就要从1024个槽中,根据相应的更新类型(插入或者更新)找到空闲的槽来作为自己的UNDO段。如果已经申请过相同类型的UNDO段,就直接使用,否则就需要新创建一个段,并将段首页号写入到这个rseg的长度为1024的数组的对应位置(空闲位置)中去,这样就将具体的回滚段与整个架构联系起来了。

如果在1024个槽中找不到空闲的位置,那这个事务就会被回滚掉,报出错误为:“Too many active concurrent transactions”,错误号为1637的异常。当然这种情况一般不会见到,如果能把这个用完,估计数据库已经根本动不了了。

上面讲述了整个回滚段存储架构及与事务的相关性,具体到一个事务所使用的某个回滚段的管理,就存储在了回滚段首页中,管理信息包括三部分,分别是Undo page header、Undo segment header及Undo log header。下面分别介绍:

Undo page header:

/** Transaction undo log page header offsets */

#define TRX_UNDO_PAGE_TYPE  0   /*!< TRX_UNDO_INSERT or

                    TRX_UNDO_UPDATE */

#define TRX_UNDO_PAGE_START 2   /*!< Byte offset where the undo log

                    records for the LATEST transaction

                    start on this page (remember that

                    in an update undo log, the first page

                    can contain several undo logs) */

#define TRX_UNDO_PAGE_FREE  4   /*!< On each page of the undo log this

                    field contains the byte offset of the

                    first free byte on the page */

#define TRX_UNDO_PAGE_NODE  6   /*!< The file list node in the chain

                    of undo log pages */

  1. TRX_UNDO_PAGE_TYPE:这个我们在上面已经解释过了,就包括两个值,分别是TRX_UNDO_INSERT和TRX_UNDO_UPDATE。
  2. TRX_UNDO_PAGE_START:用来表示当前页面中,从什么位置开始存储了UNDO日志。
  3. TRX_UNDO_PAGE_FREE:与上面的START相对,这个用来表示当前页面中,UNDO日志的结束位置,也表示从这个位置开始,可以继续追加UNDO日志,直到页面存储满为止。
  4. TRX_UNDO_PAGE_NODE:一个UNDO段中所有的页面,通过一个双向链表来管理,这个位置存储的就是双向链表的指针。

Undo segment header:

/** Undo log segment header */

#define TRX_UNDO_STATE      0   /*!< TRX_UNDO_ACTIVE, … */

#define TRX_UNDO_LAST_LOG   2   /*!< Offset of the last undo log header

                    on the segment header page, 0 if

                    none */

#define TRX_UNDO_FSEG_HEADER    4   /*!< Header for the file segment which

                    the undo log segment occupies */

#define TRX_UNDO_PAGE_LIST  (4 + FSEG_HEADER_SIZE)

                    /*!< Base node for the list of pages in

                    the undo log segment; defined only on

                    the undo log segment’s first page */

  1. TRX_UNDO_STATE:用来存储当前UNDO段的状态,状态包括TRX_UNDO_ACTIVE,TRX_UNDO_CACHED、TRX_UNDO_TO_FREE、TRX_UNDO_TO_PURGE、TRX_UNDO_PREPARED五种。
  2. TRX_UNDO_LAST_LOG:用来存储最后一个UNDO日志的偏移位置,用来在一个UNDO段中,找到最后一个UNDO日志。
  3. TRX_UNDO_FSEG_HEADER:这个位置,就是用来存储当前UNDO段的Inode信息的,通过这个信息可以知道本UNDO段的详细信息。
  4. TRX_UNDO_PAGE_LIST:段内所有的页面都是通过链表连接起来的,这个位置是链表的首地址,用来管理这个链表,上面已经介绍的TRX_UNDO_PAGE_NODE则是每个节点的双链指针。

Undo log header:

/** The undo log header. There can be several undo log headers on the first

page of an update undo log segment. */

#define TRX_UNDO_TRX_ID     0   /*!< Transaction id */

#define TRX_UNDO_TRX_NO     8   /*!< Transaction number of the

                    transaction; defined only if the log

                    is in a history list */

#define TRX_UNDO_DEL_MARKS  16  /*!< Defined only in an update undo

                    log: TRUE if the transaction may have

                    done delete markings of records, and

                    thus purge is necessary */

#define TRX_UNDO_LOG_START  18  /*!< Offset of the first undo log record

                    of this log on the header page; purge

                    may remove undo log record from the

                    log start, and therefore this is not

                    necessarily the same as this log

                    header end offset */

#define TRX_UNDO_XID_EXISTS 20  /*!< TRUE if undo log header includes

                    X/Open XA transaction identification

                    XID */

#define TRX_UNDO_DICT_TRANS 21  /*!< TRUE if the transaction is a table

                    create, index create, or drop

                    transaction: in recovery

                    the transaction cannot be rolled back

                    in the usual way: a ‘rollback’ rather

                    means dropping the created or dropped

                    table, if it still exists */

#define TRX_UNDO_TABLE_ID   22  /*!< Id of the table if the preceding

                    field is TRUE */

#define TRX_UNDO_NEXT_LOG   30  /*!< Offset of the next undo log header

                    on this page, 0 if none */

#define TRX_UNDO_PREV_LOG   32  /*!< Offset of the previous undo log

                    header on this page, 0 if none */

#define TRX_UNDO_HISTORY_NODE   34  /*!< If the log is put to the history

                    list, the file list node is here */

这是一个针对UNDO日志的头信息,一个事务写入一次UNDO日志就会创建一个UNDO日志单元,都会对应一个这样的UNDO日志头信息,用来管理这个日志信息的状态,存储一些相关的信息以备恢复时使用,多个UNDO日志之间,通过双向链表连接起来(通过我们即将介绍的TRX_UNDO_NEXT_LOG及TRX_UNDO_PREV_LOG来管理)。

  1. TRX_UNDO_TRX_ID:用来存储当前UNDO日志对应的事务的事务ID号。
  2. TRX_UNDO_TRX_NO:事务序列号,在恢复时使用,这个序列号就是我们前面讲的TRX_SYS_TRX_ID_STORE位置存储的ID值。这个与上面的ID的区别是,NO用来在回滚时保持顺序使用,而ID是在事务运行时使用的。
  3. TRX_UNDO_DEL_MARKS:用来表示当前UNDO日志中有没有通过打标志删除过记录的操作,并决定是不是要做PURGE操作。
  4. TRX_UNDO_LOG_START:用来存储当前页面中,第一个UNDO日志的开始位置。
  5. TRX_UNDO_XID_EXISTS:用来标志当前日志中有没有包含Xid事务。
  6. TRX_UNDO_DICT_TRANS:用来标志当前日志对应的事务是不是DDL的,用来在回滚时判断如何操作。
  7. TRX_UNDO_TABLE_ID:与上面一个相关,如果上面标志是真的,则这个标志的是DDL的表ID。
  8. TRX_UNDO_NEXT_LOG:用来链接当前UNDO段中所有的UNDO日志,这个是指向下一个UNDO日志。
  9. TRX_UNDO_PREV_LOG:与上一个对应,这个用来指向上一个UNDO日志,从而构成双向链表。
  10. TRX_UNDO_HISTORY_NODE:用来存储在History List中的双向链表指针。而这个链表的首地址,是在之前我们所介绍的TRX_RSEG_HISTORY位置,可以回到前面去查看相关信息。

到现在为止,关于具体一个UNDO段中每个页面及页面内容是如何管理的已经清楚了,当一个事务需要写入UNDO日志时,就可以直接从对应的UNDO段中找到一个页面及对应的追加日志的偏移位置,然后将对应的UNDO日志写入即可。

UNDO日志

(还是昨天那个球,线下讨论了关于会源码的作用,有很多人认为,一提到某人会源码,就觉得一般是用来装一下的,并且实际上没有几家公司强大到放心地让你写源码去,所以觉得这不是一个名副其实的技能。我认为实则不然,会源码,99%的机会不是用来写源码的,而是阅读其实际方法及原理,尽可能的做到知MySQL,或者在出现问题之后,是一个很好的用来解决问题的方法,要知道,我不只一次碰到手册上面所述内容是错误的,并且有很多问题网上也是没有的,那可想而知,如果你会阅读源码了,这样的问题可以立刻迎刃而解)

篇外续

日志这篇,以这样的角度及思维模式来讲述真的是没有见过的,并且到今天已经是连载第七篇,

可以很确定的告诉大家,还有几篇明天继续发。

就在今天,关于这篇内容,我们的韩朱忠老师也说话了:

日志

他也是我们本书的推荐序之一。在这里谢谢他。

文章来自微信公众号:DBAce

本文链接:https://www.yunweipai.com/15841.html

网友评论comments

发表回复

您的电子邮箱地址不会被公开。

暂无评论

Copyright © 2012-2022 YUNWEIPAI.COM - 运维派 京ICP备16064699号-6
扫二维码
扫二维码
返回顶部