上图展示的是 MySQL 的主从切换流程。在 State-1 中,客户端的读写都直接访问节点 A,而节点 B 是 A 的备库,只是将 A 的更新都同步过来,到本地执行。这样可以保持节点 B 和 A 的数据是相同的。当需要切换的时候,就切成状态 2。这时候客户端读写访问的都是节点 B,而节点 A 是 B 的从库。
在主从架构下,建议把从库设置为 Read-Only 模式,这样做有以下几个考虑:
可以通过命令来查看当前 MySQL 实例的 Read-Only 状态:
show global variables like 'read_only';
开启当前实例的 Read-Only 状态:
set global read_only=1;
Read-Only 模式对超级权限用户 (super) 是无效的,而用于同步更新的线程,就拥有超级权限。因此,从库可以正常同步主库的数据。
当 Master 收到一条客户端的更新操作后,其大致的执行流程如下:
从上述主从同步的流程看,binlog 是至关重要的。实际上,MySQL 几乎所有的高可用架构,都直接依赖于 binlog。
binlog 有几种格式,可以通过命令查看:
show variables like '%binlog_format%';
所谓主从同步延迟,就是同一个事务,在备库执行完成的时间和主库执行完成的时间之间的差值,也就是上面的 T3-T1。 可以在 Slave 上执行 show slave status 命令,它的返回结果里面会显示 seconds_behind_master,用于表示当前 Slave 的数据延迟了多少秒。 需要说明的是,在网络正常的时候,日志从 Master 传给 Slave 所需的时间是很短的,即 T2-T1 的值是非常小的。也就是说,网络正常情况下,主从延迟的主要来源是 Slave 接收完 binlog 和执行完这个事务之间的时间差。 所以说,主从同步延迟最直接的表现是,Slave 消费中转日志(relay log)的速度,比 Master 生产 binlog 的速度要慢。下面我们来分析下,主从同步延迟的产生原因有哪些。
五. 主从切换策略 由于主从同步延迟的存在,所以在主从切换的时候,就相应的有不同的策略。
可以看到,这个切换流程中是有不可用时间的。因为在步骤 2 之后,Master 和 Slave 都处于 Read-Only 状态,也就是说这时系统处于不可写状态,直到步骤 5 完成后才能恢复。 在这个不可用状态中,比较耗费时间的是步骤 3,可能需要耗费好几秒的时间。这也是为什么需要在步骤 1 先做判断,确保 seconds_behind_master 的值足够小。 这种方式为了保证主从数据的一致性,导致数据库可能出现一段不可写的时间,称为可靠性优先策略。
可用性优先策略可能会导致数据不一致。因此,大多数情况下,都建议你使用可靠性优先策略。毕竟对数据服务来说的话,数据的可靠性一般还是要优于可用性的。