InnoDB之Dirty page、Redo log

http://zhumeng8337797.blog.163.com/blog/static/1007689142011215863105/?suggestedreading&wumii

---有一部分oracle的描述

在InnoDB中，buffer pool里面的dirty page一方面可以加快数据处理速度，同时也会造成数据的不一致(RAM vs DISK)。本文介绍了dirty page是如何产生，以及InnoDB如何利用redo log如何消除dirty page产生的数据不一致。

1. 当事务(Transaction)需要修改某条记录（row）时，InnoDB需要将该数据所在的page从disk读到buffer pool中，事务提交后，InnoDB修改page中的记录(row)。这时buffer pool中的page就已经和disk中的不一样了，我们称buffer pool中的page为dirty page。Dirty page等待flush到disk上。
   
   
   
    
   
2. dirty page既然是在Buffer pool中，那么如果系统突然断电Dirty page中的数据修改是否会丢失？这个担心是很有必要的，例如如果一个用户完成一个操作（数据库完成了一个事务，page已经在buffer pool中修改，但dirty page尚未flush），这时系统断电，buffer pool数据全部消失。那么，这个用户完成的操作（导致的数据库修改）是否会丢失呢？答案是不会(innodb_flush_log_at_trx_commit=1)。这就是redo log要做的事情，在disk上记录更新。
3. redo log在每次事务commit的时候，就立刻将事务更改操作记录到redo log。所以即使buffer pool中的dirty page在断电时丢失，InnoDB在启动时，仍然会根据redo log中的记录完成数据恢复。
4. redo log的另一个作用是，通过延迟dirty page的flush最小化磁盘的random writes。（redo log会合并一段时间内TRX对某个page的修改）
5. 
   
   
   
    
6. 正常情况下，dirty page什么时候flush到disk上？
   1).redo log是一个环(ring)结构，当redo空间占满时，将会将部分dirty page flush到disk上，然后释放部分redo log。这种情况可以通过Innodb_log_wait(SHOW GLOBAL STATUS)观察，情况发生该计数器会自增一次。
   2).当需要在Buffer pool分配一个page，但是已经满了，并且所有的page都是dirty的（否则可以释放不dirty的page），通常是不会发生的。这时候必须flush dirty pages to disk。这种情况将会记录到Innodb_buffer_pool_wait_free中。一般地，可以可以通过启动参数innodb_max_dirty_pages_pct控制这种情况，当buffer pool中的dirty page到达这个比例的时候，将会强制设定一个checkpoint，并把dirty page flush到disk中。
   3).检测到系统空闲的时候，会flush，每次64 pages。
7. 涉及的InnoDB配置参数：innodb_flush_log_at_trx_commit、innodb_max_dirty_pages_pct；状态参数：Innodb_log_wait、Innodb_buffer_pool_wait_free。

参考文献

1. http://mysqldump.azundris.com/archives/78-Configuring-InnoDB-An-InnoDB-tutorial.html
2. http://dev.mysql.com/doc/refman/5.0/en/innodb.html

看了这个之后，对数据库的日志和回滚、恢复操作又多了一些理解：
转载记录之
 
redo log 重做日志/undo log 撤消日志
重做日志：每当有操作执行前，将数据真正更改时，先前相关操作写入重做日志。这样当断电，或者一些意外，导致后续任务无法完成时，系统恢复后，可以继续完成这些更改

撤消日志：当一些更改在执行一半时，发生意外，而无法完成，则可以根据撤消日志恢复到更改之前的壮态

网上找到一些解说：以便以后自己参考
有两个概念：前滚与回退
比如某一时刻数据库DOWN机了，有两个事务，一个事务已经提交，另一个事务正在处理
数据库重启的时候就要根据日志进行前滚及回退，把已提交事务的更改写到数据文件，未提交事务的更改恢复到事务开始前的状态。


redo--> undo-->datafile
insert一条记录时, 表跟undo的信息都会放进 redo 中, 在commit 或之前, redo 的信息会放进硬盘上. 故障时, redo 便可恢复那些已经commit 了的数据.
redo->每次操作都先记录到redo日志中，当出现实例故障（像断电），导致数据未能更新到数据文件，则数据库重启时须redo，重新把数据更新到数据文件
undo->记录更改前的一份copy，但你系统rollback时，把这份copy重新覆盖到原来的数据
redo->记录所有操作，用于恢复（redo records all the database transaction used for recovery）
undo->记录所有的前印象，用于回滚（undo is used to store uncommited data infor used for rollback）
redo->已递交的事务,实例恢复时要写到数据文件去的 
undo->未递交的事务.
redo的原因是：每次commit时，将数据的修改立即写到online redo中，但是并不一定同时将该数据的修改写到数据文件中。因为该数据已经提交，但是只存在联机日志文件中，所以在恢复时需要将数据从联机日志文件中找出来，重新应用一下，使已经更改数据在数据文件中也改过来！
undo的原因是：在oracle正常运行时，为了提高效率，加入用户还没有commit,但是空闲内存不多时，会由DBWR进程将脏块写入到数据文件中，以便腾出宝贵的内存供其它进程使用。这就是需要UNDO的原因。因为还没有发出commit语句，但是oracle的dbwr进程已经将没有提交的数据写到数据文件中去了。
undo 也是也是datafile， 可能dirty buffer 没有写回到磁盘里面去。
只有先redo apply 成功了，才能保证undo datafile 里面的东西都是正确的，然后才能rollback
做undo的目的是使系统恢复到系统崩溃前(关机前)的状态,再进行redo是保证系统的一致性. 
不做undo,系统就不会知道之前的状态,redo就无从谈起
所以instance crash recovery 的时候总是先rollforward， 再rollback
undo
回退段中的数据是以“回退条目”方式存储。
回退条目=块信息(在事务中发生改动的块的编号)+在事务提交前存储在块中的数据
在每一个回退段中oracle都为其维护一张“事务表”
在事务表中记录着与该回退段中所有回退条目相关的事务编号（事务SCN&回退条目）
redo
重做记录由一组“变更向量”组成。
每个变更变量中记录了事务对数据库中某个块所做的修改。
当用户提交一条commit语句时，LGWR进程会立刻将一条提交记录写入到重做日志文件中，然后再开始写入与该事务相关的重做信息。
#事务提交成功后，Oracle将为该事备生成一个系统变更码（SCN）。事务的SCN将同时记录在它的提交记录和重做记录中。
commit
提交事务前完成的工作：
?在SGA区的回退缓存中生成该事务的回退条目。在回退条目中保存有该事务所修改的数据的原始版本。
?在SGA区的重做日志缓存中生成该事务的重做记录。重做记录中记载了该事务对数据块所进行的修改，并且还记载了对回退段中的数据块所进行的修改。缓存中的重做记录有可能在事务提交之前就写入硬盘中。
?在SGA区的数据库缓丰中记录了事务对数据库所进行的修改。这些修改也有可能在事务提交之前就写入硬盘中。
提交事务时完成的工作：
?在为该事务指定的回退段中的内部事务表内记录下这个事务已经被提交，并且生成一个惟一的SCN记录在内部事务表中，用于惟一标识这个事务。
?LGWR后进进程将SGA区重做日志缓存中的重做记录写入联机重做日志文件。在写入重做日志的同时还将写入该事务的SCN。
?Oracle服务进程释放事务所使用的所有记录锁与表锁。
?Oracle通知用户事务提交完成。
?Oracle将该事务标记为已完成。
rollback
回退事务完成的工作：
?Oracle通过使用回退段中的回退条目，撤销事务中所有SQL语句对数据库所做的修改。
?Oracle服务进程释放事务所使用的所有锁
?Oracle通知事务回退成功。
?Oracle将该事务标记为已完成
举个例子：
insert into a(id) values(1);(redo)
这条记录是需要回滚的。
回滚的语句是delete from a where id = 1;(undo)
试想想看。如果没有做insert into a(id) values(1);(redo)
那么delete from a where id = 1;(undo)这句话就没有意义了。
现在看下正确的恢复:
先insert into a(id) values(1);(redo)
然后delete from a where id = 1;(undo)
系统就回到了原先的状态，没有这条记录了。