Mysql二进制日志的结构

        二进制日志文件记录了数据库的所有改变，是的任何slave都可以执行同样的更新。通常二进制日志保留了所有更改的记录，可以用于审计的目的，看看数据库中发生了什么；还可用于PITR（即时恢复），即向服务器回放二进制日志，重复执行二进制日志中记录的更新。
        二进制日志仅包含可能改变数据库的语句。请注意，那些尚没有但是可能改变数据库的语句也会被记录下来。注意那些可能带来变化的语句，如DROP TABLE EXITS 或CREATE TABLE IF NOT EXITS，以及那些不匹配任何行的语句，如带有WHERE 条件的DELETE和UPDATE语句。
        SELECT 语句一般不会记录，因为他们不会对数据库作任何改动。然而，什么都有例外。
       服务器上的事务，通常不是一个接一个顺序执行的，而是交错地并行执行。为了防止两个事物之间产生的冲突导致不一致的结果，服务器要确保事务的执行是顺序化的。这样执行的事务结果相同，就像它们是串执行的一样，也就是说，执行顺序是固定的，一个接着一个执行。、
      二进制日志按master上的提交顺序记录事务。虽然事务可能在master上交错执行，但每个事务在二进制日志中的顺序是不变的，取决于事务的提交时间。
      二进制日志并不是一个单独的文件，而是由一系列易于管理的（例如在不影响新日志的情况下移除旧日志）文件组成的。二进制日志包括一组存储世纪内容的二进制日志文件和一个二进制日志索引文件，而二进制索引文件包括所有使用二进制日志文件的文件名，它用来跟踪存在的二进制日志文件，例如下图
    
        真正的事件存储在一系列binlog文件中，文件名类似与host-bin.000001,还有一个binlog索引文件，通常文件名为host-bin.index,用来追踪已有的binlog文件。当前服务器正在写入的binlog文件成为i活动（active）binlog 文件。如果所有salve都与master同步，那么slave也正在读取该文件。分别使用log-bin和log-bin-index选项来控制binlog文件及binlog索引文件的名字。
       索引文件跟踪服务器使用的所有binlog文件。以便必要的时候服务器额嗯正确创建新的binlog文件。索引文件的每一行都包含了一个binlog文件的完整文件名，这个binlog文件是二进制日志的一部分。影响binlog文件的命令，如PURGE BINGE LOGS, RESET MASTER, 以及FLUSH LOGS,也同样影响索引文件，这些命令添加或删除binlog文件会导致索引文件添加或删除行。
      如下图所示，每个binlog文件由若干binlog事件组成，以Format_description事件（格式描述事件）作为文件头，以日志轮换事件作为文件尾。注意如果服务器突然停止或死机，binlog文件末尾可能不是轮换事件。
   Format_description事件包含写binlog服务器信息，以及关于文件状态的关键字信息。如果服务器关闭或重新启动，会创建一个新的binlog文件，同时向其中写入一个新的Format_description事件。这个事件是必需的，因为在服务器关闭和重启期间可能产生更新。例如，如果升级服务器，需要写入新的Format_description事件。

        Format_description事件包含写binlog服务器信息，以及关于文件状态的关键字信息。如果服务器关闭或重新启动，会创建一个新的binlog文件，同时向其中写入一个新的Format_description事件。这个事件是必需的，因为在服务器关闭和重启期间可能产生更新。例如，如果升级服务器，需要写入新的Format_description事件。
     服务器写完binlog文件后，在文件末尾添加一个轮换事件。该事件包含下一个binlog文件的文件名及其开始读取的位置。
    除了Format_description和轮换事件外，binlog文件中的其他事件都被分成组（group）。在事务存储引擎（transsactional storage engine）中，每个组大致对应一个事务；但是对于非事务存储引擎，或不属于事务的语句，如CREATE或ALTER语句，每个语句本生就是一个组。总之，binlog文件中的事件组要么是不属于事务的单个语句，要么是由多条语句组成的事务。
    通常情况下，每个组成要么全都执行，要么全不执行。如果由于某种原因slave在组执行的过程中停机，那么将从该组的起点而不是刚刚执行的语句开始复制。