如下图展示的是基本的主备切换流程：
在状态1中，主库是a，备库是b，所以客户端的读写都直接方法节点a。由于节点b是节点a的备库，所以备库b只是将a的更新都同步过来，本地执行，这样可以保证节点b和节点a的数据一致性。
如果发生主备切换，就会从状态1变成状态2，节点a成为备库，节点b成为主库。
在状态1中，虽然节点b没有被客户端直接方法，但是还是建议将节点b（备库）设置成只读（readonly）模式，主要有以下几个理由：
- 避免某些服务访问了备库，造成误操作；
- 防止切换逻辑有bug，比如切换过程中出现双写，造成主备不一致；
- 可以用readonly状态，来判断节点的角色；
注意：readonly对于超级管理员是无效的，而用于同步更新的线程，就拥有超级权限，所以是可以修改备库的。
接下来我们看下节点a到节点b的流程图：
实际上备库b和主库a之间维持了个长连接，主库a中有一个线程（dump_thread），专门用于服务和备库b的长连接。日志同步的完整过程如下：
- 在备库b上通过change master命令，设置主库a的相关信息，以及要从哪个位置开始请求binlog；
- 在备库b上执行start slave命令，备库会启动两个线程，即io_thread和sql_thread，其中io_thread负责与主库通信；
- 主库a校验完信息后，根据备库b转过来的位置，本地读取binlog，传递给b；
- 备库拿到binlog后，写到本地文件，称为中转日志（relay log）；
- sql_thread读取中转日志，解析出命令并执行；
binlog的格式实际上由两种格式，一种是statement，一种是row。此外还有一种mixed格式，实际上是前两种的混合。
为了方便解释几种日志格式的区别，我们创建一个表并写入些数据。
mysql> create table t(
id int(11) not null,
a int(11) default null,
t_modified timestamp not null default current_timestamp,
primary key (id),
key a(a),
key t_modified (t_modified)
)engine=innodb;
insert into t values(1,1,'2018-11-13')
insert into t values(2,2,'2018-11-12')
insert into t values(3,3,'2018-11-11')
insert into t values(4,4,'2018-11-10')
insert into t values(5,5,'2018-11-09')
然后，我们对于这个表执行delete语句：
mysql>delete from t /*comment*/ where a>=4 and t_modified <='2018-11-10' limit 1;
我们可以使用下面的命令来查看binlog中的内容：
mysql> show binlog events in 'master.000001'
可以看到，当binlog_format=statement时，binlog里面记录的就是sql原文：
为了比较statment和row的区别，我们看下这条delete语句的执行图：
从图上可以看到，运行过程中产生了一个warnings，原因是binlog设置的格式时statement，并且语句中有limit，所以时unsafe的。那为什么说是unsafe呢？
- 如果delete语句使用的是索引a，那么会根据索引a找到第一个满足条件的行，也就是a=4这一行。
- 如何delete语句使用的是索引t_modified，那么删除的就是a=5这一行。
所以使用statement可能会造成主备不一致的情况。如果在主库和备库中执行这条sql语句，走的索引不一样，就会出现数据不一致性。
我们接下来再看binlog_format=row的情况，下面是binlog中的内容：
从图上可以看到，row格式的binlog没有写sql语句的原文，而是替换成了两个event：
- table_map event:说明要操作的表是test库的表t；
- delete_rows event：定义删除哪一行
上面实际上是没有完全显示信息的，可以借助mysqlbinlog工具查看详细信息：
所以，当binlog_format=row时，binlog记录了真实删除行的主键id，这样即使在备库中，也是删除这一行，不会出现主备不一致的情况。
从上面的描述中，我们可以很清楚地看到statement和row格式的优缺点：
- statement：格式节省空间，只需要记录sql语句。但是可能会出现主备不一致的情况；
- row：不会出现主备不一致的情况。但是格式十分消耗空间，需要记录所有修改的行。
而 mixed格式的意思是，mysql会自己判断这条sql语句是否可能引起主备不一致，如果有可能，就用row格式，否则就用statement格式。
所以线上的场景，设置为statement格式肯定是不合理的，至少要设置成mixed格式。
实际上，现在越来越多都是使用row格式，其中一个好处就是恢复数据：
- 当执行delete语句后，发现误删了，直接将binlog中的信息，转换成insert语句插入即可
- 当执行insert语句后，发现错误插入了，直接将binlog中的信息，转换成delete语句插入即可
- 如果执行的是update语句，binlog会记录修改前后的信息，方面恢复
刚才介绍的是m-s结构，现在用的比较多的是双m结构，如下图：
这个和m-s结构的区别在于，节点a和节点b之间互为主备关系。这种架构有个问题：当节点a更新了数据，写入binlog_a,然后传给节点b，节点b也会执行更新，写入binlog_b。然后由于节点b更新了，节点a又会去执行节点b的更新，就造成一个死循环的情况。
为了避免这种情况，mysql在binlog中记录了这个命令第一次执行时所在实例的server id：
- 规定两个库的server id必须不同，如果相同，不能互为主备；
- 一个备库接到binlog进行重放的时候，生成与原binlog的server id相同的新binlog；
- 每个库在收到从自己的主库发过来的日志后，先判断server id，如果和自己相同，说明时自己第一次生成的，就直接丢弃这个日志。