MySQL binlog是二进制格式的日志文件,用于记录MySQL内部对数据库的修改操作,主要作用为数据库的主从复制及增量恢复
从 MySQL 5.1.12 开始,可以用以下三种模式来实现:
相应地,binlog的格式也有三种:STATEMENT,ROW,MIXED
MySQL 5.0版本前,因为binlog模式只有statement,为了避免主从复制不一致,只能使用RR隔离模式配合。MySQL 5.1+ 可以使用RC + Row进行binlog主从复制,在绝大多数情况无需加间隙锁,以提获得更好的并发性,且可保证主从复制一致性
Oracle及sqlserver默认使用RC隔离级别
大部分互联网公司使用RC + Row进行binlog主从复制
此段文章修改自[MySQL 实战45讲——MySQL是怎么保证主备一致的?],详细见原文

在状态 1 中,客户端的读写都直接访问节点 A,而节点 B 是 A 的备库,只是将 A 的更新都同步过来,到本地执行。这样可以保持节点 B 和 A 的数据是相同的。
当需要切换的时候,就切成状态 2。这时候客户端读写访问的都是节点 B,而节点 A 是 B 的备库。
在状态 1 中,虽然节点 B 没有被直接访问,但是我依然建议你把节点 B(也就是备库)设置成只读(readonly)模式。这样做,有以下几个考虑:
readonly 设置对超级 (super) 权限用户是无效的,而用于同步更新的线程,就拥有超级权限,故不影响主从同步
接下来,我们再看看节点 A 到 B 这条线的内部流程。下图中画出的就是一个 update 语句在节点 A 执行,然后同步到节点 B 的完整流程图。

备库 B 跟主库 A 之间维持了一个长连接。主库 A 内部有一个线程,专门用于服务备库 B 的这个长连接。一个事务日志同步的完整过程是这样的:
change master命令,设置主库 A 的 IP、端口、用户名、密码,以及要从哪个位置开始请求 binlog,这个位置包含文件名和日志偏移量。start slave命令,这时候备库会启动两个线程,就是图中的io_thread和sql_thread。其中io_thread负责与主库建立连接。relay log)。sql_thread读取中转日志,解析出日志里的命令,并执行。后来由于多线程复制方案的引入,
sql_thread演化成为了多个线程
参考资料: