主从异常：MySQL 主从复制数据不一致的异常解决方法

今天来说说 MySQL 主从复制数据不一致的问题，通过几个具体的案例，来向小伙伴们展示 binlog 不同 format 之间的区别。

1. 准备工作

以下配置基于 Docker。

我这里有一张简单的图向大伙展示 MySQL 主从的工作方式：

这里，我们准备两台机器：

• 主机：10.3.50.27:33061
• 从机：10.3.50.27:33062

1.1 主机配置

主机的配置就三个步骤，比较容易：

1. 授权给从机服务器

针对该配置文件，我们做如下修改：

• log-bin：同步的日志路径及文件名，一定注意这个目录要是 MySQL 有权限写入的（我这里是偷懒了，直接放在了下面那个datadir下面）。
• binlog-do-db：要同步的数据库名，当从机连上主机后，只有这里配置的数据库才会被同步，其他的不会被同步。
• server-id: MySQL 在主从环境下的唯一标志符，给个任意数字，注意不能和从机重复。

修改 binlog_format 的值为 STATEMENT，这一点很关键。

配置完成后重启 MySQL 服务端：

再看一眼 binlog_format 设置成功没：

可以看到，没问题。

至此，主机配置完成。

1.2 从机配置

从机的配置也比较简单，我们一步一步来看：

1. 在/etc/my.cnf 添加配置

注意从机这里只需要配置一下 server-id 即可。

注意：如果从机是从主机复制来的，即我们通过复制 CentOS 虚拟机获取了 MySQL 实例 ，此时两个 MySQL 的 uuid 一样（正常安装是不会相同的），这时需要手动修改，修改位置在 /var/lib/mysql/auto.cnf ，注意随便修改这里几个字符即可，但也不可太过于随意，例如修改了 uuid 的长度。

配置完成后，记得重启从机。

2. 使用命令来配置从机

4. 查看 slave 的状态

主要是下面两项值都要为为 YES，则表示配置正确：

按道理，这条记录会同步到 33062 这台从机上：

大家看到，数据确实同步了，但是 uuid 却不一样。

3. 原因分析

我们知道，MySQL 主从同步最主要的依据就是 binlog，master 将自己的 binlog 发给 slave，slave 重放之后获取和 master 一致的数据。

那我们就来看看 master 生成的 binlog 是啥样子。

我们按照事件的方式来看一下 binlog，命令格式如下：

从图中可以看到，记录在 binlog 原文中的日志是：use javaboy_db; insert into user(uuid,name) values(uuid(),'javaboy')。

这句 SQL 将来同步到 slave 之后，slave 照着执行一下，那必然出现执行结果不一致的问题，因为 uuid() 函数每次执行结果都不一样。

现在小伙伴们看明白问题的原因了吧。

4. 问题解决

问题倒也好解决，上篇文章我们说过，我们可以将 binlog_format 设置为 ROW 来解决这个问题。

具体操作步骤如下。

在主机中，修改 /etc/mysql/mysql.conf.d/mysqld.cnf 配置文件，将 binlog_format 改为 ROW，如下：

修改完成后，重启主机，主机重启之后，会产生新的 binlog 文件，所以我们需要重新查看主机的最新状态并重新配置从机，先来看主机，如下：

以此为依据，让从机重新连接主机，在从机上再进行如下操作：

大家看到，在 BEGIN 和 COMMIT 之间，就是我们的数据修改操作。

• Table_map：这一行是说明了接下来要操作 javaboy_db.user 表。
• Write_rows：这一行是说明了要写一行新的数据了。

不过这里看不出啥端倪来，我们借助 mysqlbinlog 工具来看看是否有新的发现。

为了查看 binlog，MySQL 为我们提供了两个官方工具，除了上面的 show binlog events，另一个就是 mysqlbinlog 命令，如下（注意在系统中执行该命令，不是在 MySQL 终端执行该命令）：

这里的内容比较多，我们来看几个比较关键的地方：

• Table_map: javaboy_db.user mapped to number 108：这表示接下来要操作编号为 108 的表，每张表都有一个自己的编号。
• Write_rows: table id 108 flags: STMT_END_F：这个就是具体的添加操作了，向编号为 108 的表中添加一条记录。

接下来那两行，大致上瞅一眼，像是 Base64 转码后的内容，大家感兴趣的可以自行解码看看，解码后有一些是乱码的，但是有一些字符串如 uuid 则没有乱码，我们也能大致猜出来这里存储的内容。

接下来我们看下面记录的 SQL，如下：

这就是日志中记录的内容，可以看到，每个字段上具体的值是啥，都写下来了，这样当然就不会发生数据不一致的情况了。

5. 小结

到此这篇关于MySQL 主从复制数据不一致的解决方法的文章就介绍到这了,更多相关MySQL 主从复制数据不一致内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！