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

最新推荐文章于 2023-07-04 09:49:55 发布

sxlxwyr

最新推荐文章于 2023-07-04 09:49:55 发布

阅读量248

点赞数

分类专栏： MySQL

原文链接：https://time.geekbang.org/column/article/76446

版权

48 篇文章 3 订阅

订阅专栏

MySQL主备的基本原理

基本的主备切换流程

readonly设置对超级（super）权限的用户是无效的，用于同步更新的线程，就拥有超级权限。

节点A到B这条线的内部流程：

备库B跟主库A之间维持了一个长连接。主库A内部有一个线程，专门用于服务备库B的这个长连接。一个事务日志同步的完整过程是这样的：

在备库B上通过change master命令，设置主库A的ip、端口、用户名、密码，以及要从哪个位置开始请求binlog，这个位置包含文件名和日志偏移量。
在备库B上执行start slave命令，这时候备库会启动两个线程，就是图中的io_thread和sql_thread。其中io_thread负责与主库建立连接。
主库A校验完用户名、密码后，开始按照备库B传过来的位置，从本地读取binlog，发给B。
备库B拿到binlog后，写到本地文件，称为中转日志（relay log）。
sql_thread读取中转日志，解析除日志里的命令，并执行。

注意：后来由于多线程复制方案的引入，sql_thread演化成了多个线程。

三种格式：

binlog_format=statement的时候，binlog里面记录的就是SQL语句的原文。

可以用show binlog events in 'master.000001';命令看binlog中的内容。

第一行SET @@SESSION.GTID_NEXT='ANONYMOUS'，在此先忽略；
第二行是一个begin，跟第四行的commit对应，表示中间是一个事务；
第三行就是真实执行的语句了。可以看到，在执行delete命令之前，还有一个user 'test'命令，这条命令不是我们主动执行的，而是MySQL根据当前要操作的表所在的数据库，自动添加的，这样可以保证日志传到备库执行的时候，不论当前的工作线程是在哪个库里，都能够正确地更新到test库的表t。 use 'test'命令之后的delete语句，就是我们输入的SQL原文了，可以看到，binlog“忠实”地记录了SQL命令，甚至连注释也一并记录了。
最后一行是一个commit。你可以看到里面写着xid=61（redo log和binlog就是通过xid关联起来的）。

statement格式可能会引起主备不一致。

binlog_format=row格式

和statement相比，前后的begin和commit是一样的，但是,row格式的binlog没有了SQL原文，而是替换成了两个event：Table_map和Delete_rows。

看到详细的SQL，要借助mysqlbinlog工具以及特定命令。mysqlbinlog --vv data/master.000001 --start-position=8900;

当binlog_format使用row格式的时候，binlog里面记录了真实删除行的主键id，这binlog传到备库去的时候，就肯定会删除id=4的行，不会有主备删除不同行的问题。

因为有些statement格式的binlog可能会导致主备不一致，所以要使用row格式。
row格式的缺点是很占空间。比用用一个delete语句删除10万行数据，用statement就是一个SQL语句被记录到binlog中，占用几十个字节的空间。但是如果用row格式的binlog，就要把这10万条记录都写到binlog中。不仅占用空间，写binlog也要耗费IO资源，影响执行速度。
所以，MySQL取了个这种方案，就是mixed格式。意思是，MySQL自己会判断这条SQL语句是否可能引起主备不一致，如果有可能，就用row格式，否则就用statement格式。

实际生产上用的比较多的是双M结构

这样在切换的时候就不用再修改主备关系了。

节点A上更新了一条语句，然后把生成的binlog发给节点B，节点B执行完这条语句后也会生成binlog，如果节点A同时是节点B的备库，相当于又把节点B生成的binlog拿过来执行了一次，然后会不断地循环执行这个更新语句，也就是循环复制了。这怎么办？

按照这个逻辑，如果设置了双M结构，日志流程就会变成这样：

关注