【数据库】事务实现的机制，checkpoint

本文内容：

• 事务的分类
• 事务实现的机制（undo和redo）
• checkpoint机制

http://www.cnblogs.com/chenpingzhao/p/5003881.html
http://blog.csdn.net/mchdba/article/details/12242685

---

四种事务类型介绍

主要注意：

• 链事务与带有保存点的扁平事务不同的是，带有保存点的扁平事务能回滚到任意正确的保存点，而链事务中的回滚仅限当前事务，即只能恢复到最近的一个保存点，对于锁的处理，两者也不相同，锁事务在执行COMMIT后即释放了当前所持有的锁，而带有保存点的扁平事务不影响迄今为止所持有的锁
• 分布式事务的使用场景：节点A不能通过一台数据库就完成任务，其需要访问网络中两个节点的数据库，而在每个节点的数据库执行的实务操作又都是扁平的

---

事务的实现

redo log 用来保证事务的持久性，undo log 用来帮助事务回滚和MVCC的功能。

---

Undo log

性能上的两个问题：

1. 数据以同步的方式写入磁盘（如果不同步地写入，则commit之后，缓冲池清空，新的操作也消失了）
2. 写入是一个随机I/O

与redo不同，undo存放在数据库内部的一个特殊段中，称为undo段。

undo的另一个作用是MVCC（上一篇中提到过了）

---

undo log

undo log是逻辑日志，因此只是将数据库逻辑地恢复到原来的样子。（因为它是通过执行相反的dml语句来实现的。而且不会回收因为insert和upate而新增加的page页的，undo页的回收是通过masterthread线程来实现的）
undo过程是一个反向操作的过程。

• insert undo log
  针对insert操作的undo log，主要记录事务ID，对应的表对象，所有主键的列和值。该log在事务提交后可删除。
• update undo log
  针对删除和更新的undo log。因为需要提供MVCC机制，因此不能在事务提交时就进行删除。

---

redo

重做日志用来实现事务的持久性，记录的是一个数据的变化过程，即ACID中的D，由两部分组成：

一是内存中的重做日志缓冲(redo log buffer) —— 易丢失
二是重做日志文件(redo log file)—— 持久

当事务提交commit前，必须先将事务的所有日志写入到重做日志文件进行持久化，待事务commit操作完成才算完成，这里的日志指重做日志。

（上图没有将Undo log 写入磁盘的步骤画出来）
（上图同样没有数据写入磁盘的操作，可以理解成使用了redo log后，可以异步地去更新）

为了确保每次日志都能写入日志文件，在每次将重做日志缓冲写入重做日志文件后，InnoDB存储引擎都需要调用一次fsync操作，为了确保重做日志写入磁盘。

log block：

在InnoDB存储引擎中，重做日志都是以512字节进行存储的，这意味着重做日志缓存、重做日志文件块都是以块block的方式进行保存的，称为重做日志块(redo log block)每块的大小512字节。

log group

log group 重做日志组，其中有多个重做日志文件。og group是一个逻辑的概念，并没有一个实际的物理文件来表示log group信息。

恢复
InnoDB存储引擎在启动时不管上次数据运行是否正常关闭，都会尝试进行恢复操作。因为redo log 中记录了数据库的数据修改记录。因此实现了一致性。

日志结构：

---

####checkpoint
关于checkpoint机制

思考一下这个场景：如果重做日志可以无限地增大，同时缓冲池也足够大，那么是不需要将缓冲池中页的新版本刷新回磁盘。因为当发生宕机时，完全可以通过重做日志来恢复整个数据库系统中的数据到宕机发生的时刻。

但是这需要两个前提条件：1、缓冲池可以缓存数据库中所有的数据；2、重做日志可以无限增大

checkpoint机制目的是解决以下几个问题：1、缩短数据库的恢复时间；2、缓冲池不够用时，将脏页刷新到磁盘；3、重做日志不可用时，刷新脏页。（脏页：内存中的数据与磁盘上的数据不一样则成为脏页。）

• 当数据库发生宕机时，数据库不需要重做所有的日志，因为Checkpoint之前的页都已经刷新回磁盘。数据库只需对Checkpoint后的重做日志进行恢复，这样就大大缩短了恢复的时间。（利用LSN）
• 当缓冲池不够用时，根据LRU算法会溢出最近最少使用的页，若此页为脏页，那么需要强制执行Checkpoint，将脏页也就是页的新版本刷回磁盘。（注意这里是指把重做日志缓冲池中的数据写入重做日志并将其刷入磁盘）
• 当重做日志出现不可用时，因为当前事务数据库系统对重做日志的设计都是循环使用的，并不是让其无限增大的，重做日志可以被重用的部分是指这些重做日志已经不再需要（数据已经刷到磁盘），当数据库发生宕机时，数据库恢复操作不需要这部分的重做日志，因此这部分就可以被覆盖重用。如果重做日志还需要使用，那么必须强制Checkpoint，将缓冲池中的页至少刷新到当前重做日志的位置。

checkpoint：

对于InnoDB存储引擎而言，是通过LSN（Log Sequence Number）来标记版本的。
LSN是8字节的数字，每个页有LSN，重做日志中也有LSN，Checkpoint也有LSN。
LSN：log sequence number

---

checkpoint分类

在InnoDB存储引擎内部，有两种Checkpoint，分别为：Sharp Checkpoint、Fuzzy Checkpoint

sharp Checkpoint ：数据库关闭时将所有的脏页都刷新回磁盘，这是默认的工作方式，即参数innodb_fast_shutdown=1。但是若数据库在运行时也使用Sharp Checkpoint，那么数据库的可用性就会受到很大的影响。故在InnoDB存储引擎内部使用Fuzzy Checkpoint进行页的刷新，即只刷新一部分脏页，而不是刷新所有的脏页回磁盘。

Fuzzy Checkpoint：1、Master Thread Checkpoint；2、FLUSH_LRU_LIST Checkpoint；3、Async/Sync Flush Checkpoint；4、Dirty Page too much Checkpoint

1、Master Thread Checkpoint

以每秒或每十秒的速度从缓冲池的脏页列表中刷新一定比例的页回磁盘，这个过程是异步的，此时InnoDB存储引擎可以进行其他的操作，用户查询线程不会阻塞。

2、FLUSH_LRU_LIST Checkpoint

因为InnoDB存储引擎需要保证LRU列表中需要有差不多100个空闲页可供使用。在InnoDB1.1.x版本之前，需要检查LRU列表中是否有足够的可用空间。操作发生在用户查询线程中，显然这会阻塞用户的查询操作。倘若没有100个可用空闲页，那么InnoDB存储引擎会将LRU列表尾端的页移除。如果这些页中有脏页，那么需要进行Checkpoint，而这些页是来自LRU列表的，因此称为FLUSH_LRU_LIST Checkpoint。

而从MySQL 5.6版本，也就是InnoDB1.2.x版本开始，这个检查被放在了一个单独的Page Cleaner线程中进行，并且用户可以通过参数innodb_lru_scan_depth控制LRU列表中可用页的数量，该值默认为1024，如：

mysql>  SHOW GLOBAL VARIABLES LIKE 'innodb_lru_scan_depth';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_lru_scan_depth | 1024  |
+-----------------------+-------+

3、Async/Sync Flush Checkpoint

指的是重做日志文件不可用的情况，这时需要强制将一些页刷新回磁盘，而此时脏页是从脏页列表中选取的。若将已经写入到重做日志的LSN记为redo_lsn，将已经刷新回磁盘最新页的LSN记为checkpoint_lsn，则可定义：

checkpoint_age = redo_lsn - checkpoint_lsn

再定义以下的变量：

async_water_mark = 75% * total_redo_log_file_size

sync_water_mark = 90% * total_redo_log_file_size

若每个重做日志文件的大小为1GB，并且定义了两个重做日志文件，则重做日志文件的总大小为2GB。那么async_water_mark=1.5GB，sync_water_mark=1.8GB。则：

当checkpoint_age < async_water_mark时，不需要刷新任何脏页到磁盘；

当async_water_mark < checkpoint_age < sync_water_mark时触发Async Flush，从Flush列表中刷新足够的脏页回磁盘，使得刷新后满足checkpoint_age < async_water_mark；

checkpoint_age > sync_water_mark这种情况一般很少发生，除非设置的重做日志文件太小，并且在进行类似LOAD DATA的BULK INSERT操作。此时触发Sync Flush操作，从Flush列表中刷新足够的脏页回磁盘，使得刷新后满足checkpoint_age < async_water_mark。

可见，Async/Sync Flush Checkpoint是为了保证重做日志的循环使用的可用性。在InnoDB 1.2.x版本之前，Async Flush Checkpoint会阻塞发现问题的用户查询线程，而Sync Flush Checkpoint会阻塞所有的用户查询线程，并且等待脏页刷新完成。从InnoDB 1.2.x版本开始——也就是MySQL 5.6版本，这部分的刷新操作同样放入到了单独的Page Cleaner Thread中，故不会阻塞用户查询线程。

MySQL官方版本并不能查看刷新页是从Flush列表中还是从LRU列表中进行Checkpoint的，也不知道因为重做日志而产生的Async/Sync Flush的次数。但是InnoSQL版本提供了方法，可以通过命令SHOW ENGINE INNODB STATUS来观察。

4、Dirty Page too much

即脏页的数量太多，导致InnoDB存储引擎强制进行Checkpoint。其目的总的来说还是为了保证缓冲池中有足够可用的页。其可由参数innodb_max_dirty_pages_pct控制：

innodb_max_dirty_pages_pct值为75表示，当缓冲池中脏页的数量占据75%时，强制进行Checkpoint，刷新一部分的脏页到磁盘。在InnoDB 1.0.x版本之前，该参数默认值为90，之后的版本都为75。

---

Checkpoint机制

如上图所示，Innodb的一条事务日志共经历4个阶段：

• 创建阶段：事务创建一条日志；
• 日志刷盘：日志写入到磁盘上的日志文件；
• 数据刷盘：日志对应的脏页数据写入到磁盘上的数据文件；
• 写CKP：日志被当作Checkpoint写入日志文件；

对应这4个阶段，系统记录了4个日志相关的信息，用于其它各种处理使用：

• Log sequence number（LSN1）：当前系统LSN最大值，新的事务日志LSN将在此基础上生成（LSN1+新日志的大小）；
• Log flushed up to（LSN2）：当前已经写入日志文件的LSN；
• Oldest modified data log（LSN3）：当前最旧的脏页数据对应的LSN，写Checkpoint的时候直接将此LSN写入到日志文件；
• Last checkpoint at（LSN4）：当前已经写入Checkpoint的LSN；

对于系统来说，以上4个LSN是递减的，即： LSN1>=LSN2>=LSN3>=LSN4
也就是说每个阶段都会对应一个LSN号，如果系统顺序执行，每个阶段的LSN号应该呈阶梯递减状，也有可能相等，但绝不会反过来。

在Innodb事务日志中，采用了Fuzzy Checkpoint，Innodb每次取最老的modified page(last checkpoint)对应的LSN，再将此脏页的LSN作为Checkpoint点记录到日志文件，意思就是“此LSN之前的LSN对应的日志和数据都已经flush到redo log

当mysql crash的时候，Innodb扫描redo log，从last checkpoint开始apply redo log到buffer pool，直到last checkpoint对应的LSN等于Log flushed up to对应的LSN，则恢复完成

checkpoint详解