数据库

GTID复制错误的修复

2021-01-11 14:43:46 阅读数 1887 收藏 0

这是学习笔记的第 1971 篇文章


  前几天碰到一个MySQL服务器掉电,重新启动之后,主从复制出现了异常。

show slave status的报错信息如下:             Last_SQL_Error: Error '@@SESSION.GTID_NEXT cannot be set to ANONYMOUS when @@GLOBAL.GTID_MODE = ON.' on query. Default database: ''. Query: 'CREATE TABLE IF NOT EXISTS infra.chk_masterha (`key` tinyint NOT NULL primary key,`val` int(10) unsigned NOT NULL DEFAULT '0') engine=MyISAM'

可以从日志可以明显看出来,这是MHA的心跳检测机制,对于数据完整性来说,这个操作是可以弥补的。我们可以暂且忽略这一条。 

于是使用如下的方法来跳过这个错误:

stop slave;

set session gtid_next='xxxxxxx';

begin;commit;

SET SESSION GTID_NEXT = AUTOMATIC;

start slave;

本来以为这是一个常规的修复,没想到复制状态出现了问题,

为了尽快修复,我使用了reset slave all的方式,然后重新配置复制关系,

change master to MASTER_HOST='xx.124.67',MASTER_USER='dba_repl',MASTER_PASSWORD='xx',MASTER_PORT=4306,master_auto_position=1;

没想到抛出了如下的错误。

Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.

从这个信息可以看出,应该是日志的信息出了问题,但是查看主库中,最近也没做过purge binary logs操作,相关的日志都存在,为什么抛出这个错误呢。 

经过测试,发现有一个折中方案,那就是先临时关闭GTID协议,使用偏移量的方式来重接复制,这个时候复制就正常了。

change master to MASTER_HOST='xx.124.67',MASTER_USER='dba_repl',MASTER_PASSWORD='xxx',MASTER_PORT=4306,Master_Log_File='mysqlbin.000105',MASTER_LOG_POS=428492286,master_auto_position=0;

一旦想重新启用GTID协议,就又开始抛错了。
change master to master_auto_position=1;

对于这个问题也着实下了功夫,发现还是对于GTID的理解不够深入导致解决的时候困难重重。我们来理一下这个问题,看看这种情况下怎么修复。

为了能够快速复选问题,并且进行问题跟踪,我把这个数据库做了镜像备份,如下是使用偏移量复制的状态。


查看GTID的信息有些奇怪,这个内容代表什么意思呢。

zExecuted_Gtid_Set: eb99e9de-c2cb-11e8-81e4-005056b7dfa4:1-4613465:6048714-6048731:6048837-6299932

从GTID的格式可以了解到,同一source_id的事务序号有多个范围区间,各组范围之间用冒号分隔,而这个时候查看mysql.gtid_executed的内容如下:

查看GTID_purge变量的内容如下:

从库端的Executed_GTID状态

通过这个内容我们可以看出,目前的Executed_GTID_Set已经是大于6299932了,但是在从库端的GTID_Set中却还是一个较大范围的区间。

按照这种情况,开启master_auto_position=1时,还是会尝试去应用旧的事务数据,也就难怪会抛出错误了。 

我们在主库端做下验证,看看主库端的Executed_GTID_Set是什么情况,是否也是保留了一个较大的范围区间。


从以上的结果可以看出,主库端是很清晰的,目前的GTID_Set值已经超过了6300007

从现在起,我们就在从库端操作了。 

首先,停止从库的复制进程。这个时候Executed_GTID_Set是6300028

>>stop slave;

因为目前的GTID配置有些不一致,所以我们需要重置一下GTID的配置。

>>reset master;

这个时候查看mysql.gtid_executed是没有数据的。

>> select *from gtid_executed;

Empty set (0.00 sec)

我们初始化的时候,选择这个临界点GTID值:6300028

>>SET @@GLOBAL.GTID_PURGED='eb99e9de-c2cb-11e8-81e4-005056b7dfa4:1-6300028';

Query OK, 0 rows affected (0.00 sec)

这样从库端的GTID设置就是和主库一样的配置方式了。

使用show master status可以看到,这个配置是生效了。

接下来我们来配置下复制关系。

重置从库的复制配置

>>reset slave all;

重新建立复制,使用master_auto_position=1来开启GTID协议复制

>> CHANGE MASTER TO MASTER_HOST='xxx.124.67',MASTER_USER='dba_repl',MASTER_PASSWORD='xxx',MASTER_PORT=4306,MASTER_AUTO_POSITION=1;

Query OK, 0 rows affected, 1 warning (0.01 sec)

启动从库

mysql--dba_admin@127.0.0.1:mysql 18:35:40>>start slave;

Query OK, 0 rows affected (0.00 sec)

这个时候查看从库的状态,就达到了预期的效果了。

通过这个过程也着实对于GTID有了更进一步的了解,对于一些异常情况的测试也在模拟测试中基本都碰到了。





本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。