微信搜索superit|邀请体验:大数据, 数据管理、OLAP分析与可视化平台 | 赞助作者:赞助作者

MySQL 主从复制数据不一致,怎么办?

mysql aide_941 6℃

文章目录

  1. 准备工作
    1.1 主机配置
    1.2 从机配置
  2. 数据不一致问题
  3. 原因分析
  4. 问题解决
  5. 小结

今天的文章来晚了,主要是我一觉起来变黄码了,关键是我还不知道,早上 8.20 到了公司楼下,保安要看健康码,当我自信满满的打开粤省事却傻眼了,折腾一早上,绿码总算回来了,真是生活处处有惊喜。。。
书接上回,闲话不表。

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

  1. 准备工作
    以下配置基于 Docker。

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

这里,我们准备两台机器:

主机:10.3.50.27:33061
从机:10.3.50.27:33062
1.1 主机配置
主机的配置就三个步骤,比较容易:

  1. 授权给从机服务器

GRANT REPLICATION SLAVE ON . to ‘rep1’@’10.3.50.27’ identified by ‘123’;
FLUSH PRIVILEGES;
1
2
这里表示配置从机登录用户名为 rep1,密码为 123,并且必须从 10.3.50.27 这个地址登录,登录成功之后可以操作任意库中的任意表。其中,如果不需要限制登录地址,可以将 IP 地址更换为一个 %。

注意,在 MySQL8 里边,这块有一些变化。MySQL8 中用户创建和授权需要分开,不能像上面那样一步到位,具体方式如下:

CREATE USER code>rep1@10.3.50.27 IDENTIFIED WITH caching_sha2_password BY ‘javaboy.COM’;

GRANT Replication Slave ON . TO code>rep1@10.3.50.27;
1
2
3

  1. 修改主库配置文件

开启 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 文件的最大字节

设置最大 100MB

max_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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
各项配置的含义松哥已经在注视中说明了。截图如下:

如下图:

log-bin:同步的日志路径及文件名,一定注意这个目录要是 MySQL 有权限写入的(我这里是偷懒了,直接放在了下面那个datadir下面)。
binlog-do-db:要同步的数据库名,当从机连上主机后,只有这里配置的数据库才会被同步,其他的不会被同步。
server-id: MySQL 在主从环境下的唯一标志符,给个任意数字,注意不能和从机重复。
修改 binlog_format 的值为 STATEMENT,这一点很关键。
配置完成后重启 MySQL 服务端:

docker restart mysql33061
1

  1. 查看主服务器当前二进制日志名和偏移量

这个操作的目的是为了在从数据库启动后,从这个点开始进行数据的恢复:

show master status;
1

再看一眼 binlog_format 设置成功没:

可以看到,没问题。

至此,主机配置完成。

1.2 从机配置
从机的配置也比较简单,我们一步一步来看:

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

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

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

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

  1. 使用命令来配置从机

change master to master_host=’10.3.50.27′,master_port=33061,master_user=’rep1′,master_password=’123′,master_log_file=’javaboy_logbin.000001′,master_log_pos=154;
1
这里配置了主机地址、端口以及从机登录主机的用户名和密码,注意最后两个参数要和 master 中的保持一致。

注意,由于 MySQL8 密码插件的问题,这个问题同样会给主从配置带来问题,所以在 MySQL8 配置主从上,上面这行命令需要添加 get_master_public_key=1,完整命令如下:

change master to master_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;
1

  1. 启动 slave 进程

start slave;
1
启动之后查看从机状态:

show slave status\G;
1

  1. 查看 slave 的状态

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

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
1
2
至此,配置完成,主机创建库,添加数据,从机会自动同步。

如果这两个有一个不为 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 线程读取中转日志,解析出日志里的命令,并执行。
大致就是这样一个流程。

  1. 数据不一致问题
    接下来我们创建一个 javaboy_db 的数据库,并在里边创建一个 user 表,user 表的定义如下:

CREATE TABLE user (
id int(11) unsigned NOT NULL AUTO_INCREMENT,
uuid varchar(128) DEFAULT NULL,
name varchar(64) DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
1
2
3
4
5
6
接下来我们在主机中向 user 表中插入一条记录,如下:

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

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

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

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

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

show binlog events [IN ‘log_name’] [FROM pos] [LIMIT [offset,] row_count];
1
这个表示以事件的方式来查看 binlog,这里涉及到几个参数:

log_name:可以指定要查看的 binlog 日志文件名,如果不指定的话,表示查看最早的 binlog 文件。
pos:从哪个 pos 点开始查看,凡是 binlog 记录下来的操作都有一个 pos 点,这个其实就是相当于我们可以指定从哪个操作开始查看日志,如果不指定的话,就是从该 binlog 的开头开始查看。
offset:这是是偏移量,不指定默认就是 0。
row_count:查看多少行记录,不指定就是查看所有。
查看命令如下(我这里就从 pos 为 154 的位置开始):

show binlog events IN ‘javaboy_logbin.000001’ FROM 154;
1
查看结果如下(部分):

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

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

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

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

具体操作步骤如下。

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

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

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

stop slave;

change master to master_host=’10.3.50.27′,master_port=33061,master_user=’rep1′,master_password=’123′,master_log_file=’javaboy_logbin.000002′,master_log_pos=794;

start slave;
1
2
3
4
5
重新配置完从机之后,我们继续向 user 表插入一条数据,插入完成后,我们再去看从机的数据,发现此时的数据已经是一致的了。

解决这个问题,我们最主要的更改就是修改了 binlog_format 为 ROW,当我们把 binlog_format 改为 ROW 之后,我们来看看此时 binlog 中都记录了啥。

show binlog events IN ‘javaboy_logbin.000002’ FROM 794;
1

大家看到,在 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;
1
-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,如下:

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

  1. 小结
    好啦,今天通过一个简单的案例,跟小伙伴们分享了 binlog 两种不同的日志格式,另外还有一中 MIXED 格式现在很少用了,感兴趣的小伙伴可以结合上篇文章的内容,在本文案例的基础上继续测试 MIXED 模式,这里我就不赘述啦~
    ————————————————
    版权声明:本文为CSDN博主「_江南一点雨」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
    原文链接:
    https://blog.csdn.net/u012702547/article/details/123559519

转载请注明:SuperIT » MySQL 主从复制数据不一致,怎么办?

喜欢 (0)or分享 (0)