sync_binlog
Controls how often the MySQL server synchronizes the binary log to disk.
控制MySQL服务器同步二进制文件到磁盘的频率。
sync_binlog参数：
0 ：存储引擎不进行binlog的刷新到磁盘，而由操作系统的文件系统控制缓存刷新。
1：每提交一次事务，存储引擎调用文件系统的sync操作进行一次缓存的刷新，这种方式最安全，但性能较低。
n：当提交的日志组=n时，存储引擎调用文件系统的sync操作进行一次缓存的刷新。
sync_binlog=0或sync_binlog大于1，事务被提交，而尚未同步到磁盘。因此，在电源故障或操作系统崩溃时有可能服务器已承诺尚未同步一些事务到二进制日志。因此它是不可能执行例行程序恢复这些事务，他们将会丢失二进制日志。
innodb_flush_log_at_trx_commit
控制提交操作的严格 ACID 合规性与重新安排并批量完成提交相关 I/O 操作时可能获得的更高性能之间的平衡 Controls the balance between strict ACID compliance for commit operations and higher performance that is possible when commit-related I/O operations are rearranged and done in batches。
- 0：日志每秒写入并刷新到磁盘一次
- 1：每次事务提交都会把日志缓存区的数据写入日志文件中，并且刷新到磁盘中。该模式为系统默认
- 2：日志在每次事务提交后写入，并每秒刷新到磁盘一次
其中0和2有点容易混淆，特意查了下谷歌。
innodb_flush_log_at_trx_commit和sync_binlog 都为 1 时是最安全的，在mysqld 服务崩溃或者服务器主机crash的情况下，binary log 只有可能丢失最多一个语句或者一个事务。但是鱼与熊掌不可兼得，双1，1 会导致频繁的io操作，因此该模式也是最慢的一种方式。
为什么有些操作系统和硬盘可以这么普信？
