binlog的作用及與redo log的區別
區別
-
二進位制日誌(bin log)會記錄所有與MySQL資料庫有關的日誌記錄，包括InnoDB、MyISAM、Heap等其他儲存引擎的日誌。而InnoDB儲存引擎的重做日誌只記錄有關該儲存引擎本身的事務日誌。
-
其次，記錄的內容不同，無論使用者將二進位制日誌檔案記錄的格式設為STATEMENT還是ROW，又或者是MIXED，其記錄的都是關於一個事務的具體操作內容，即該日誌是邏輯日誌。而InnoDB儲存引擎的重做日誌檔案記錄的是關於每個頁（Page）的更改的物理情況。
-
此外，寫入的時間也不同，二進位制日誌檔案僅在事務提交前進行提交，即只寫磁碟一次，不論這時該事務多大。而在事務進行的過程中，卻不斷有重做日誌條目（redo entry）被寫入到重做日誌檔案中。
作用
- 恢復（recovery）：某些資料的恢復需要二進位制日誌，例如，在一個數據庫全備檔案恢復後，使用者可以通過二進位制日誌進行point-in-time的恢復。
- 複製（replication）：其原理與恢復類似，通過複製和執行二進位制日誌使一臺遠端的MySQL資料庫（一般稱為slave或standby）與一臺MySQL資料庫（一般稱為master或primary）進行實時同步。
- 審計（audit）：使用者可以通過二進位制日誌中的資訊來進行審計，判斷是否有對資料庫進行注入的攻擊。
以下配置檔案的引數影響著二進位制日誌記錄的資訊和行為：
sync_binlog
在預設情況下，二進位制日誌並不是在每次寫的時候同步到磁碟（使用者可以理解為緩衝寫）。因此，當資料庫所在作業系統發生宕機時，可能會有最後一部分資料沒有寫入二進位制日誌檔案中，這會給恢復和複製帶來問題。引數sync_binlog=[N]表示每寫緩衝多少次就同步到磁碟。如果將N設為1，即sync_binlog=1表示採用同步寫磁碟的方式來寫二進位制日誌，這時寫操作不使用作業系統的緩衝來寫二進位制日誌。sync_binlog的預設值為0，如果使用InnoDB儲存引擎進行復制，並且想得到最大的高可用性，建議將該值設為ON。不過該值為ON時，確實會對資料庫的IO系統帶來一定的影響。
但是，即使將sync_binlog設為1，還是會有一種情況導致問題的發生。當使用InnoDB儲存引擎時，在一個事務發出COMMIT動作之前，由於sync_binlog為1，因此會將二進位制日誌立即寫入磁碟。如果這時已經寫入了二進位制日誌，但是提交還沒有發生，並且此時發生了宕機，那麼在MySQL資料庫下次啟動時，由於COMMIT操作並沒有發生，這個事務會被回滾掉。但是二進位制日誌已經記錄了該事務資訊，不能被回滾。這個問題可以通過將引數innodb_support_xa設為1來解決，雖然innodb_support_xa與XA事務有關，但它同時也確保了二進位制日誌和InnoDB儲存引擎資料檔案的同步。
max_binlog_size
指定了單個二進位制日誌檔案的最大值，如果超過該值，則產生新的二進位制日誌檔案，字尾名+1，並記錄到.index檔案。從MySQL 5.0開始的預設值為1073 741824，代表1 G（在之前版本中max_binlog_size預設大小為1.1G）
binlog_cache_size
當使用事務的表儲存引擎（如InnoDB儲存引擎）時，所有未提交（uncommitted）的二進位制日誌會被記錄到一個快取中去，等該事務提交（committed）時直接將緩衝中的二進位制日誌寫入二進位制日誌檔案，而該緩衝的大小由binlog_cache_size決定，預設大小為32K.如果如果超過此大小，會被定入臨時檔案。
可以通過show variables like 'binlog_cache_use'檢視緩衝使用次數，通過show global status like 'binlog_cache_disk_use'\G檢視使用臨時檔案次數.
binlog-do-db與binlog-ignore-db
引數binlog-do-db和binlog-ignore-db表示需要寫入或忽略寫入哪些庫的日誌。預設為空，表示需要同步所有庫的日誌到二進位制日誌。
log-slave-update
如果當前資料庫是複製中的slave角色，則它不會將從master取得並執行的二進位制日誌寫入自己的二進位制日誌檔案中去。如果需要寫入，要設定log-slave-update。如果需要搭建master=>slave=>slave架構的複製，則必須設定該引數。
binlog_format
引數可設的值有STATEMENT、ROW和MIXED。
binlog_format是動態引數，因此可以在資料庫執行環境下進行更改
將引數binlog_format設定為ROW，會對磁碟空間要求有一定的增加。這是因為這時MySQL資料庫不再將邏輯的SQL操作記錄到二進位制日誌中，而是記錄對於每行的更改（如果修改10萬行資料，那麼也會記錄10萬行的變動）。而由於複製是採用傳輸二進位制日誌方式實現的，因此複製的網路開銷也有所增加。
（1）STATEMENT格式和之前的MySQL版本一樣，二進位制日誌檔案記錄的是日誌的邏輯SQL語句。
（2）在ROW格式下，二進位制日誌記錄的不再是簡單的SQL語句了，而是記錄表的行更改情況。基於ROW格式的複製類似於Oracle的物理Standby（當然，還是有些區別）。同時，對上述提及的Statement格式下複製的問題予以解決。從MySQL 5.1版本開始，如果設定了binlog_format為ROW，可以將InnoDB的事務隔離基本設為READ COMMITTED，以獲得更好的併發性。
（3）在MIXED格式下，MySQL預設採用STATEMENT格式進行二進位制日誌檔案的記錄，但是在一些情況下會使用ROW格式，可能的情況有：
1）表的儲存引擎為NDB，這時對錶的DML操作都會以ROW格式記錄。
2）使用了UUID（）、USER（）、CURRENT_USER（）、FOUND_ROWS（）、ROW_COUNT（）等不確定函式。
3）使用了INSERT DELAY語句。
4）使用了使用者定義函式（UDF）。
5）使用了臨時表（temporary table）