MySQ的二进制日志记录了所有的DDL和DML(除了数据查询语句)语句，以
事件形式
记录，MySQL的二进制日志是事务安全型的。
MySQL的二进制日志两个最重要的使用场景：
1.MySQL Replication在 Master端开启binlog , Master把它的二进制日志传递给slaves,保证master-slave数据一致性
2.数据恢复 通过使用mysqlbinlog工具来恢复数据
二进制包括两类文件：二进制日志索引文件(文件名后缀为.index)用来记录所有的二进制文件、二进制日志文件(文件后缀名为.00000*)记录数据库所有的DDL和DML(除了数据查询语句)语句事件。
binlog的开启：
在/etc/my.cnf配置文件中的[mysqld]模块 添加log-bin=mysql-bin
这个表示binlog的前缀是mysql-bin,以后生成的日志文件就是mysql-bin.******，按顺序编号，每次重启mysql或者单个文件的大小达到阈值都会新生成一个文件。
binlog的三种格式分类：
在配置文件可以配置 binlog_format= statement | row | mixed
1）statement: 语句级，binlog会记录每次执行写操作的
语句
相对row模式节省空间，但可能产生数据不一致性，比如 update tt set create_date=now( )，如果用binlog日志进行恢复，就会由于执行时间不同导致产生的数据不同
优点：节省空间 缺点： 有可能造成数据不一致
2) row: 行级 binlog会记录每次操作后每行记录的
变化
优点：保持数据的绝对一致性 因为不管sql是什么，引用了什么函数，它只记录执行后的效果
缺点： 占用空间大 比如 update tt set salary = 8000 where age > 20
这个条件过滤出来的数据可能非常多，row会记录每一行的数据变化
3）mixed statement的升级版 一定程度上解决了因为一些情况造成的statement模式数据不一致问题
默认还是statement，在某些情况下 比如
当函数中包含UUID( )时，包含AUTO_INCREMENT字段的表被更新时，执行 insert delayed语句时，用UDF时， 会按照ROW的方式进行处理。
优点：节省空间，同时一定程度上兼顾了数据一致性
缺点：还有极个别情况依旧会造成数据不一致，另外statement和mixed对于需要对binlog的监控的情况都不方便。
Canal想做监控分析，选择row格式比较合适。