今天的文章来晚了，主要是我一觉起来变黄码了，关键是我还不知道，早上 8.20 到了公司楼下（最近不在深圳），保安要看健康码，当我自信满满的打开粤省事却傻眼了，折腾一早上，闹了个乌龙，绿码总算回来了，真是生活处处有惊喜。。。
书接上回，闲话不表。
今天来说说 MySQL 主从复制数据不一致的问题，通过几个具体的案例，来向小伙伴们展示 binlog 不同 format 之间的区别。
1. 准备工作
以下配置基于 Docker。
我这里有一张简单的图向大伙展示 MySQL 主从的工作方式：
这里，我们准备两台机器：
主机：10.3.50.27:33061从机：10.3.50.27:330621.1 主机配置
主机的配置就三个步骤，比较容易：
1. 授权给从机服务器
GRANTREPLICATIONSLAVEON*.*to’rep1’@’10.3.50.27’identifiedby’123′;FLUSHPRIVILEGES;
??
注意，在 MySQL8 里边，这块有一些变化。MySQL8 中用户创建和授权需要分开，不能像上面那样一步到位，具体方式如下：
CREATEUSER`rep1`@`10.3.50.27`IDENTIFIEDWITHcaching_sha2_passwordBY’javaboy.COM’;GRANTReplicationSlaveON*.*TO`rep1`@`10.3.50.27`;
2. 修改主库配置文件
开启 binlog ，并设置 server-id ，每次修改配置文件后都要重启 MySQL 服务才会生效
开启 binlog 主要是修改 MySQL 的配置文件 mysqld.cnf，该文件在容器的 /etc/mysql/mysql.conf.d 目录下。
针对该配置文件，我们做如下修改：
[mysqld]# 这个参数表示启用 binlog 功能，并指定 binlog 的存储目录log-bin=javaboy_logbin# 设置 binlog_format 格式binlog_format=STATEMENT# 设置一个 binlog 文件的最大字节# 设置最大 100MBmax_binlog_size=104857600# 设置了 binlog 文件的有效期（单位：天）expire_logs_days = 7# binlog 日志只记录指定库的更新（配置主从复制的时候会用到）binlog-do-db=javaboy_db# binlog 日志不记录指定库的更新（配置主从复制的时候会用到）#binlog-ignore-db=javaboy_no_db# 写缓存多少次，刷一次磁盘，默认 0 表示这个操作由操作系统根据自身负载自行决定多久写一次磁盘# 1 表示每一条事务提交都会立即写磁盘，n 则表示 n 个事务提交才会写磁盘sync_binlog=0# 为当前服务取一个唯一的 id（MySQL5.7 开始需要）server-id=1
各项配置的含义松哥已经在注视中说明了。截图如下：
如下图：
log-bin：同步的日志路径及文件名，一定注意这个目录要是 MySQL 有权限写入的（我这里是偷懒了，直接放在了下面那个datadir下面）。binlog-do-db：要同步的数据库名，当从机连上主机后，只有这里配置的数据库才会被同步，其他的不会被同步。server-id: MySQL 在主从环境下的唯一标志符，给个任意数字，注意不能和从机重复。修改 binlog_format 的值为 STATEMENT，这一点很关键。
配置完成后重启 MySQL 服务端：
dockerrestartmysql33061
3. 查看主服务器当前二进制日志名和偏移量
这个操作的目的是为了在从数据库启动后，从这个点开始进行数据的恢复：
showmasterstatus;
再看一眼 binlog_format 设置成功没：
可以看到，没问题。
至此，主机配置完成。
1.2 从机配置
从机的配置也比较简单，我们一步一步来看：
1. 在/etc/my.cnf 添加配置
注意从机这里只需要配置一下 server-id 即可。
注意：如果从机是从主机复制来的，即我们通过复制 CentOS 虚拟机获取了 MySQL 实例 ，此时两个 MySQL 的 uuid 一样（正常安装是不会相同的），这时需要手动修改，修改位置在 /var/lib/mysql/auto.cnf ，注意随便修改这里几个字符即可，但也不可太过于随意，例如修改了 uuid 的长度。
配置完成后，记得重启从机。
2. 使用命令来配置从机
changemastertomaster_host=’10.3.50.27′,master_port=33061,master_user=’rep1′,master_password=’123′,master_log_file=’javaboy_logbin.000001′,master_log_pos=154;
注意，由于 MySQL8 密码插件的问题，这个问题同样会给主从配置带来问题，所以在 MySQL8 配置主从上，上面这行命令需要添加 get_master_public_key=1，完整命令如下：
changemastertomaster_host=’10.3.50.27′,master_port=33061,master_user=’rep1′,master_password=’123′,master_log_file=’javaboy_logbin.000001′,master_log_pos=154,get_master_public_key=1;
3. 启动 slave 进程
startslave;
启动之后查看从机状态：
showslavestatus\G;
4. 查看 slave 的状态
主要是下面两项值都要为为 YES，则表示配置正确：
Slave_IO_Running:YesSlave_SQL_Running:Yes
至此，配置完成，主机创建库，添加数据，从机会自动同步。
如果这两个有一个不为 YES ，表示主从环境搭建失败，此时可以阅读日志，查看出错的原因，再具体问题具体解决。
具体的同步过程如下：
首先在从机 33062 上通过 change master 命令，设置主机 33061 的 IP、端口、用户名、密码，以及要从哪个位置开始请求 binlog（master_log_pos），这个位置包含文件名和日志偏移量。在从机 33061 上执行 start slave 命令，这时候从机会启动两个线程，分别是 io_thread 和 sql_thread。io_thread 负责与主机建立连接。主机 33061 校验完用户名、密码后，开始按照从机 33062 传过来的位置，从本地读取 binlog，发给 33062。从机 33062 拿到 binlog 后，写到本地文件，称为中转日志（relay log）。sql_thread 线程读取中转日志，解析出日志里的命令，并执行。
大致就是这样一个流程。
2. 数据不一致问题
接下来我们创建一个 javaboy_db 的数据库，并在里边创建一个 user 表，user 表的定义如下：
CREATETABLE`user`(`id`int(11)unsignedNOTNULLAUTO_INCREMENT,`uuid`varchar(128)DEFAULTNULL,`name`varchar(64)DEFAULTNULL,PRIMARYKEY(`id`))ENGINE=InnoDBDEFAULTCHARSET=utf8mb4;
接下来我们在主机中向 user 表中插入一条记录，如下：
按道理，这条记录会同步到 33062 这台从机上：
大家看到，数据确实同步了，但是 uuid 却不一样。
3. 原因分析
我们知道，MySQL 主从同步最主要的依据就是 binlog，master 将自己的 binlog 发给 slave，slave 重放之后获取和 master 一致的数据。
那我们就来看看 master 生成的 binlog 是啥样子。
我们按照事件的方式来看一下 binlog，命令格式如下：
showbinlogevents[IN’log_name’][FROMpos][LIMIT[offset,]row_count];
这个表示以事件的方式来查看 binlog，这里涉及到几个参数：
log_name：可以指定要查看的 binlog 日志文件名，如果不指定的话，表示查看最早的 binlog 文件。pos：从哪个 pos 点开始查看，凡是 binlog 记录下来的操作都有一个 pos 点，这个其实就是相当于我们可以指定从哪个操作开始查看日志，如果不指定的话，就是从该 binlog 的开头开始查看。offset：这是是偏移量，不指定默认就是 0。row_count：查看多少行记录，不指定就是查看所有。
查看命令如下（我这里就从 pos 为 154 的位置开始）：
showbinlogeventsIN’javaboy_logbin.000001’FROM154;
查看结果如下（部分）：
这句 SQL 将来同步到 slave 之后，slave 照着执行一下，那必然出现执行结果不一致的问题，因为 uuid() 函数每次执行结果都不一样。
现在小伙伴们看明白问题的原因了吧。
4. 问题解决
问题倒也好解决，上篇文章我们说过，我们可以将 binlog_format 设置为 ROW 来解决这个问题。
具体操作步骤如下。
在主机中，修改 /etc/mysql/mysql.conf.d/mysqld.cnf 配置文件，将 binlog_format 改为 ROW，如下：
修改完成后，重启主机，主机重启之后，会产生新的 binlog 文件，所以我们需要重新查看主机的最新状态并重新配置从机，先来看主机，如下：
以此为依据，让从机重新连接主机，在从机上再进行如下操作：
stopslave;changemastertomaster_host=’10.3.50.27′,master_port=33061,master_user=’rep1′,master_password=’123′,master_log_file=’javaboy_logbin.000002′,master_log_pos=794;startslave;
重新配置完从机之后，我们继续向 user 表插入一条数据，插入完成后，我们再去看从机的数据，发现此时的数据已经是一致的了。
解决这个问题，我们最主要的更改就是修改了 binlog_format 为 ROW，当我们把 binlog_format 改为 ROW 之后，我们来看看此时 binlog 中都记录了啥。
showbinlogeventsIN’javaboy_logbin.000002’FROM794;
大家看到，在 BEGIN 和 COMMIT 之间，就是我们的数据修改操作。
Table_map：这一行是说明了接下来要操作 javaboy_db.user 表。Write_rows：这一行是说明了要写一行新的数据了。
不过这里看不出啥端倪来，我们借助 mysqlbinlog 工具来看看是否有新的发现。
为了查看 binlog，MySQL 为我们提供了两个官方工具，除了上面的 show binlog events，另一个就是 mysqlbinlog 命令，如下（注意在系统中执行该命令，不是在 MySQL 终端执行该命令）：
mysqlbinlog-vv/var/lib/mysql/javaboy_logbin.000002–start-position=794;-vv 表示显示详细信息，这样就会打印出 binlog 中二进制文件的内容。
这里的内容比较多，我们来看几个比较关键的地方：
Table_map: javaboy_db.user mapped to number 108：这表示接下来要操作编号为 108 的表，每张表都有一个自己的编号。Write_rows: table id 108 flags: STMT_END_F：这个就是具体的添加操作了，向编号为 108 的表中添加一条记录。
接下来那两行，大致上瞅一眼，像是 Base64 转码后的内容，大家感兴趣的可以自行解码看看，解码后有一些是乱码的，但是有一些字符串如 uuid 则没有乱码，我们也能大致猜出来这里存储的内容。
接下来我们看下面记录的 SQL，如下：
这就是日志中记录的内容，可以看到，每个字段上具体的值是啥，都写下来了，这样当然就不会发生数据不一致的情况了。
5. 小结
好啦，今天通过一个简单的案例，跟小伙伴们分享了 binlog 两种不同的日志格式，另外还有一中 MIXED 格式现在很少用了，感兴趣的小伙伴可以结合上篇文章的内容，在本文案例的基础上继续测试 MIXED 模式，这里我就不赘述啦～
