MySQL数据库InnoDB存储引擎Log漫游

  • 时间:
  • 浏览:1

- 逻辑的日志(Logical Log)

  记录在关系(表)上的有一另1个元组操作。  A. 插入一行记录。  B. 修改一行记录。  C. 删除一行记录。  逻辑日志比起物理的日志,显得简洁的多。否则占用的空间也要小的多。  否则逻辑日志有有一另1个缺点:  A. 偏离 执行     例如于:表T有有一另1个索引,在向T插入1条记录时,都都都可以分别向有一另1个B-Tree中插入记录。     有不可能 第有一另1个B-Tree插入成功了,否则第1个B-Tree如此 插入成功。在恢复或     回滚时,都都都可以防止哪些特殊情形。  B. 操作的一致性问提图片     有一另1个插入操作有有一另1个B-Tree的分裂,页A的一半数据移到了B页,A页写入了磁盘,B页如此 写入磁盘。     不可能 这然后处在了故障,都都都可以进行恢复,逻辑日志是不难 拿出的。

  B. Double write有当时人的写buffer.  C. 先将多个要做doublewrite的page写入内存的buffer,否则再一同写到磁盘上。

- Undo + Redo事务的繁杂过程

  假设有A、B有一另1个数据,值分别为1,2.  A.事务结束了了英语 了了.  B.记录A=1到undo log.  C.修改A=3.  D.记录A=3到redo log.  E.记录B=2到undo log.  F.修改B=4.  G.记录B=4到redo log.  H.将redo log写入磁盘。  I.事务提交

Undo + Redo事务的特点

  A. 为了保证持久性,都都都可以在事务提交前将Redo Log持久化。  B. 数据必须在事务提交前写入磁盘,本来缓处在内存中。  C. Redo Log 保证事务的持久性。  D. Undo Log 保证事务的原子性。  E. 有有一另1个隐含的特点,数据都都都可以要晚于redo log写入持久存储。

- 原理

  Undo Log的原理很简单,为了满足事务的原子性,在操作任何数据然后,首先将数据备份到有一另1个地方  (其他存储数据备份的地方称为Undo Log)。否则进行数据的修改。不可能 出显了错误不可能 用户执行了  ROLLBACK励志的话 ,系统还都都都可以利用Undo Log中的备份将数据恢复到事务结束了了英语 了了然后的情形。

- MTR的一致性

  为了满足MTR的一致性,MTR做了如下的设计:  A. MTR的所有日志被封装在一同,当MTR提交时一同写入redo log buffer.     然后做有有一另1个好处:     * 减少并发MTR对redo log buffer 的竞争。     * 连续的存储在一同,恢复时的防止过程更简单。  B. InnoDB在redo log的层面,将有一另1个MTR中的所有日志作为Redo log的最小单元。在恢复时,有一另1个MTR

     中的所有日志都都都可以是详细的才能进行恢复。

不可能 才能将数据缓存一段时间,就能减少IO提高性能。否则然后就会丧失事务的持久性。否则引入了另外一

种机制来实现持久化,即Redo Log.

  虽说Redo Log将数据的操作细分到了页面级别。否则其他在多个页面上的操作是逻辑上不可分裂的。

  比如B-Tree的分裂操作,对父节点和有一另1个子节点的修改。当进行恢复时,要么详细恢复,要么详细不  恢复,必须只恢复其中的偏离 页面。InnoDB中通过mini-transaction(MTR)来保证哪些不可再分  的操作的原子性。

- 同步Checkpoint

  InnoDB的buffer pool通过LRU的算法来决定哪些脏页应该被写入持久存储。不可能 中含 最小LSN的  页面频繁的被更新,它就不需要被刷到存储上。然后就不可能 是因为 checkpoint点很长一段时间无法前进,  甚至是因为 日志空间被占满。这时就要按照LSN由最小到大的顺序写一偏离 脏页到持久存储。  log_checkpoint_margin().  log_calc_max_ages()用来计算,‘判断不是要执行同步checkpoint’用到的参数.

  看mtr_memo_slot_note_modification()和buf_flush_note_modification().

  哪些类型定义在:trx0rec.h.

  记录日志的过程在:trx_undo_page_report_insert()和trx_undo_page_report_modify()中。  Undo操作在row0undo.c, row0uins.c和row0umod.c中, 入口函数是row_undo().

- 数据是哪些

  不须同的层厚和层次来看,当我们儿儿还都都都可以将数据库中的数据看作:  A. 关系数据  B. 元组或对象  C. 处在Page中的二进制序列

MySQL数据库InnoDB存储引擎事务日志系列文章:

MySQL数据库InnoDB存储引擎Log漫游(1)MySQL数据库InnoDB存储引擎Log漫游(2)

06 – Mini-Transaction(MTR)

前面提到Redo Log将数据的操作细分到了页面级别。否则其他在多个页面上的操作是逻辑上不可分裂的。InnoDB中用Mini-Transaction来表示哪些不可再细分的逻辑操作。

  B. 净页,映射到了有一另1个数据文件页,否则如此 被修改过。内容和数据文件的页一样。  C. 脏页,映射到了有一另1个数据文件页,否则数据被修改过。内容和数据文件的页不一样。

- 用Undo Log实现原子性和持久化的事务的繁杂过程

  假设有A、B有一另1个数据,值分别为1,2。  A.事务结束了了英语 了了.  B.记录A=1到undo log.  C.修改A=3.  D.记录B=2到undo log.  E.修改B=4.  F.将undo log写到磁盘。  G.将数据写到磁盘。  H.事务提交  这里有有一另1个隐含的前提条件:‘数据一定会 先读到内存中,否则修改内存中的数据,最后将数据写回磁盘’。

除了还都都都可以保证事务的原子性,Undo Log也还都都都可以用来辅助完成事务的持久化。

- 事务的原子性(Atomicity)

  事务中的所有操作,要么详细完成,要么不做任何操作,必须只做偏离 操作。不可能 在执行的过程中处在  了错误,要回滚(Rollback)到事务结束了了英语 了了前的情形,就像其他事务从来如此 执行过。

- 恢复策略

  前面说到未提交的事务和回滚了的事务也会记录Redo Log,否则在进行恢复时,哪些事务要进行特殊的  的防止.有2中不同的恢复策略:

- 数据页的最新(最大)LSN

  为了满足幂等规则,InnoDB中每个数据页上都记录有有一另1个LSN。每次更新数据页时,将LSN修改为  当前操作的redo log的LSN。在恢复时,不可能 数据页的LSN大于等于当前redo log的LSN,则跳过此  日志。

  A. 进行恢复时,只重做不可能 提交了的事务。

  B. 进行恢复时,重做所有事务包括未提交的事务和回滚了的事务。否则通过Undo Log回滚哪些     未提交的事务。

06 – 参考

  A. Database Systems: The Complete Book (2nd Edition)  B. Transaction Processing: Concepts and Techniques  C. how-innodb-performs-a-checkpoint  D. InnoDB fuzzy checkpoints  E. Heikki Tuuri Innodb answers – Part I  F. Heikki Tuuri Innodb answers – Part II

- Checksum

  检测页面不是一致的功能是靠Checksum来完成的,每个页面修改完成后一定会记算有一另1个页面的checksum。  其他checksum存贴到 页面的尾部.每次从磁盘读有一另1个页到内存时,都都都都可以检测页的一致性。  函数buf_page_is_corrupted()是用来检测page的一致性的.

- 原理

  假设在某个时间点,所有的脏页都被刷新到了磁盘上.其他时间点然后的所有Redo Log就必须重  做了。系统记录下其他时间点时redo log的结尾位置作为checkpoint. 在进行恢复时,从其他  checkpoint的位置结束了了英语 了了即可。Checkpoint点然后的日志也就不再必须,还都都都可以被删除掉。为了  更好的利用日志空间,InnoDB以环形缓存(circular buffer)的法律法律法律依据来使用日志空间。

- InnoDB Redo Log的日志类型

  InnoDB redo log的格式还都都都可以概括为:  <Space ID>+<Page NO.>+<操作类型>+<数据>.

- 页级锁

  提交时才写日志到redo log的做法,决定了MTR要使用页级锁。  A. 有一另1个页面必须一同被多个活动的MTR修改。  B. MTR中数据页的锁,直到MTR提交时(日志写入redo log buffer)后才释放。

01 – Redo Log

- 逻辑日志的一致性问提图片

  前面说了逻辑日志的一致性问提图片是很繁杂的,为哪些undo log要用逻辑日志呢?  不可能 redo log使用了physiological日志和MTR,就还都都都可以保证在恢复时重做完redo log后,  数据是一致。在执行undo时,就不须考虑其他问提图片了。

本文是介绍MySQL数据库InnoDB存储引擎重做日志漫游

- InnoDB存储引擎的恢复机制

  MySQL数据库InnoDB存储引擎使用了B策略, InnoDB存储引擎中的恢复机制有几个特点:

- 事务的持久性(Durability)

  事务一旦完成,该事务对数据库所做的所有修改一定会持久的保存到数据库中。为了保证持久性,数据库  系统会将修改后的数据详细的记录到持久的存储上。

- IO性能

  Undo + Redo的设计主要考虑的是提升IO性能。虽说通过缓存数据,减少了写数据的IO.  否则却引入了新的IO,即写Redo Log的IO。不可能 Redo Log的IO性能不好,就必须起到提高性能的目的。  为了保证Redo Log才能有比较好的IO性能,InnoDB 的 Redo Log的设计有以下几个特点:

  优点:不可能 恢复时,详细不依赖原页面上的内容,本来需要须求持久化了的数据保持在有一另1个一致的情形。

       比如在写有一另1个页面到磁盘上时,系统处在故障,页面上的一部数据写入了磁盘,另一偏离 丢失了。       这时仍然还都都都可以恢复出正确的数据。

- Double Write

  Double Write的思路很简单:  A. 在覆盖磁盘上的数据前,先将Page的内容写入到磁盘上的其他地方(InnoDB存储引擎中的doublewrite      buffer,这里的buffer一定会 内存空间,是持久存储上的空间).  B. 否则再将Page的内容覆盖到磁盘上然后的数据。

Sharp Checkpoint

- LRU

  InnoDB维护了有一另1个LRU列表。当空间处在问题时,用来决定哪些脏页应该被首先写入磁盘,哪些净页应该被释放掉。  A. buffer_pool->LRU,普通LRU链表,记录所有数据缓冲页。  B. buffer_pool->unzip_LRU,是压缩页(row_format=compressed)解压后数据缓冲页LRU链表。  LUR链表中的页面按最近一次的访问的时间顺序排列,头部是最后一次被访问的页面,尾部是最早一次被  访问的页面。无论是读还是写有一另1个页面上的数据,一定会 先获取其他页面。否则还都都都可以在获取页面时,维护  LRU链表.当获取有一另1个页面后,将其贴到 LRU链表的头部即可。  buf_page_get_gen()和buf_page_get_zip()用来获取有一另1个页面,当我们儿调用  buf_unzip_LRU_add_block()和buf_page_set_accessed_make_young()来维护LRU链表。

- MTR日志的封装

  为了在日志文件中区分不同的MTR,MTR将MLOG_SINGLE_REC_FLAG或MLOG_MULTI_REC_END写入  redo log(mtr_log_reserve_and_write()).  A. 不可能 MTR的日志中必须一行记录,在日志的结束了了英语 了了处上加MLOG_SINGLE_REC_FLAG,表示MTR中必须     三根记录。  B. 不可能 MTR的日志中含 多行记录,在日志的结尾处上加有一另1个类型为MLOG_MULTI_REC_END的日志,     代表MTR的日志到此结束了了英语 了.

微信公众号【Java技术江湖】一位阿里 Java 工程师的技术小站。(关注公众号后回复”Java“即可领取 Java基础、进阶、项目和架构师等免费学习资料,更有数据库、分布式、微服务等热门技术学习视频,内容雄厚,兼顾原理和实践,另外也将赠送作者原创的Java学习指南、Java进程员面试指南等干货资源。

- InnoDB存储引擎中相关的函数

  Redo: recv_recovery_from_checkpoint_start()  Undo: recv_recovery_rollback_active()  Undo Log的Redo Log: trx_undof_page_add_undo_rec_log()

- 脏页(dirty page)

  不可能 有一另1个数据页在内存中修改了,否则还如此 刷新到磁盘。其他数据页就称作脏页。

00 – Undo Log

Undo Log 是为了实现事务的原子性,在MySQL数据库InnoDB存储引擎中,还用Undo Log来实现多版本并发控制(简称:MVCC)。

理论上来说,不可能 MySQL数据库InnoDB存储引擎的buffer足够大,就必须将数据其他持久化。将详细的redo log重新执行一遍

就还都都都可以恢复所有的数据。否则随着时间的积累,Redo Log会变的很大很大。不可能 每次都从三根记录结束了了英语 了了恢复,恢复的过程就会很慢,从而无法被容忍。为了减少恢复的时间,就引入了Checkpoint机制。

- 物理和逻辑结合的日志(Physiological Log)

  其他日志将物理和逻辑日志相结合,取其利,去其害。从而达到有一另1个相对更好的有一另1个情形。其他日志有有一另1个特点:  A. 物理到page. 将操作细分到页级别。为每个页上的操作单独记日志。     比如,有一另1个Insert分别在有一另1个B-Tree的节点上做了插入操作,如此 就分别为每有一另1个页的操作记录三根日志。  B. Page内采用逻辑的日志。比如对有一另1个B-Tree的页内插入三根记录时,物理上来说要修改Page Header的     内容(如,页内的记录数要加1),要插入一行数据到某个位置,要修改相邻记录里的链表指针,要修改Slot的     属性等。从逻辑上来说,也没得其他页内插入了一行记录。否则Page内的逻辑日志只记录:’这是有一另1个     插入操作’和’这行数据的内容‘。

  MySQL数据库InnoDB存储引擎的Redo Log 记录的本来其他物理和逻辑相结合的日志。

  使用页内的逻辑日志,还都都都可以减少日志占用的空间。否则它毕竟还是逻辑日志,上方提到的有一另1个问提图片才能防止吗?  A. 页面内的偏离 执行的情形还都都都可以认为不处在了。不可能 整个页面的操作是原子操作,在完成然后是不需要写     到磁盘上的。  B. 操作一致性的问提图片仍然处在。不可能 在写有一另1个Page到磁盘时处在了故障,不可能 是因为 Page Header的记     录数被加1了,否则数据如此 刷新到磁盘上,总之页面上的数据不一致了。

  这里只提到了偏离 Redo Log的类型,详细的定义在mtr0mtr.h文件中. 通过其他类型的定义,还都都都可以

  很容易的找到一定会 哪些使用了。

处在问题:每个事务提交前将数据和Undo Log写入磁盘,然后会是因为 少量的磁盘IO,否则性能很低。

  缺点:Log记录的内容本来,占用很大的空间。如B-Tree的分裂操作,要记录约有一另1个详细Page的内容。

- flush_list

  同步checkpoint时,都都都可以根据数据页修改的先后顺序来将脏页写入持久存储。否则除了LRU链表,  buffer pool中还有有一另1个按脏页修改先后顺序排列的链表,叫flush_list.当都都都可以同步checkpoint时,  根据flush_list中页的顺序刷数据到持久存储。  A. 有一另1个页只在flush_list中出显1次,不可能 有一另1个页面只都都都可以写一次。  B. 按页面最早一次被修改的顺序排列。

- 幂等(Idempotence)规则

  如上图所示,checkpoint 在LSN1位置,当checkpoint完成时R1,R2对应的修改也被刷到了持久存储。  恢复都都都可以从LSN1位置结束了了英语 了了,包括R1, R2在内。重新执行后,数据还能正确吗?  幂等规则要求无论redo log被执行了几个次,数据始终正确。  InnoDB的redo log, 物理到Page,Page内是逻辑日志。  物理日志,碳酸岩支持幂等规则. 否则逻辑日志 都都都可以特殊防止,才能支持满足幂等规则。

  Redo Log记录的页面操作大致还都都都可以分为以下几种类型:

  A. 在页面上写入N个字节的内容,哪些还都都都可以看作是物理的Log.     MLOG_1BYTE, MLOG_2BYTES, MLOG_4BYTES, MLOG_8BYTES, MLOG_WRITE_STRING     各种Page链表的指针修改,以及文件头,段页等的内容的修改一定会 以其他法律法律法律依据记录的日志。  B. 页面上的记录操作。     MLOG_REC_*, MLOG_LIST_*, MLOG_COMP_REC_*, MLOG_COMP_LIST_*     哪些日志记录了对B-Tree页的INSER, DELETE, UPDATE操作和分裂合并操作。  C. 文件和Page操作     MLOG_FILE_CREATE, MLOG_FILE_RENAME, MLOG_FILE_DELETE,     MLOG_PAGE_CREATE, MLOG_INIT_FILE_PAGE, MLOG_PAGE_REORGANIZE  D. Undo Log操作     MLOG_UNDO_*     InnoDB中将undo log的操作也记入了redo log. 为哪些要然后做,在前面‘恢复’不可能 说了.

03 – 日志的内容

- MTR的ROLLBACK

  看了MTR的代码发现mtr如此 记录undo日志,也才能rollback. MTR一定会 很小的操作单元,否则每个MTR  一定会 明确的操作目标,否则比较容易保证其正确性。  A. 不可能 页面操作是在内存中完成,否则页面有固定的格式,否则本来的页面操作是不需要失败的。     InnoDB存储引擎中的本来写页面的函数都如此 返回值.  B. 在对任何页面操作前,不难 检查不是不可能 处在错误。不可能 不可能 处在错误就必须往下执行。     如,当插入一行记录到B-Tree的节点时,首先检查页面有足够的空间。  C. 使用更大粒度的锁(如B-Tree的锁),否则按照一定的顺序加锁。然后才能不是因为 死锁问提图片。

04 – Checkpoint

02 – 恢复(Recovery)

  A. 尽量保持Redo Log存储在一段连续的空间上。否则在系统第一次启动时就会将日志文件的空间详细分配。

     以顺序追加的法律法律法律依据记录Redo Log,通过顺序IO来改善性能。  B. 批量写入日志。日志并一定会 直接写入文件,本来先写入redo log buffer.当都都都可以将日志刷新到磁盘时     (如事务提交),将其他日志一同写入磁盘.  C. 并发的事务共享Redo Log的存储空间,它们的Redo Log按励志的话 的执行顺序,依次交替的记录在一同,     以减少日志占用的空间。例如于,Redo Log中的记录内容不可能 是然后的:     记录1: <trx1, insert …>     记录2: <trx2, update …>     记录3: <trx1, delete …>     记录4: <trx3, update …>     记录5: <trx2, insert …>  D. 不可能 C的是因为 ,当有一另1个事务将Redo Log写入磁盘时,也会将其他未提交的事务的日志写入磁盘。  E. Redo Log上只进行顺序追加的操作,当有一另1个事务都都都可以回滚时,它的Redo Log记录本来需要

  代码在:buf0dblwr.cc

  buf_flush_write_block_low()调用  buf_dblwr_write_single_page()或 buf_dblwr_add_to_batch()来实现doublewrite.

- Fuzzy Checkpoint

  如下图所示,不可能 刷脏页的一同用户还在更新数据,LSN1前的某个脏页在刷到持久存储然后一定会 不可能 被  LSN1然后的某个操作给修改了。当checkpoint完成时,LSN1后的偏离 操作(R1,R2对应的操作)也被  持久化了。当Sharp checkpoint完成时,持久存储中存储的数据是某个确切时间点的内存数据的快照。  Fuzzy checkpoint完成时,持久存储中存储的数据一定会 某个确切时间点的内存数据的快照。从其他  程度上,还都都都可以说持久存储中的数据丧失了一致性。在恢复时,都都都可以要防止其他问提图片。

- InnoDB Undo Log的日志类型

  MySQL数据库InnoDB存储引擎的undo log采用了逻辑的日志。  InnoDB undo log的格式还都都都可以概括为:<操作类型>+<Table ID>+<数据>.

- 原理

  和Undo Log相反,Redo Log记录的是新数据的备份。在事务提交前,否则将Redo Log持久化即可,  必须将数据持久化。当系统崩溃时,实在数据如此 持久化,否则Redo Log不可能 持久化。系统还都都都可以根据  Redo Log的内容,将所有数据恢复到最新的情形。

- MTR的LSN

  A. 不可能 在将日志写入redo log buffer时,才能获得LSN。本来修改数据时,并如此 修改页上的LSN。     都都都可以在MTR获得LSN后统一修改。  B. 有一另1个MTR必须有一另1个LSN. 有一另1个MTR内修改的所有页的LSN相同。然后checkpoint就不需要出显在MTR的上方。  C. 在获得LSN后,不可能 被MTR修改的脏页没得buffer pool的flush_list里,就会被上上加。

- 日志顺序号(Log Sequence Number)

  LSN是日志空间中每条日志的结束了了英语 了点,用字节偏移量来表示。在Checkpoint和恢复时使用。

  A. 从表中删除一行记录

     TRX_UNDO_DEL_MARK_REC(将主键记入日志)     在删除三根记录时,并一定会 真正的将数据从数据库中删除,本来标记为已删除.然后做的好处是     Undo Log中不需要记录整行的信息.在undo时操作也变得很简单.

  B. 向表中插入一行记录     TRX_UNDO_INSERT_REC(将主键记入日志)     TRX_UNDO_UPD_DEL_REC(仅将主键记入日志) 当表中含 三根被标记为删除的记录和要插入的     数据主键相一同, 实际的操作是更新其他被标记为删除的记录。  C. 更新表中的三根记录     TRX_UNDO_UPD_EXIST_REC(将主键和被更新了的字段内容记入日志)     TRX_UNDO_DEL_MARK_REC和TRX_UNDO_INSERT_REC,当更新主键字段时,实际执行的过程     是删除旧的记录否则,再插入三根新的记录。

05 – 缓存池(Buffer Pool)

学习到这里,我更倾向于说这是有一另1个”Redo+Undo+Buffer”的模式。为了提搞IO性能,脏页缓处在buffer中,Redo log也要先缓处在内存中,doublewrite一定会 内存buffer. Buffer pool在其他模式中是至关重要的。

Fuzzy Checkpoint

  逻辑的日志上的‘偏离 执行’的问提图片是比较好维护的,否则‘一致性’的问提图片维护起来是很繁杂的。

  好在其他问提图片被缩小到了有一另1个页面的范围内,否则比较容易防止。InnoDB存储引擎中用Double Write的法律法律法律依据

  来防止其他问提图片。

  A. 在重做Redo Log时,并不关心事务性。 恢复时,如此 BEGIN,也如此 COMMIT,ROLLBACK的行为。

     本来关心每个日志是哪个事务的。尽管事务ID等事务相关的内容会记入Redo Log,哪些内容本来被当作     要操作的数据的一偏离 。  B. 使用B策略就都都都可以要将Undo Log持久化,否则都都都可以要在写Redo Log然后将对应的Undo Log写入磁盘。     Undo和Redo Log的其他关联,使得持久化变得繁杂起来。为了降低繁杂度,InnoDB将Undo Log看作     数据,否则记录Undo Log的操作也会记录到redo log中。然后undo log就还都都都可以象数据一样缓存起来,     而不需要在redo log然后写入磁盘了。     中含 Undo Log操作的Redo Log,看起来是然后的:     记录1: <trx1, Undo log insert <undo_insert …>>     记录2: <trx1, insert …>     记录3: <trx2, Undo log insert <undo_update …>>     记录4: <trx2, update …>     记录5: <trx3, Undo log insert <undo_delete …>>     记录6: <trx3, delete …>  C. 到这里,还有有一另1个问提图片如此 弄清楚。既然Redo如此 事务性,那实在 会重新执行被回滚了的事务?     实在是然后。一同Innodb也会将事务回滚时的操作也记录到redo log中。回滚操作本质上也是     对数据进行修改,否则回滚时对数据的操作也会记录到Redo Log中。     有一另1个回滚了的事务的Redo Log,看起来是然后的:     记录1: <trx1, Undo log insert <undo_insert …>>     记录2: <trx1, insert A…>     记录3: <trx1, Undo log insert <undo_update …>>     记录4: <trx1, update B…>     记录5: <trx1, Undo log insert <undo_delete …>>     记录6: <trx1, delete C…>     记录7: <trx1, insert C>     记录8: <trx1, update B to old value>     记录9: <trx1, delete A>     有一另1个被回滚了的事务在恢复时的操作本来先redo再undo,否则不需要破坏数据的一致性.

- Sharp Checkpoint

  对于繁忙的系统来说,很少会出显然后的的有一另1个时间点。为了能创发明人人然后有一另1个时间点,最简单的办  法本来,在某个时间结束了了英语 了了停止一切更新操作,直到所有的脏页被刷新到磁盘,Checkpoint被记录。 

  显然对于繁忙的系统, 其他法律法律法律依据是不离米 的。还都都都可以在checkpoint时不停止用户的操作呢?

- 页分类

  Buffer pool内的页分为其他:  A. 未被使用的页(空白的buffer),如此 映射到有一另1个数据文件中页。

本文主要介绍了final关键字的使用法律法律法律依据及原理

  以上是当时人看代码后的离米 印象,不一定说到了正点上。MTR模块的代码虽简单,否则MTR在其他模块少量的

  使用。要透彻的理解MTR,估计还得要看其他模块的代码,分派出来大偏离 MTR操作过程才行.

  否则Log中也还都都都可以记录不同的内容:

- 物理的日志(Physical Log)  A. 记录详细的Page  B. 记录Page中被修改的偏离 (page中的偏移,内容和长度).

  不可能 undo log都都都可以被MVCC和Purge使用,本来还有TRX_ID和DATA_ROLL_PTR等特殊的内容记录

  在日志中。TRX_UNDO_INSERT_REC必须记录哪些内容.不可能 MVCC中不可内引用有一另1个不处在的数据。  这也是事务将insert和update、delete的undo log分开存放的是因为 。事务提交后,insert的undo  占用的空间就还都都都可以立即释放了.

  Double write 显然会曾加磁盘的IO。直觉上IO次数增加了1倍,否则性能损失并一定会 很大。Peter在

  innodb-double-write中说性能损失不超过5-10%。应该是不可能 多数情形下使用了批量写入的缘故。  A. Double write buffer是一段连续的存储空间,还都都都可以顺序写入。

  固然能一同保证原子性和持久化,是不可能 以下特点:

  A. 更新数据前记录Undo log。  B. 为了保证持久性,都都都可以将数据在事务提交前写到磁盘。否则事务成功提交,数据必然不可能 持久化。  C. Undo log都都都可以先于数据持久化到磁盘。不可能 在G,H之间系统崩溃,undo log是详细的,     还都都都可以用来回滚事务。  D. 不可能 在A-F之间系统崩溃,不可能 数据如此 持久化到磁盘。本来磁盘上的数据还是保持在事务结束了了英语 了了前的情形。

  不可能 在A步骤时系统故障,然后的数据如此 被覆盖,还是详细的。

  不可能 在B步骤时系统故障,然后的数据不详细了,否则新数据不可能 被详细的写入了doublewrite buffer.  否则系统恢复时就还都都都可以用doublewrite buffer中的新Page来覆盖其他不详细的page.

  锁对象存储在mtr的memo中。调用mtr_s_lock和mtr_x_lock来加锁时,锁对象被保存到memo中。

  解锁在mtr_memo_slot_release()中完成。

- 异步Checkpoint

  实现了幂等规则后,脏页就还都都都可以在任何时能 间,以任何顺序写入持久存储了。InnoDB的buffer pool有  一套单独的机制来刷脏页。否则本来情形下checkpoint时,不须写脏页到存储。本来将所有脏页的  最小的LSN记做checkpoint.  checkpoint的实现在log0log.c.  log_checkpoint()实现异步checkpoint.