网上有很多关于pos机报99错误,GTID复制错误的修复的知识，也有很多人为大家解答关于pos机报99错误的问题，今天pos机之家(www.poszjia.com)为大家整理了关于这方面的知识，让我们一起来看下吧!
本文目录一览：
pos机报99错误
这是学习笔记的第 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有了更进一步的了解，对于一些异常情况的测试也在模拟测试中基本都碰到了。
以上就是关于pos机报99错误,GTID复制错误的修复的知识，后面我们会继续为大家整理关于pos机报99错误的知识，希望能够帮助到大家！
