MySQL是怎么保证主备一致的？

MySQL是怎么保证主备一致的？

binlog 可以用来归档，也可以用来做主备同步，但它的内容是什么样的呢？为什么备库执行了 binlog 就可以跟主库保持一致了呢

主库接收到客户端的更新请求后，执行内部事务的更新逻辑，同时写 binlog。
备库 B 跟主库 A 之间维持了一个长连接。主库 A 内部有一个线程，专门用于服务备库 B 的这个长连接。一个事务日志同步的完整过程是这样的：

1.在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、密码，以及要从哪个位置开始请求 binlog，这个位置包含文件名和日志偏移量。

2.在备库 B 上执行 start slave 命令，这时候备库会启动两个线程，就是图中的 io_thread 和 sql_thread。其中 io_thread 负责与主库建立连接。

3.主库 A 校验完用户名、密码后，开始按照备库 B 传过来的位置，从本地读取 binlog，发给 B。

4.备库 B 拿到 binlog 后，写到本地文件，称为中转日志（relay log）。

5.sql_thread 读取中转日志，解析出日志里的命令，并执行。

binlog 里面到底是什么内容，为什么备库拿过去可以直接执行。
三种格式：statement、row、mixed

为什么会有 mixed 这种 binlog 格式的存在场景？

因为有些 statement 格式的 binlog 可能会导致主备不一致，所以要使用 row 格式。
但 row 格式的缺点是，很占空间。
所以，就有了 mixed 格式的 binlog。mixed 格式的意思是，MySQL 自己会判断这条 SQL 语句是否可能引起主备不一致，如果有可能，就用 row 格式，否则就用 statement 格式。

MySQL主备同步相关：

数据同步有关的时间点主要包括以下三个：
1.主库 A 执行完成一个事务，写入 binlog，我们把这个时刻记为 T1;
2.之后传给备库 B，我们把备库 B 接收完这个 binlog 的时刻记为 T2;
3.备库 B 执行完成这个事务，我们把这个时刻记为 T3。
主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是 T3-T1。

主备库机器的系统时间设置不一致，会不会导致主备延迟的值不准？
不会的。因为，备库连接到主库的时候，会通过执行 SELECT UNIX_TIMESTAMP() 函数来获得当前主库的系统时间。如果这时候发现主库的系统时间与自己不一致，备库在执行 seconds_behind_master 计算的时候会自动扣掉这个差值。

主备延迟的来源
首先，有些部署条件下，备库所在机器的性能要比主库所在的机器性能差。
第二种备库的压力大。
第三种大事务。