概述
binlog 是 MySQL 的 Server 层实现的，所有引擎都可用。binlog 存储了完整的逻辑日志。
binlog 三种格式
STATMENT
基于SQL语句的复制(statement-based replication, SBR)，每一条会修改数据的sql语句会记录到binlog中。
优点：不需要记录每一条SQL语句与每行的数据变化，这样子binlog的日志也会比较少，减少了磁盘IO，提高性能。
缺点：在某些情况下会导致master-slave中的数据不一致(如sleep()函数，last_insert_id()，以及user-defined functions(udf)等会出现问题)
ROW
基于行的复制(row-based replication, RBR)：不记录每一条SQL语句的上下文信息，仅需记录哪条数据被修改了，修改成了什么样子了。
优点：不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题
缺点：会产生大量的日志，尤其是alter table的时候会让日志暴涨。
MIXED
混合模式复制(mixed-based replication, MBR)：以上两种模式的混合使用
一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式
怎么知道 binlog 是完整的
一个事务的 binlog 是有完整格式的：
- statement格式： 最后会有 COMMIT；
- row格式：最后会有一个 XID event；
sync_binlog
sync_binlog：是MySQL 的二进制日志（binary log）同步到磁盘的频率。 取值：0-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中的数据强制写入磁盘。
