sync_binlog=1 or N
sync_binlog=0，當事務提交之後，MySQL不做fsync之類的磁碟同步指令重新整理binlog_cache中的資訊到磁碟，而讓Filesystem自行決定什麼時候來做同步，或者cache滿了之後才同步到磁碟。這個是效能最好的。
sync_binlog=1，當每進行1次事務提交之後，MySQL將進行一次fsync之類的磁碟同步指令來將binlog_cache中的資料強制寫入磁碟。
sync_binlog=n，當每進行n次事務提交之後，MySQL將進行一次fsync之類的磁碟同步指令來將binlog_cache中的資料強制寫入磁碟。
如果沒有設定它為1，那麼崩潰後可能導致二進位制日誌沒有同步事務資料，有可能binlog中最後的語句丟失。要想防止這種情況，你可以使用sync_binlog全域性變數(1是最安全的值，但也是最慢的)，使binlog在每N次binlog寫入後與硬碟 同步。即使sync_binlog設定為1,出現崩潰時，也有可能表內容和binlog內容之間存在不一致性。如果使用InnoDB表，MySQL伺服器 處理COMMIT語句，它將整個事務寫入binlog並將事務提交到InnoDB中。如果在兩次操作之間出現崩潰，重啟時，事務被InnoDB回滾，但仍 然存在binlog中。可以用--innodb-safe-binlog選項來增加InnoDB表內容和binlog之間的一致性。(註釋：在MySQL 5.1中不需要--innodb-safe-binlog；由於引入了XA事務支援，該選項作廢了），該選項可以提供更大程度的安全，使每個事務的 binlog(sync_binlog =1)和(預設情況為真)InnoDB日誌與硬碟同步，該選項的效果是崩潰後重啟時，在滾回事務後，MySQL伺服器從binlog剪下回滾的 InnoDB事務。這樣可以確保binlog反饋InnoDB表的確切資料等，並使從伺服器保持與主伺服器保持同步(不接收 回滾的語句)。
大多數情況下，對資料的一致性並沒有很嚴格的要求，所以並不會把 sync_binlog 配置成 1. 為了追求高併發，提升效能，可以設定為 100 或直接用 0。而和 innodb_flush_log_at_trx_commit 一樣，對於支付服務這樣的應用，還是比較推薦 sync_binlog = 1.