MySQL的binlog

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格式比较合适。