redolog和binlog的寫入機制

binlog的寫入機制

**binlog 的寫入邏輯**：事務執行過程中，先把日志寫到 binlog cache，事務送出的時候，再把 binlog cache 寫到 binlog 檔案中

**binlog寫入的三個階段**：binlog cache  （write） 檔案系統的page cache  (fsync) 磁盤

write 和 fsync 的時機，是由參數 sync_binlog 控制的：
- sync_binlog=0 的時候，表示每次送出事務都隻 write，不 fsync；
- sync_binlog=1 的時候，表示每次送出事務都會執行 fsync；
- sync_binlog=N(N>1) 的時候，表示每次送出事務都 write，但累積 N 個事務後才 fsync。

**結論**:一般不建議将這個參數設成 0，比較常見的是将其設定為 100~1000 中的某個數值。如果設定成0，主動重新開機丢失的資料不可控制。設定成1，效率低下，設定成N(N>1)，則主機重新開機，造成最多N個事務的binlog日志丢失，但是性能高，丢失資料量可控。
           

redolog寫入機制

存儲狀态

• 存在 redo log buffer 中，實體上是在 MySQL 程序記憶體中；
• 寫到磁盤 (write)，但是沒有持久化（fsync)，實體上是在檔案系統的 page cache 裡面；
• 持久化到磁盤，對應的是 hard disk。

redo log 的寫入政策,InnoDB 提供了 innodb_flush_log_at_trx_commit 參數，它有三種可能取值：

• 0:表示每次事務送出時都隻是把 redo log 留在 redo log buffer 中;
• 1:表示每次事務送出時都将 redo log 直接持久化到磁盤；
• 2:表示每次事務送出時都隻是把 redo log 寫到 page cache。

InnoDB 有一個背景線程，每隔 1 秒，就會把 redo log buffer 中的日志，調用 write 寫到檔案系統的 page cache，然後調用 fsync 持久化到磁盤。

結論：一般建議設定成2。如果設定成0，則mysql程序重新開機時，會丢失資料，如果設定成1，則每次都刷磁盤，性能太差。設定成2，隻會在主機重新開機才會丢失資料，安全系數比0要高，因為是寫入資料到檔案系統的page cache，是以性能也很高，和設定成0差不多。

redolog和binlog總的結論：

如果你的 MySQL 現在出現了性能瓶頸，而且瓶頸在 IO 上，可以通過哪些方法來提升性能呢？

1. 設定 binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 參數，減少 binlog 的寫盤次數。這個方法是基于“額外的故意等待”來實作的，是以可能會增加語句的響應時間，但沒有丢失資料的風險；
2. 将 sync_binlog 設定為大于 1 的值（比較常見是 100~1000）。這樣做的風險是，主機掉電時會丢 binlog 日志；
3. 将 innodb_flush_log_at_trx_commit 設定為 2。這樣做的風險是，主機掉電的時候會丢資料。