在InnoDB中，bufferpool里面的dirtypage一方面可以加快数据处理速度，同时也会造成数据的不一致(RAMvsDISK)。本文介绍了dirtypage是如何产生，以及InnoDB如何利用redolog如何消除dirtypage产生的数据不一致。
一、原理
-
当事务(Transaction)需要修改某条记录（row）时，InnoDB需要将该数据所在的page从disk读到bufferpool中，事务提交后，InnoDB修改page中的记录(row)。这时bufferpool中的page就已经和disk中的不一样了，我们称bufferpool中的page为dirtypage。Dirtypage等待flush到disk上，查看 buffer_pool: SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_%';。
-
dirtypage既然是在Bufferpool中，那么如果系统突然断电Dirtypage中的数据修改是否会丢失？这个担心是很有必要的，例如如果一个用户完成一个操作（数据库完成了一个事务，page已经在bufferpool中修改，但dirtypage尚未flush），这时系统断电，bufferpool数据全部消失。那么，这个用户完成的操作（导致的数据库修改）是否会丢失呢？答案是不会(innodb_flush_log_at_trx_commit=1)。这就是redolog要做的事情，在disk上记录更新。
-
redolog在每次事务commit的时候，就立刻将事务更改操作记录到redolog，保证事务的持久性。所以即使bufferpool中的dirtypage在断电时丢失，InnoDB在启动时，仍然会根据redolog中的记录完成数据恢复。
-
redolog的另一个作用是，通过延迟dirtypage的flush最小化磁盘的randomwrites。（redolog会合并一段时间内TRX对某个page的修改）
-
正常情况下，dirty page什么时候flush到disk上？
1).redolog是一个环(ring)结构，当redo空间占满时，将会将部分dirtypageflush到disk上，然后释放部分redolog。这种情况可以通过Innodb_log_wait(SHOWGLOBALSTATUS)观察，情况发生该计数器会自增一次。
2).当需要在Bufferpool分配一个page，但是已经满了，并且所有的page都是dirty的（否则可以释放不dirty的page），通常是不会发生的。这时候必须flushdirtypagestodisk。这种情况将会记录到Innodb_buffer_pool_wait_free中。一般地，可以通过启动参数innodb_max_dirty_pages_pct控制这种情况，当bufferpool中的dirtypage到达这个比例的时候，将会强制设定一个checkpoint，并把dirtypageflush到disk中。
3).检测到系统空闲的时候，会flush，每次64pages。 -
涉及的InnoDB配置参数：innodb_flush_log_at_trx_commit、innodb_max_dirty_pages_pct；状态参数：Innodb_log_wait、Innodb_buffer_pool_wait_free。
-
参数innodb_flush_log_at_trx_commit用来控制事务日志刷新到磁盘的策略。
默认innodb_flush_log_at_trx_commit=1，表示在每次事务提交的时候，都把log buffer刷到文件系统中去，并且调用文件系统的“flush”操作将缓存刷新到磁盘上去。这样的话，数据库对IO的要求就非常高了，如果底层的硬件提供的IOPS比较差，那么MySQL数据库的并发很快就会由于硬件IO的问题而无法提升。为了提高效率，保证并发，牺牲一定的数据一致性。innodb_flush_log_at_trx_commit还可以设置为0和2。
innodb_flush_log_at_trx_commit=0时，提交事务时并不将log buffer写入磁盘，而是等待主线程每秒的刷新。
innodb_flush_log_at_trx_commit=2时，事务提交时将事务日志写入redo log file，但仅写入文件系统的缓存，不进行fsync操作。在这个设置下，当MySQL数据库发生宕机而操作系统不发生宕机，并不会导致事务的丢失。
二、关于有关参数的配置
1、innodb_buffer_pool_size：该参数确保有足够大的日志缓冲区来保存脏数据在被写入到日志文件之前
2、innodb_log_file_size ：该参数决定着mysql事务日志文件（ib_logfile0）的大小；
3、innodb_flush_log_at_trx_commit用来控制事务日志刷新到磁盘的策略
默认innodb_flush_log_at_trx_commit=1，表示在每次事务提交的时候，都把log buffer刷到文件系统中去，并且调用文件系统的“flush”操作将缓存刷新到磁盘上去。这样的话，数据库对IO的要求就非常高了，如果底层的硬件提供的IOPS比较差，那么MySQL数据库的并发很快就会由于硬件IO的问题而无法提升。为了提高效率，保证并发，牺牲一定的数据一致性。innodb_flush_log_at_trx_commit还可以设置为0和2。
innodb_flush_log_at_trx_commit=0时，提交事务时并不将log buffer写入磁盘，而是等待主线程每秒的刷新。
innodb_flush_log_at_trx_commit=2时，事务提交时将事务日志写入redo log file，但仅写入文件系统的缓存，不进行fsync操作。在这个设置下，当MySQL数据库发生宕机而操作系统不发生宕机，并不会导致事务的丢失。
4、innodb_file_per_table：该参数设置为on时，每张表都建一个ibd文件，否则合用ibdata1
5、innodb_log_files_in_group：该参数控制日志文件数。默认值为2。mysql 事务日志文件是循环覆写的。
需要注意的是：innodb_log_files_in_group是静态的变量，需要以“干净”的方式更改并重新启动，否则mysql启动不起来。也就是说如果想把原来是2的修改成3，这样的话你需要先关闭mysql服务，把原来的ib_logfile0和ib_logfile1文件删掉，然后启动mysql，否则报错如下所示：
直接修改my.cnf将该参数改为3的时候
重启mysql，报错，innodb引擎无法挂载
110124 14:06:23 InnoDB: Log file ./ib_logfile2 did not exist: new to be created
110124 14:06:23 [ERROR] Plugin 'InnoDB' init function returned error.
110124 14:06:23 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
6、sync_binlog
MySQL提供一个sync_binlog参数来控制数据库的binlog刷到磁盘上去。
默认，sync_binlog=0，表示MySQL不控制binlog的刷新，由文件系统自己控制它的缓存的刷新。这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。
如果sync_binlog>0，表示每sync_binlog次事务提交，MySQL调用文件系统的刷新操作将缓存刷下去。最安全的就是sync_binlog=1了，表示每次事务提交，MySQL都会把binlog刷下去，是最安全但是性能损耗最大的设置。这样的话，在数据库所在的主机操作系统损坏或者突然掉电的情况下，系统才有可能丢失1个事务的数据。但是binlog虽然是顺序IO，但是设置sync_binlog=1，多个事务同时提交，同样很大的影响MySQL和IO性能。虽然可以通过group commit的补丁缓解，但是刷新的频率过高对IO的影响也非常大。对于高并发事务的系统来说，“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。
所以很多MySQL DBA设置的sync_binlog并不是最安全的1，而是100或者是0。这样牺牲一定的一致性，可以获得更高的并发和性能。
7、query_cache_size：查询缓存是否开启。 值为0，表示禁用query cache，而默认配置正是配置为0
have_query_cache 表示这个mysql版本是否支持查询缓存
query_cache_size 用于查询缓存的内存大小
query_cache_limit 表示单个结果集所被允许缓存的最大值。