《MySQL运维内参》节选

作者：VEPHP 时间 2017-09-18

《《MySQL运维内参》节选》要点：
本文介绍了《MySQL运维内参》节选，希望对您有用。如果有疑问，可以联系我们。

引子：

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

《MySQL运维内参》节选

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

从这些代码段中可以看到,缓存到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,或者在出现问题之后,是一个很好的用来解决问题的方法,要知道,我不只一次碰到手册上面所述内容是错误的,并且有很多问题网上也是没有的,那可想而知,如果你会阅读源码了,这样的问题可以立刻迎刃而解)

篇外续

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

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

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

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

文章来自微信公众号：DBAce

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4171.html

标签：

PHP教程

WEB前端开发

数据库

WEB服务器

APP开发

LINUX学习

后端开发课程

前端开发课程

数据库课程

《MySQL运维内参》节选

数据库回滚

篇外续

同类教程排行

特辑教程