MySQL's sync-binlog parameters

When MySQL turns on the Bin-log log using Bin-log, by default it is not synchronized with the hard disk every time the write is performed, so that when the server crashes, it can cause the Bin-log final statement to be lost.

Can be adjusted by this parameter, sync_binlog=n, so that the execution of N-times after writing to the hard disk synchronization. 1 is the safest, but also the slowest.

Refer to MySQL website: http://dev.mysql.com/doc/refman/5.5/en/replication-options-binary-log.html#sysvar_sync_binlog

Reference: http://blog.csdn.net/wulantian/article/details/9965905

Sync_binlog=1 or N This makes MySQL synchronize the binary log ' s contents to disk each time it commits a transaction By default, Binlog is not synchronized with the hard disk each time it is written. So if the operating system or machine (not just the MySQL server) crashes, it is possible that the last statement in the Binlog is lost. To prevent this, you can use the Sync_binlog global variable (1 is the safest value, but also the slowest), so that Binlog synchronizes with the hard disk after every n binlog write. Even if Sync_binlog is set to 1, there is a possibility of inconsistency between the table content and the Binlog content when a crash occurs. If you use the InnoDB table, the MySQL server processes the commit statement, which writes the entire transaction to Binlog and commits the transaction to InnoDB. If a crash occurs between two operations, the transaction is InnoDB rolled back, but still exists in Binlog. You can use the--innodb-safe-binlog option to increase the consistency between InnoDB table content and Binlog. (Note:--innodb-safe-binlog is not required in MySQL 5.1; This option is obsolete because of the introduction of XA transaction support), which provides greater security for Binlog (Sync_binlog =1) per transaction and (default is True) InnoDB logs are synchronized with the hard disk, the effect of this option is that after the crash restarts, after rolling back the transaction, the MySQL server cuts the rollback from the Binlog innodb transaction. This ensures that the Binlog feedback innodb the exact data of the table, etc., and keeps the slave server in sync with the primary server (without taking the rollback statement).

MySQL's sync-binlog parameters