但是，我们不打算描述存储引擎的实现细节，也不打算介绍各种存储引擎的优点和缺点。它只描述了MySQL的过程binlog，并澄清几个容易混淆的问题。
binlog MySQL是重要的，它主要体现在其功能。mysql官方文件明确指出binlog启动会增加MySQL 1%的负载，所以在大多数情况下，binlog不会成为性能瓶颈。
binlog是日志是印刷在二进制形式的MySQL，这是默认不加密和不压缩的。每一个正常的binlog文件头为4字节，一个价值0xfe 0x62 0x69 0x6e.log_event是binlog，即单位，正常情况下，binlog生长在log_event.removing的头标志的形式，binlog序列是一个log_event.each log_event有自己独立的单元并没有引用关系。它也有自己的二进制头，主要记录时间戳、类型标签和其他描述性信息。
MySQL是磁盘操作的实施在io_cache结构，这也有利于我们的研究和描述binlog。如果没有特别说明，binlog将阅读和写作io_cache相同的意义。
为了了解MySQL为binlog写作的过程中，你可以跟踪一个SQL语句的过程。要更新为例，在最简单的情况下，MySQL将首先调用接口ha_update_row是开放的存储引擎，但binlog_query binlog执行写操作。这样做的原因是，在主从备份的情况下，如果主库首写binlog崩溃，它是可能执行更新成功从库更新时写的。当主库重新启动，这是从图书馆的数据不一致。如果更新操作发生在事务表，在binlog是书面的，开放的接口ha_autocommit_or_rollback将被执行，其操作结果将由存储引擎判断。
在主从备份的情况下，主库相当于服务器，这是从图书馆客户相当，双方都使用TCP短连接。从图书馆，阅读日志发送请求，主图书馆接收请求，读取本地binlog，发送给图书馆的。日志是接到图书馆，和本地的日志是一个简单的检查后写的，称为中继日志。从图书馆的过程是具体负责一个线程，称为同步IO线程。有从图书馆的螺纹，称为同步SQL线程。其行为是读取中继日志定期，解析执行SQL语句已同步。

回答以下问题：

1。binlog格式
二进制顺序存储，加密，压缩

不2.binlog使用沃尔玛

不
三.主要图书馆送binlog，它是复制的记忆

不确定是否可以先读取磁盘的副本并发送它。

4。relaylog使用沃尔玛

是的。在收到库中的日志后，将首先写入中继日志。

5。binlog和relaylog SQL一致吗

在网络传输可靠性的前提下，是的

问一个问题：
因为binlog不使用沃尔玛，将主、从图书馆与主从情景MySQL异常不一致

以前有一个问题从来没有被理解过：
因为MySQL是做数据操作的第一个，然后写binlog，如果不能写binlog，MySQL崩溃，如何做数据
答案是数据是由存储引擎决定的。
MySQL可以与它的存储引擎分开可见，因为MySQL只是一个框架，而不是一个实现。
binlog是mysql的日志，和交易是保证存储引擎本身。
以更新为例，MySQL所做的只是简单地分为：
1。修改数据更新
2。写binlog
三.如果当前处理的表是事务表，则提交或回滚。
注意，更新和提交回滚都是由存储引擎实现的，而MySQL只是站在逻辑高度来理解这些操作。
InnoDB事务引擎，它本身具有日志以保证数据的一致性。在InnoDB的实施，更新前修改数据，
一个新的交易将建成一个回滚点设置。提交/回滚在InnoDB接口将提交或回滚事务。
因此，InnoDB，事实上每一个SQL语句、事务，包含写操作的binlog。但即便如此，InnoDB仍然不能保证
binlog数据是一致的，因为InnoDB不回滚binlog撞车后成功书面提交。根据手册，
——InnoDB支持XA设置为1和sync_binlog = 1的保证，binlog InnoDB的数据是一致的。

For non transactional engine MyISAM, there is no chance of commit/rollback, so in exceptional cases, the data will be inconsistent with the binlog.
那么新的问题出现了：如何解决这一矛盾的表吗