網(wǎng)上有很多關(guān)于pos機(jī)報(bào)99錯誤,GTID復(fù)制錯誤的修復(fù)的知識，也有很多人為大家解答關(guān)于pos機(jī)報(bào)99錯誤的問題，今天pos機(jī)之家(www.afbey.com)為大家整理了關(guān)于這方面的知識，讓我們一起來看下吧!
本文目錄一覽：
pos機(jī)報(bào)99錯誤
這是學(xué)習(xí)筆記的第 1971 篇文章
前幾天碰到一個MySQL服務(wù)器掉電，重新啟動之后，主從復(fù)制出現(xiàn)了異常。
show slave status的報(bào)錯信息如下： 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的心跳檢測機(jī)制，對于數(shù)據(jù)完整性來說，這個操作是可以彌補(bǔ)的。我們可以暫且忽略這一條。
于是使用如下的方法來跳過這個錯誤：
stop slave;
set session gtid_next=\'xxxxxxx\';
begin;commit;
SET SESSION GTID_NEXT = AUTOMATIC;
start slave;
本來以為這是一個常規(guī)的修復(fù)，沒想到復(fù)制狀態(tài)出現(xiàn)了問題，
為了盡快修復(fù)，我使用了reset slave all的方式，然后重新配置復(fù)制關(guān)系，
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.
從這個信息可以看出，應(yīng)該是日志的信息出了問題，但是查看主庫中，最近也沒做過purge binary logs操作，相關(guān)的日志都存在，為什么拋出這個錯誤呢。
經(jīng)過測試，發(fā)現(xiàn)有一個折中方案，那就是先臨時關(guān)閉GTID協(xié)議，使用偏移量的方式來重接復(fù)制，這個時候復(fù)制就正常了。
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協(xié)議，就又開始拋錯了。
change master to master_auto_position=1;
對于這個問題也著實(shí)下了功夫，發(fā)現(xiàn)還是對于GTID的理解不夠深入導(dǎo)致解決的時候困難重重。我們來理一下這個問題，看看這種情況下怎么修復(fù)。
為了能夠快速復(fù)選問題，并且進(jìn)行問題跟蹤，我把這個數(shù)據(jù)庫做了鏡像備份，如下是使用偏移量復(fù)制的狀態(tài)。
查看GTID的信息有些奇怪，這個內(nèi)容代表什么意思呢。
zExecuted_Gtid_Set: eb99e9de-c2cb-11e8-81e4-005056b7dfa4:1-4613465:6048714-6048731:6048837-6299932
從GTID的格式可以了解到，同一source_id的事務(wù)序號有多個范圍區(qū)間，各組范圍之間用冒號分隔，而這個時候查看mysql.gtid_executed的內(nèi)容如下：
查看GTID_purge變量的內(nèi)容如下：
從庫端的Executed_GTID狀態(tài)
通過這個內(nèi)容我們可以看出，目前的Executed_GTID_Set已經(jīng)是大于6299932了，但是在從庫端的GTID_Set中卻還是一個較大范圍的區(qū)間。
按照這種情況，開啟master_auto_position=1時，還是會嘗試去應(yīng)用舊的事務(wù)數(shù)據(jù)，也就難怪會拋出錯誤了。
我們在主庫端做下驗(yàn)證，看看主庫端的Executed_GTID_Set是什么情況，是否也是保留了一個較大的范圍區(qū)間。
從以上的結(jié)果可以看出，主庫端是很清晰的，目前的GTID_Set值已經(jīng)超過了6300007
從現(xiàn)在起，我們就在從庫端操作了。
首先，停止從庫的復(fù)制進(jìn)程。這個時候Executed_GTID_Set是6300028
>>stop slave;
因?yàn)槟壳暗腉TID配置有些不一致，所以我們需要重置一下GTID的配置。
>>reset master;
這個時候查看mysql.gtid_executed是沒有數(shù)據(jù)的。
>> select *from gtid_executed;
Empty set (0.00 sec)
我們初始化的時候，選擇這個臨界點(diǎn)GTID值：6300028
>>SET @@GLOBAL.GTID_PURGED=\'eb99e9de-c2cb-11e8-81e4-005056b7dfa4:1-6300028\';
Query OK, 0 rows affected (0.00 sec)
這樣從庫端的GTID設(shè)置就是和主庫一樣的配置方式了。
使用show master status可以看到，這個配置是生效了。
接下來我們來配置下復(fù)制關(guān)系。
重置從庫的復(fù)制配置
>>reset slave all;
重新建立復(fù)制，使用master_auto_position=1來開啟GTID協(xié)議復(fù)制
>> 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)
這個時候查看從庫的狀態(tài)，就達(dá)到了預(yù)期的效果了。
通過這個過程也著實(shí)對于GTID有了更進(jìn)一步的了解，對于一些異常情況的測試也在模擬測試中基本都碰到了。
以上就是關(guān)于pos機(jī)報(bào)99錯誤,GTID復(fù)制錯誤的修復(fù)的知識，后面我們會繼續(xù)為大家整理關(guān)于pos機(jī)報(bào)99錯誤的知識，希望能夠幫助到大家！
