MySQL--參數sync_binlog

Sync_binlog

 

By default, the binary log is not synchronized to disk at each write. So if the operating system or machine (not only the MySQL server) crashes, there is a chance that the last statements of the binary log are lost. To prevent this, use the  sync_binlog system variable to synchronize the binary log to disk after every N commit groups. See Section 5.1.7, 「Server System Variables」. The safest value for  sync_binlog is 1, but this is also the slowest. Even with  sync_binlog set to 1, there is still the chance of inconsistency between the table content and binary log content in case of a crash.

 

默認狀況下，二進制日誌不會在每次寫入的時候刷新到磁盤，因此若是操做系統宕機（不只是mysql服務器），二進制日誌的最後一個語句可能會丟失。

爲了防止這種狀況，使用sync_binlog系統變量在每n此提交組以後將二進制日誌同步到磁盤，最安全的值是1，但這也是最慢的，即便sync_binlog設置爲1，在崩潰的狀況下，表內容和二進制日誌內容之間仍然存在不一致的可能性

 

 

For example, if you are using InnoDB tables and the MySQL server processes a  COMMIT statement, it writes many prepared transactions to the binary log in sequence, synchronizes the binary log, and then commits this transaction into InnoDB. If the server crashes between those two operations, the transaction is rolled back by InnoDB at restart but still exists in the binary log. Such an issue is resolved assuming  --innodb_support_xa is set to 1, the default. Although this option is related to the support of XA transactions in InnoDB, it also ensures that the binary log and InnoDB data files are synchronized. For this option to provide a greater degree of safety, the MySQL server should also be configured to synchronize the binary log and the InnoDB logs to disk before committing the transaction. The InnoDB logs are synchronized by default, and sync_binlog=1 can be used to synchronize the binary log. 

 

例如，若是使用innodb表而且mysql服務器處理commit語句，它會按順序將許多已經準備好的事務寫入二進制、同步二進制日誌，而後將事務提交到innodb。若是服務器在這兩個操做之間宕機，事務會在服務器重啓以後回滾，但仍然存在於二進制日誌中。

將--innodb_support_xa設置爲1（默認值）能夠解決。

雖然這個選項與innodb中對xa事務的支持有關，但它確保了二進制日誌和innodb數據文件同步。爲了提供更高程度的安全性，還應配置mysql服務器在innodb提交事務之間將二進制日誌和日誌同步到磁盤。innodb日誌默認是同步的，並設置且sync_binlog=1能夠用於二進制同步

 

 

 

The effect of this option is that at restart after a crash, after doing a rollback of transactions, the MySQL server scans the latest binary log file to collect transaction xid values and calculate the last valid position in the binary log file. The MySQL server then tells InnoDB to complete any prepared transactions that were successfully written to the to the binary log, and truncates the binary log to the last valid position. This ensures that the binary log reflects the exact data of InnoDB tables, and therefore the slave remains in synchrony with the master because it does not receive a statement which has been rolled back.

 

這個選項的做用是服務器（包括mysql）在宕機重啓時，在執行事務回滾後，mysql服務器掃描最新的二進制日誌文件用以收集事務xid值並計算二進制日誌文件中的最後一個有效位置。mysql通知innodb完成全部已經成功寫入二進制日誌文件的事務，並將二進制日誌截斷到最後一個有效位置。這樣就保證可二進制日誌文件可以真實反映innodb表的數據，由於從庫並不會收到已經回滾的語句，故而從庫依然同主庫保持同步。

 

If the MySQL server discovers at crash recovery that the binary log is shorter than it should have been, it lacks at least one successfully committed InnoDB transaction. This should not happen if sync_binlog=1 and the disk/file system do an actual sync when they are requested to (some do not), so the server prints an error message The binary log file_name is shorter than its expected size. In this case, this binary log is not correct and replication should be restarted from a fresh snapshot of the master's data

 

若是mysql在宕機重啓以後發現二進制日誌比它應有的長度短，那麼它至少缺乏一個成功提交的事務。

若是sync_binlog=1並且文件系統在請求時執行實際同步，就不會發生這種狀況，於是服務器會輸出錯誤消息

The binary log file_name is shorter than its expected size.

在這種狀況下，此二進制日誌不正確，應從主庫的新快照從新啓動複製

 

 

sync_binlog參數

Property	Value
Command-Line Format	--sync-binlog=#
System Variable	sync_binlog
Scope	Global
Dynamic	Yes
Type	integer
Default Value	0
Minimum Value	0
Maximum Value	4294967295

Controls how often the MySQL server synchronizes the binary log to disk.

 

sync_binlog=0: 

    Disables synchronization of the binary log to disk by the MySQL server. Instead, the MySQL server relies on the operating system to flush the binary log to disk from time to time as it does for any other file. This setting provides the best performance, but in the event of a power failure or operating system crash, it is possible that the server has committed transactions that have not been synchronized to the binary log.

 

    不一樣步日誌，mysql依賴操做系統定時將二進制日誌刷新到磁盤，就像對任何其餘文件同樣。

性能最好，可是若是服務器宕機，mysql可能已經提交了還沒有同步到二進制文件中的日誌

 

sync_binlog=1: 

    Enables synchronization of the binary log to disk before transactions are committed. This is the safest setting but can have a negative impact on performance due to the increased number of disk writes. In the event of a power failure or operating system crash, transactions that are missing from the binary log are only in a prepared state. This permits the automatic recovery routine to roll back the transactions, which guarantees that no transaction is lost from the binary log.

 

    每次提交事務時，都同步二進制日誌到磁盤。事務不會有任何丟失，可是性能損耗較大。

 

sync_binlog=N, 

    where N is a value other than 0 or 1: The binary log is synchronized to disk after N binary log commit groups have been collected. In the event of a power failure or operating system crash, it is possible that the server has committed transactions that have not been flushed to the binary log. This setting can have a negative impact on performance due to the increased number of disk writes. A higher value improves performance, but with an increased risk of data loss.

    

    每n次提交後，將二進制日誌同步到磁盤。若是發生宕機，mysql可能已經提交還沒有刷新到二進制日誌的事務。

較高的值可能提升性能，但會提升數據丟失的風險

 

For the greatest possible durability and consistency in a replication setup that uses InnoDB with transactions, use these settings:

• sync_binlog=1.
• innodb_flush_log_at_trx_commit=1.

Caution

Many operating systems and some disk hardware fool the flush-to-disk operation. They may tell  mysqld that the flush has taken place, even though it has not. In this case, the durability of transactions is not guaranteed even with the recommended settings, and in the worst case, a power outage can corrupt InnoDB data. Using a battery-backed disk cache in the SCSI disk controller or in the disk itself speeds up file flushes, and makes the operation safer. You can also try to disable the caching of disk writes in hardware caches.

 

若是有硬件緩存，應禁止