内存刷新机制

red log buffer、data buffer、binlog cache。在O和M中，讲究日志先行策略，就是一条DML语句进入数据库以后，都会先写日志，再写数据文件。

1.red log，

重作日志文件，用于记录事务操做的变化，记录的是数据修改以后的值，无论事务是否提交都会记录下来。在实例和介质失败时，重作日志文件就能派上用场，如数据库掉电，InnoDB存储引擎会使用重作日志恢复到掉电前的时刻，以此来保证数据的完整性。

默认状况下至少有两个red log文件，在磁盘上用ib_logfile(0-N)命名。

red log写的方式是顺序和循环写，当写满最后一个文件时，会从新从第一个文件开始写，写满日志文件会产生切换操做，并执行 checkpoint,触发脏页的刷新。MySQL数据库重启过程当中，若是参数文件中的red log值大小与当前redo log值不一致，会把现有redo log 删除，并按照参数文件中设置的大小，从新生成新的redo log文件。

（1）在磁盘中生成 red log文件以前，数据是先写在red log buffer中的。

• 经过innodb_flush_log_at_trx_commit参数来控制。该参数分别为0，1，2
• 0的含义:red log thread每隔1秒会将red log buffer中的数据写入red log文件，同时进行刷盘操做。保证数据确实写入磁盘。在此参数下，每次事务提交并不会触发red log thread将日志缓冲中的数据写入red log文件。
• 1的含义:每次事务提交时，都会触发redo log thread将日志缓冲中的数据写入文件，并flush到磁盘。该设置下是最安全的模式。保证数据库在主机断电，OS　crash下不会丢失任何已提交的数据。
• 2的含义:每次事务提交时，都会把redo log buffer的数据写入redo log 文件，可是不会同时刷新到磁盘。

三种模式下：

0性能最好，可是不安全，MySQL进程一旦崩溃会致使丢失一秒的数据。

1是安生性最高，但数据库性能最慢。

2是介于二者之间。

（2）master thread:每秒进行刷新

（3）redo log buffer:使用超过一半的时候会触发刷新。

 

2.binlog

DML语句既会写red log 文件，也会写binlog文件。功能主要用于备份恢复和主从复制。

从binlog cache刷新到磁盘的binlog文件中，须要经过sync_binlog参数来决定。

a.sync_binlog=0,当事务提交以后，MySQL不作fsync之类的磁盘同步指令刷新binlog_cache中的信息来到磁盘，而让Filesystem自行决定何时来作同步，或都cache满了以后才同步到磁盘。

b.sync_binlog=N,每进行N次事务提交以后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

 

++++++++++++++++++++++++++++++++++red log和binlog区别++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

两都都是记录了对数据真实的修改的语句。同时有如下区别：

1.记录内容的不一样。

binlog是逻辑日志，记录全部数据的改变信息。

red log记录的是物理日志，记录全部InnoDB表数据的变化。

 

2.记录内容的时间不一样。

binlog 记录commit完毕以后的DML和DDLSQL语句。

red log记录事务发起以后的DML和DDL SQL语句。

3.文件使用方式的不一样。

binlog不是循环使用，在写满或者实例重启以后，会生成新的binlog文件。

red log是循环使用，最后一个文件写满以后，会从新写第一个文件。

 

4.做用不一样。

binlog能够做为恢复数据使用，主从复制搭建。

red log做为异常宕机中都介质故障后的数据恢复使用。

 

有如下关联：

在主从环境中，从库须要经过二进制日志来应用主库提交的事务，但若是主库red log已经提交而二进制日志没有保持一致，则会形成从库数据丢失，主从数据不一致的状况，见如下分析：

MySQL两阶段提交过程：

a.准备阶段（transaction prepare）:事务SQL语句先写入redo log buffer,而后作一个事务准备标记，再将log buffer中的数据刷新到redo log.

b.提交阶段(commit):将事务产生的binlog写入文件，刷入磁盘。

再在redo log中作一个事务提交的标记，并把binlog写成功的标记也一并写入red log文件。

结合如下两场景分析两阶段如何保持数据库的一致性:

Sense one:

准备阶段，redo log刷新到磁盘了，可是binlog写盘前发生了MySQL实例crash,这是会发生怎么的操做呢？

即便redo log写盘成功了，但因为binlog未写入成功，咱们须要执行回滚操做来保证数据的一致性。

 

Sense two:

提交阶段，binlog写盘成功了，此时MySQL实例发生crash,此时binlog已经确保写成功了，咱们在重启实例进行恢复时，只须要让redo log重作一次就能够了。

总结一下：

其实只要binlog写入完成，则在主从复制环境中，都会正常完成事务。

最后看一下脏页的刷新条件：

（1）重作日志ib_logfile文件写满后，在切换的过程当中会执行checkpoint，会触发脏页的刷新。

（2）经过innodb_max_dirty_pages_pct参数的值控制。该参数是指在buffer pool中dirty page所占的百分比，达到设置的值，就会触发脏页的刷新。

（3）由innodb_adaptive_flushing参数控制。