MySQL提供一个sync_binlog参数来控制数据库的binlog刷到磁盘上去。
| 属性 | 值 |
|---|---|
| 命令行格式 | –sync-binlog=# |
| 系统变量 | sync_binlog |
| 范围 | 全球 |
| 动态 | 是 |
| 类型 | 整数 |
| 默认值 | （> = 5.7.7） 1 |
| 默认值 | （<= 5.7.6） 0 |
| 最小值 | 0 |
| 最大值 | 4294967295 |
控制在将二进制日志同步到磁盘之前要收集的二进制日志提交组的数量。当 sync_binlog=0二进制日志永远不会同步到磁盘，当sync_binlog设置为大于0的值时，此二进制日志落实组的数目会定期同步到磁盘。 sync_binlog=1，所有事务在提交之前都会同步到二进制日志。因此，即使在意外重启的情况下，二进制日志中缺失的任何事务也只处于准备状态。这会导致服务器的自动恢复例程回滚这些事务。这保证了二进制日志中没有事务丢失，并且是最安全的选项。但是，由于磁盘写入次数增加，这可能会对性能产生负面影响。使用更高的值可以提高性能，但会增加数据丢失的风险。
当sync_binlog=0或 sync_binlog大于1时，事务将被提交而未被同步到磁盘。因此，在发生电源故障或操作系统崩溃的情况下，服务器可能会提交一些尚未同步到二进制日志的事务。因此恢复例程不可能恢复这些事务，它们将从二进制日志中丢失。
在MySQL 5.7.7之前，默认值为 sync_binlog0，它配置为不同步到磁盘 - 在这种情况下，服务器依赖于操作系统随时刷新二进制日志的内容，就像任何其他文件一样。MySQL 5.7.7和更高版本使用默认值1，这是最安全的选择，但如上所述可能会影响性能。
虽然可以通过group commit的补丁缓解，但是刷新的频率过高对IO的影响也非常大。对于高并发事务的系统来说，“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。
官方文档：sync_binlog
| Property | Value |
|---|---|
| Command-Line Format | –sync-binlog=# |
| System Variable | sync_binlog |
| Scope | Global |
| Dynamic | Yes |
| Type | integer |
| Default | Value (>= 5.7.7) 1 |
| Default | Value (<= 5.7.6) 0 |
| Minimum | Value 0 |
| Maximum | Value 4294967295 |
Controls the number of binary log commit groups to collect before synchronizing the binary log to disk. When sync_binlog=0, the binary log is never synchronized to disk, and when sync_binlog is set to a value greater than 0 this number of binary log commit groups is periodically synchronized to disk. When sync_binlog=1, all transactions are synchronized to the binary log before they are committed. Therefore, even in the event of an unexpected restart, any transactions that are missing from the binary log are only in prepared state. This causes the server’s automatic recovery routine to roll back those transactions. This guarantees that no transaction is lost from the binary log, and is the safest option. However this can have a negative impact on performance because of an increased number of disk writes. Using a higher value improves performance, but with the increased risk of data loss.
When sync_binlog=0 or sync_binlog is greater than 1, transactions are committed without having been synchronized to disk. Therefore, in the event of a power failure or operating system crash, it is possible that the server has committed some transactions that have not been synchronized to the binary log. Therefore it is impossible for the recovery routine to recover these transactions and they will be lost from the binary log.
Prior to MySQL 5.7.7, the default value of sync_binlog was 0, which configures no synchronizing to disk—in this case, the server relies on the operating system to flush the binary log’s contents from time to time as for any other file. MySQL 5.7.7 and later use a default value of 1, which is the safest choice, but as noted above can impact performance.