欢迎您光临本站,如有问题请及时联系我们。

《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表存储之后,我们特别要注意下面两点特征:

  对于同一个页面的REDO记录,必然是存储在同一个HASH桶中的。

  对于某一个页面的所有日志记录,是按照先后顺序来管理的。

  这两个特征非常重要,因为我们知道,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号页面中存储的信息及其对应的位置,每一项的详细意义如下:

  TRX_SYS_TRX_ID_STORE:用来存储事务号,在每次新启动一个事务时,都会去检查当前最大事务号是不是达到了TRX_SYS_TRX_ID_WRITE_MARGIN(256)的倍数,如果达到了,就会将最大的事务号写入到这个位置,在下次启动时,将这个值取出来,再加上一个步长(TRX_SYS_TRX_ID_WRITE_MARGIN),来保证事务号的唯一性,其实就是一个经典的取号器的实现原理。

  TRX_SYS_FSEG_HEADER:用来存储事务段信息。

  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个信息,它们的意义分别如下:

  TRX_RSEG_MAX_SIZE:回滚段管理页面的总数量,即所有undo段页面之和,一般为ULINT_MAX,即无上限。

  TRX_RSEG_HISTORY_SIZE:这个表来表示当前InnoDB中,在History List中有多少页面,即需要做PURGE的回滚段页面个数。

  TRX_RSEG_HISTORY:这个用来存储History List的链表首地址,事务提交之后,其对应的回滚段如果还不能PURGE,那都会加入到这个链表中。

  TRX_RSEG_FSEG_HEADER:这个用来存储回滚段的Inode位置信息,通过这个地址,就可以找到这个段的详细信息。

  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 */

  TRX_UNDO_PAGE_TYPE:这个我们在上面已经解释过了,就包括两个值,分别是TRX_UNDO_INSERT和TRX_UNDO_UPDATE。

  TRX_UNDO_PAGE_START:用来表示当前页面中,从什么位置开始存储了UNDO日志。

  TRX_UNDO_PAGE_FREE:与上面的START相对,这个用来表示当前页面中,UNDO日志的结束位置,也表示从这个位置开始,可以继续追加UNDO日志,直到页面存储满为止。

  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 */

  TRX_UNDO_STATE:用来存储当前UNDO段的状态,状态包括TRX_UNDO_ACTIVE,TRX_UNDO_CACHED、TRX_UNDO_TO_FREE、TRX_UNDO_TO_PURGE、TRX_UNDO_PREPARED五种。

  TRX_UNDO_LAST_LOG:用来存储最后一个UNDO日志的偏移位置,用来在一个UNDO段中,找到最后一个UNDO日志。

  TRX_UNDO_FSEG_HEADER:这个位置,就是用来存储当前UNDO段的Inode信息的,通过这个信息可以知道本UNDO段的详细信息。

  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来管理)。

  TRX_UNDO_TRX_ID:用来存储当前UNDO日志对应的事务的事务ID号。

  TRX_UNDO_TRX_NO:事务序列号,在恢复时使用,这个序列号就是我们前面讲的TRX_SYS_TRX_ID_STORE位置存储的ID值。这个与上面的ID的区别是,NO用来在回滚时保持顺序使用,而ID是在事务运行时使用的。

  TRX_UNDO_DEL_MARKS:用来表示当前UNDO日志中有没有通过打标志删除过记录的操作,并决定是不是要做PURGE操作。

  TRX_UNDO_LOG_START:用来存储当前页面中,第一个UNDO日志的开始位置。

  TRX_UNDO_XID_EXISTS:用来标志当前日志中有没有包含Xid事务。

  TRX_UNDO_DICT_TRANS:用来标志当前日志对应的事务是不是DDL的,用来在回滚时判断如何操作。

  TRX_UNDO_TABLE_ID:与上面一个相关,如果上面标志是真的,则这个标志的是DDL的表ID。

  TRX_UNDO_NEXT_LOG:用来链接当前UNDO段中所有的UNDO日志,这个是指向下一个UNDO日志。

  TRX_UNDO_PREV_LOG:与上一个对应,这个用来指向上一个UNDO日志,从而构成双向链表。

  TRX_UNDO_HISTORY_NODE:用来存储在History List中的双向链表指针。而这个链表的首地址,是在之前我们所介绍的TRX_RSEG_HISTORY位置,可以回到前面去查看相关信息。

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

UNDO日志

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

  篇外续

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

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

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

日志

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


来源:本文由E8运维原创撰写,欢迎分享本文,转载请保留出处和链接!