host error怎么修复_GTID复制错误的修复

这是学习笔记的第 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有了更进一步的了解，对于一些异常情况的测试也在模拟测试中基本都碰到了。