mysql数据库对binlog日志的处理_数据库知识

　　Binlog是mysql以二进制形式打印的日志，它默认不加密，不压缩。每个正常的binlog文件头部，有4个字节的标记，值为0xfe 0x62 0x69 0x6e。LOG_EVENT是binlog里的单位，即正常情况下binlog按照逐LOG_EVENT的形式增长。除去头部的标记，binlog就是一个LOG_EVENT的序列。每个LOG_EVENT都独立单元，没有互相引用的关系，它也有自己的二进制头部，主要是记录了时间戳、类型标记等描述信息。

　　Mysql把磁盘操作的实现封装在IO_CACHE结构里，这也方便了我们对binlog的研究和描述，后文如果没有特别说明，读写binlog与读写IO_CACHE的含义相同。为了解mysql写入binlog的过程，可以找一个sql语句的处理过程进行跟踪。以update为例，在最简单的情况下，mysql会先调用为存储引擎开放的接口ha_update_row，然而执行binlog_query对binlog进行写操作。

　　这样处理的原因是，在主从备份的场景下，如果主库先写入binlog成功、在执行update的过程中crash，从库有可能执行update成功，此时主库重启之后，与从库的数据不一致。如果update操作发生在事务性的表上，在写入binlog之后会执行开放接口ha_autocommit_or_rollback，由存储引擎判断操作结果。

　　在主从备份的场景下，主库相当于server，从库相当于client，双方采用tcp短连接。从库发出读取日志的请求，主库接收请求、读取本地binlog、然后发送给从库。从库接收日志，进行简单校验后写本地日志，称为relay log。此处从库的流程专门由一个线程负责，称为同步io线程。从库还有一个线程，称为同步sql线程。它的行为是，定期读取relay log，解析并执行同步过来的sql语句。

　　下面回答几个问题：

　　1.binlog的格式？

　　二进制顺序存储，不加密，不压缩。

　　2.binlog使用WAL吗？

　　No。

　　3.主库发送binlog，是使用内存里的copy吗？

　　无法确定，很有可能是先从磁盘上读一份，然后发送。

　　4.relaylog使用WAL吗？

　　Yes。从库接收到日志后，会先写relay log。

　　5.binlog和relaylog的SQL是否一致？

　　在网络传输正确性可靠的前提下，yes。

　　提一个问题：既然binlog不使用WAL，那么在主从场景下，mysql异常之后，主库和从库是否会不一致呢？

　　之前有个问题一直没弄明白：既然mysql是先做数据操作、再写binlog，如果写binlog的时候失败，mysql又crash，数据怎么办？

　　答案是由存储引擎决定数据。可以把mysql和它的存储引擎分开看，因为mysql只是一个框架，而不是一个实现。binlog是mysql自己的日志，而事务是由存储引擎本身保证的。

　　以update为例，mysql做的事情简单分为：

　　1. 修改数据update。

　　2. 写binlog。

　　3. 如果当前处理的表是一个事务性的表，则commit或rollback。

　　注意此处的update和commit/rollback都由存储引擎实现，mysql只是站在逻辑的高度上理解这些操作。
　　
　　对于事务型的引擎innodb，它本身有日志保证数据的一致性。在innodb的实现中，update修改数据之前，会新建一个事务，并建立一个回滚点。而在innodb提供的commit/rollback接口会提交/回滚事务。

　　因此对innodb而言，每条SQL语句的事务，其实包含了binlog的写操作。然而即使是这样，innodb仍然无法保证binlog和数据的一致性，因为innodb在写commit成功后crash，回滚操作不会回滚binlog。按照手册上的说法，把--innodb-support-xa设置为1，同时保证sync_binlog=1，才能保证innodb的binlog和数据一致。

　　对于非事务型的引擎myisam，没有commit/rollback的机会，因此在异常情况下，数据会和binlog不一致。