網上有很多關于pos機報99錯誤,GTID復制錯誤的修復的知識，也有很多人為大家解答關于pos機報99錯誤的問題，今天pos機之家(www.bangarufamily.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錯誤的知識，希望能夠幫助到大家！
