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