Mysql 支持互为主从，主库通过binlog 将执行的语句传给从库，具体的执行机构：
主库上的 dump thread，主库上的 binlog 只有在写入到硬盘之后才能通过 dump thread 传出
从库上的 IO thread，接收主库的 dump thread 发过来的 binlog 并且生成 relay log，这么一层中间日志
从库上的 sql thread，执行 relay log 中的语句
值得注意的是 ，从库 会 向主库 验证身份，并且告知 主库 binlog 需要开始 读取的位置， 主库才会通过 dump thread 发送给 io thread
各个从库 请求的位置不一样，得到的最终数据可能不一样，连接上之后，主库会一直传 binlog 内容给 从库，直到没有可以传的内容为止。至此之后，如果再有语句执行，写入 binlog 到 磁盘。
则主库 再通过 dump thread 传给 io thread
binlog 有 三种格式 ：
1. row 这种格式 记录的是关乎主键的，也就是记录 主键 = x 这一行被修改了什么，如果被修改的是多行，则会记录 主键 = x，主键 = y ... 被修改了什么
2.statement 这种格式 是 单纯记录执行的语句的，但是单纯地记录语句 可能发生不一致的情况，比如主库和从库对于 binlog 的同一条语句选用了 不同索引。
比如 delete * from table where a > x and b < y , 假设 a 和 b 上都有索引，那么可能主库选择 索引 a， 从库选择 索引 b，删除的列可能不完全相同，导致主从不一致
3.mixed 这种格式 是上述两种的混合。当记录的是有歧义的语句时候，会使用 row 格式，否则用 statement 格式。也就是 像 2 那样有歧义的话，就会使用 row 格式，而不是 statement
循环复制问题，前面提到，mysql 支持互为主从，那么 binlog 不会在 互为主从的两个数据库之间循环复制吗？
不会，因为数据库会按照 server id 来判断 binlog 是否能被执行
比如 A库 server id = 1，B库 server id = 2， A 和 B 互为主从，互为主从的 库必须 server id 不同
那么 A库产生的 binlog 上 标有 server id = 1， 传给B库，B库执行后产生 binlog，产生的 binlog 的 server id 和 之前的一样， 也就是1
然后再 传给A库 ， A库判断 server id 和自己一样，不执行，循环中断。