innodb下mysql的mvcc

jinguanding

原帖由 fan_zhen_hua 于 2010-8-23 21:45 发表
[quote]原帖由 justlooks 于 2010-8-20 09:55 发表
能详细解释一下吗？
关于trx id是tx id吧。
数据块有两个隐含列，当有新事务过来时访问这条数据时，如果有tx_id ，那么说明这条数据正在被更新，并且能够找到相应的undo信息。。这些信息是在数据块上的。

假设有部分事务没有结束，那么当db 意外down机，比如停电时，innodb是如何来恢复的呢？？（我猜想通过innodb的事务日志文件来恢复？因为通过binlog只有redo信息，没有undo的信息。无法进行恢复。）

查到了如下的资料:


是不是可以将innodb的事务日志的作用理解为oracle中的redo,将binlog的作用理解为oracle中的归档，不过也包含了redo.

logfile就是redo，而tablespace 中会存储undo的数据

fan_zhen_hua

恩。这一块明白了。一般才配置了两个innodb的事务日志。。后来想了下，一般两个就够了，因为innodb的事务日志可以直接被覆盖，不用象oracle那样需要等待归档完才能被重写。

justlooks

上面已经说过了，record中会有trx_id和rseg_ptr2个系统列,而当前事务读到这个record会根据自身的read_view这个结构和这个record的trx_id运用mvcc的判断规则,如果判定需要一致性读先前版本的话那么会根据rseg_ptr指向的rollback segment结构的对应的undo log记录来构建先前版本的record

jinguanding

那样可能会导致，做checkpoint多的，覆盖是没有错的....但是只能覆盖完成掉了事务redo日志

所以这个文件组数多少，以及每个文件大小多少，都需要考虑的...一般情况下512M2组都够用


另外mysql可能不会像Oracle那样集中式去用

[ 本帖最后由 jinguanding 于 2010-8-24 18:08 编辑 ]

fan_zhen_hua

恩。一致性读也是根据undo来构建的，这块跟oracle基本是类似的。。。

[ 本帖最后由 fan_zhen_hua 于 2010-8-24 21:17 编辑 ]

fan_zhen_hua

另外mysql可能不会像Oracle那样集中式去用 没看明白？
那样可能会导致，做checkpoint多的。mysql的checkpoint有哪些因素可以触发呢？我先回家了，回家查查资料。

fan_zhen_hua

找了下innodb的checkpoint。
对于innodb中,innodb innodb_flush_log_at_trx_commit=1，在每次commit后，innodb buffer同步刷新输出到文件，这时进行checkpoint。因为事务日志是顺序写的。所以在实例crash时，可以根据checkpoint来进行恢复。innodb的checkpoint发生在事务日志中，（oracle则在control file中）。不知道这样的理解对不对。除了commit之外，不知道是否还有别的动作会触发checkpoint。当然，stop mysql也会发生

以下摘自官网。光从文字的描述中，对有些点还是不太了解。大家可以讨论一下。

InnoDB实现一种被认识为“模糊”检查点设置的检查点机制。InnoDB以小批量从缓冲池刷新已修改的数据库页。没必要以单个批次刷新缓冲池，单批次刷新实际操作中可能会在检查点设置进程中停止用户SQL语句的处理。

在崩溃恢复中，InnoDB找寻被写进日志的检查点标签。它知道所有在该标签之前对数据库的修改被呈现在数据库的磁盘映像中。然后InnoDB从检查点往前扫描日志文件，对数据库应用已写入日志的修改。

InnoDB以循环方式写日志文件。所有使得缓冲池里的数据库页与磁盘上的映像不同的已提交修改必须出现在日志文件中，以备万一InnoDB需要做一个恢复。这意味着，当InnoDB开始重新使用一个日志文件，它需要确认在磁盘上的数据库页映像包含已写进InnoDB准备重新使用的日志文件里的修改。换句话说，InnoDB必须创建一个检查点，这经常涉及已修改数据库页到磁盘的刷新。

前面的叙述解释了为什么使你的日志文件非常大会在设置检查点中节约磁盘I/O。设置日志文件总的大小和缓冲池一样大或者甚至比缓冲池大通常是有意义的。大日志文件的缺点是崩溃恢复要花更长的时间，因为有更多写入日志的信息要应用到数据库上。

[ 本帖最后由 fan_zhen_hua 于 2010-8-26 23:02 编辑 ]

ucgary

to fan_zhen_hua
checkpoint是一种机制,是触发同步各种文件的,永久写入脏数据到磁盘的,你所说的 （oracle则在control file中）,不是那么准确.

"除了commit之外，不知道是否还有别的动作会触发checkpoint。"
checkpoint我理解是一种批量的操作. 有文档说commit会触发checkpoint吗???

"因为innodb的事务日志可以直接被覆盖，不用象oracle那样需要等待归档完才能被重写。"
innodb的事务日志如果要被覆盖,要先确认这些信息已经写入数据文件了,否则会发生checkpoint .这点和oracle类似.