內存刷新機制

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參數控制。