今天發(fā)生了與之前某篇博客相似的問題，有同學(xué)在不同步的 binlog 庫(kù)中使用語句 database.table 命令對(duì)表進(jìn)行 drop 導(dǎo)致 master 丟棄該表但是從庫(kù)并未能同步到該操作。并且后續(xù)又實(shí)用 use xxxx 對(duì)該表進(jìn)行增刪字段，由于salve 并未建立此表于是 slave 崩潰的情況。

slave 崩潰信息通過查看 MySQL 錯(cuò)誤日志差不多是這樣

2019-07-11 15:05:12 17674 [ERROR] Slave SQL: Error 'Table'api.ring_king_record'doesn't exist'on query. Default database:'api'. Query:'ALTER TABLE `api`.`ring_king_record`

CHANGE COLUMN `course_id` `course_id` VARCHAR(45) NULL DEFAULT ''AFTER `id`,

CHANGE COLUMN `title` `title` VARCHAR(45) NULL DEFAULT ''AFTER `course_id`,

CHANGE COLUMN `serialNumber` `serial_number` VARCHAR(45) CHARACTER SET 'latin1' NULL DEFAULT '' COMMENT '唯一標(biāo)示碼',

CHANGE COLUMN `tsaCount` `tsa_count` VARCHAR(45) CHARACTER SET 'latin1' NULL DEFAULT '' COMMENT '剩余確權(quán)次數(shù)'', Error_code: 1146

2019-07-11 15:05:12 17674 [Warning] Slave: Table 'api.ring_king_record' doesn't exist Error_code: 1146

2019-07-11 15:05:12 17674 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000762' position 16412436.2019-07-11 15:05:12 17674 [Note] Slave I/O thread: connected to master 'xxxx',replication started in log 'mysql-bin.000763' at position 2157463

可以很清晰的看到錯(cuò)誤的原因是 api.ring_king_record 這個(gè)表根本不存在，但是卻嘗試去操作 change column 的操作。所以 slave 直接崩潰了， MySQL 提示我們數(shù)據(jù)庫(kù)已經(jīng)停止同步希望我們修復(fù)了這個(gè)問題之后再使用 SLAVE START 來啟動(dòng) slave 的同步跟上 master.

這里只需要關(guān)注兩個(gè)地方

1. mysql-bin.000762 可以讓我們定位到發(fā)生問題是哪個(gè) binlog。

2. position 可以讓我們定位到發(fā)生的位置是在哪兒。

通過 position 16412435 如果你可以訪問 master 物理機(jī)，那么可以通過訪問 binlog 所在目錄使用命令

mysqlbinlog mysql-bin.000672 | grep -C 100 16412435

去查看相關(guān)的信息，包括前后是什么語句，之類的。

如果類似于使用了 rds 這樣的 MySQL 服務(wù)，可以去 master 所在的 rds 并使用 MySQL Client 上執(zhí)行語句

show binlog events in 'mysql-bin.000762' from 16412436 limit 10\G;

我們可以得到從崩潰該語句開始的一些信息

mysql> show binlog events in 'mysql-bin.000762' from 16412436 limit 10\G;*************************** 1. row ***************************Log_name: mysql-bin.000762Pos:16412436Event_type: Gtid

Server_id:1215612563End_log_pos:16412484Info: SET @@SESSION.GTID_NEXT= '8dcfd361-10cb-11e9-9060-506b4b2ac23e:30038123'

*************************** 2. row ***************************Log_name: mysql-bin.000762Pos:16412484Event_type: Query

Server_id:1215612563End_log_pos:16412989Info: use `api`; ALTER TABLE `api`.`ring_king_record`

CHANGE COLUMN `course_id` `course_id` VARCHAR(45) NULL DEFAULT ''AFTER `id`,

CHANGE COLUMN `title` `title` VARCHAR(45) NULL DEFAULT ''AFTER `course_id`,

CHANGE COLUMN `serialNumber` `serial_number` VARCHAR(45) CHARACTER SET 'latin1' NULL DEFAULT '' COMMENT '唯一標(biāo)示碼',

CHANGE COLUMN `tsaCount` `tsa_count` VARCHAR(45) CHARACTER SET 'latin1' NULL DEFAULT '' COMMENT '剩余確權(quán)次數(shù)'

*************************** 3. row ***************************Log_name: mysql-bin.000762Pos:16412989Event_type: Gtid

Server_id:1215612563End_log_pos:16413037Info: SET @@SESSION.GTID_NEXT= '8dcfd361-10cb-11e9-9060-506b4b2ac23e:30038124'

*************************** 4. row ***************************Log_name: mysql-bin.000762Pos:16413037Event_type: Query

Server_id:1215612563End_log_pos:16413277Info:/*rds internal mark*/CREATE TABLE IF NOT EXISTS mysql.ha_health_check (

id BIGINT DEFAULT0,

type CHAR(1) DEFAULT '0',

PRIMARY KEY (type)

這里可以很清楚的看到崩潰位置?16412436 GTID:?8dcfd361-10cb-11e9-9060-506b4b2ac23e:30038123 執(zhí)行了 change column 的操作導(dǎo)致了崩潰。

現(xiàn)在我們要恢復(fù) slave 就需要跳過這個(gè)報(bào)錯(cuò)的語句。因?yàn)槿珠_啟了 GTID 的關(guān)系我們無法使用傳統(tǒng)的

root@(none) >stop slave;

Query OK,0 rows affected (0.00sec)

root@(none)>SET GLOBAL SQL_SLAVE_SKIP_COUNTER =N; #跳過N個(gè)事務(wù)

Query OK,0 rows affected (0.00sec)

root@(none)>start slave;

Query OK,0 rows affected, 1 warning (0.03sec)

來恢復(fù) 會(huì)報(bào)錯(cuò)

ERROR1858 (HY000): sql_slave_skip_counter can not be set when the server is running with @@GLOBAL.GTID_MODE = ON. Instead, for each transaction that you want to skip, generate an empty transaction with the same GTID as the transaction

我在網(wǎng)上查了不少資料，但是感覺大部分都是互相 copy xjb 扯淡，也根本使用不了。

下面是我結(jié)合幾個(gè)靠譜博客和官方文檔寫的一個(gè)配置

stop slave;

reset master;

reset slave;

CHANGE MASTER TO MASTER_HOST='master_address',MASTER_USER='xxx', MASTER_PASSWORD='xxx';set global gtid_purged = '8dcfd361-10cb-11e9-9060-506b4b2ac23e:30038123';

SET @@SESSION.GTID_NEXT= '8dcfd361-10cb-11e9-9060-506b4b2ac23e:30038124';

begin;

commit;

SET GTID_NEXT="AUTOMATIC";

start slave;

下面我會(huì)依次介紹這些命令是用來干嘛的。

首先我們所有現(xiàn)在針對(duì)去恢復(fù)的 slave 操作都需要先停止 slave.

reset master 這一步我不是很確定是否真的可以不做，reset master 會(huì)將 slave 機(jī)器的所有 binlog 都清空。比如之前我們可能是 mysql-bin.000023 這樣子，如果使用了 reset master 會(huì)重新從 mysql-bin.000001 開始記錄 binlog。我因?yàn)榍謇砹艘矝]關(guān)系，因?yàn)槲視?huì)要顯示的指定我從 master 機(jī)器的什么位置開始消費(fèi)并且追上 master 所以就設(shè)置了。

reset slave 將讓 slave 忘記主從復(fù)制的關(guān)系的位置信息，它會(huì)刪除 master.info 和 relay-log.iinfo 文件重置 relaylog 信息。我們知道 relay-log 其實(shí)就是用于記錄 slave 復(fù)制 master 信息復(fù)制到哪里來了這里會(huì)重置這些信息。

然后我哦們指定 change master 重新指定我們要跟隨的 master 地址。

設(shè)置全局的 gtid_purged 這里注意 這個(gè) gtid_purged 用于告訴你的 slave 無視哪些 gtid 的記錄段，就是我們會(huì)無視掉所有之前我們消費(fèi)過的記錄段直到到達(dá)我們報(bào)錯(cuò)的位置。這個(gè)可以跟下面的參數(shù)聯(lián)動(dòng)。從上面的圖我們看到我們只需要跳過 change column 那條語句所在的 GTID 重新從

8dcfd361-10cb-11e9-9060-506b4b2ac23e:30038124

開始消費(fèi)即可跳過，所以上面我們使用 30038124-1 來表示我們需要 purged 的部分。

最后我們通過提交一個(gè)空事務(wù)并指定自動(dòng)位移 GTID 來恢復(fù)我們的 slave。

一切完成之后我們啟動(dòng) slave 使用 start slave

這個(gè)時(shí)候我們的 slave 從庫(kù)會(huì)從我們指定的位置開始追上 master 只需要等待一段時(shí)間即可，那么如何判斷已經(jīng)追上了 master 呢？

我們?cè)趶膸?kù)上執(zhí)行

show slave status

mysql>show slave status\G;*************************** 1. row ***************************Slave_IO_State: Waitingfor master to send eventMaster_Host: xxxxxxxxxxxxMaster_User: xxxx

Master_Port:3306Connect_Retry:60Master_Log_File: mysql-bin.000764Read_Master_Log_Pos:6362259Relay_Log_File: mysqld-relay-bin.000006Relay_Log_Pos:6362469Relay_Master_Log_File: mysql-bin.000764Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB: xxxxxxxxxxxx

Replicate_Ignore_DB: mysql

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno:0Last_Error:

Skip_Counter:0Exec_Master_Log_Pos:6362259Relay_Log_Space:6362761Until_Condition: None

Until_Log_File:

Until_Log_Pos:0Master_SSL_Allowed: No

Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

Seconds_Behind_Master:0Master_SSL_Verify_Server_Cert: No

Last_IO_Errno:0Last_IO_Error:

Last_SQL_Errno:0Last_SQL_Error:

Replicate_Ignore_Server_Ids:

Master_Server_Id:1215612563Master_UUID: 8dcfd361-10cb-11e9-9060-506b4b2ac23e

Master_Info_File:/var/lib/mysql/master.info

SQL_Delay:0SQL_Remaining_Delay: NULL

Slave_SQL_Running_State: Slave has read all relay log; waitingfor the slave I/O thread to update it

Master_Retry_Count:86400Master_Bind:

Last_IO_Error_Timestamp:

Last_SQL_Error_Timestamp:

Master_SSL_Crl:

Master_SSL_Crlpath:

Retrieved_Gtid_Set: 8dcfd361-10cb-11e9-9060-506b4b2ac23e:30038448-30142673Executed_Gtid_Set: 0cf0e744-f9f6-11e8-bb7a-00163e302177:1-27887,

8dcfd361-10cb-11e9-9060-506b4b2ac23e:1-30142673Auto_Position:1

比較?Read_Master_Log_Pos 和 Exec_Master_Log_Pos 差不多就說明已經(jīng)追上了 master。

Relay_Log_Pos 和他們差不多能說明 io 線程也能拉到最新的數(shù)據(jù)。

當(dāng)我們有錯(cuò)誤的時(shí)候 show slave status 也可以給我們提供非常多的信息，例如最后出錯(cuò)的信息是啥。為什么報(bào)錯(cuò)都有顯示，如果沒有第一時(shí)間去看錯(cuò)誤日志，使用命令在這里看錯(cuò)誤信息也不錯(cuò)。

另外使用?show variables like '%gtid%'; 也可以給我們提供一些基于 gtid 的信息。

唔。。。又是修數(shù)據(jù)跑監(jiān)控的一天=。=

---------------------------------分割線---------------------------------

關(guān)于 GTID 昨晚回去 我重新翻看了一些資料覺得還是有必要多說兩句。

可以說 GTID 的出現(xiàn)解決了之前完全依賴 master 文件和 pos 的來切換主從的問題得到了解決。

MySQL 版本5.6 引入了 GTID 解決主從同步位點(diǎn)問題。GTID 的全稱是 Global Transaction Identifier 也就是全局事務(wù) ID,是一個(gè)事務(wù)在提交的時(shí)候生成的，是這個(gè)事務(wù)的唯一標(biāo)識(shí)。它由兩部分組成：

GTID=server_uuid:gno

其中 server_uuid 是一個(gè)實(shí)例第一次啟動(dòng)時(shí)自動(dòng)生成的，可以通過我們上面介紹的命令 show master/slave status 看到該機(jī)器的 UUID

gno 是一個(gè)整數(shù)，初始化是1，每次提交事務(wù)的時(shí)候分配給這個(gè)事務(wù)，并加 1。

GTIO 模式的啟動(dòng)配置：

#GTID

gtid_mode=on

enforce_gtid_consistency=on

log-slave-updates=1

GTID_mode 開啟的參數(shù)相關(guān)的是前兩個(gè)參數(shù)， log-slave-updates = 1 是開啟連貫復(fù)制 log

本身 slave 同步 master 的日志是不會(huì)再放入自己的 binlog 中的，如果我們還有機(jī)器在監(jiān)聽 slave 的 binlog 日志就需要開啟?log-slave-updates 參數(shù)。

在 GTID 模式下，每個(gè)事務(wù)都會(huì)跟一個(gè) GTID 一一對(duì)應(yīng)。這個(gè) GTID 有兩種生成方式，而使用哪種取決于 session 變量 gtid_next 的值。

可以看到上面我們?cè)谔^事務(wù)的時(shí)候是直接指定了一個(gè) GTID_NEXT 的位置從這個(gè)位置開始。

然后指定下面的偏移規(guī)則是 gtid_next=automatic 使用默認(rèn)值每執(zhí)行一個(gè)事務(wù)就 +1

這樣每個(gè) MySQL 實(shí)例都維護(hù)了一個(gè) GTID 集合，用來對(duì)應(yīng)“這個(gè)實(shí)例執(zhí)行過的所有事務(wù)”。

因?yàn)檫@個(gè)集合的存在，所以我們?cè)谥刂??slave 和 master 的進(jìn)度的時(shí)候，如果 slave 并沒有通過?gtid_purged 或者通過指定 GTID_NEXT 跳過已經(jīng)執(zhí)行的事務(wù) slave 會(huì)嘗試去執(zhí)行這些事務(wù)，并且因?yàn)橹麈I沖突等原因報(bào)錯(cuò)崩潰。

所以現(xiàn)在回頭過來看這幾條命令

set gtid_next='aaaaaaaa-cccc-dddd-eeee-ffffffffffff:10';

begin;

commit;set gtid_next=automatic;

start slave;

其實(shí)它的意義是 首先 :10 這個(gè)gtid 是有問題那個(gè) GTID 就是執(zhí)行了會(huì)崩潰的那個(gè) GTID 。

然后這個(gè)時(shí)候我們對(duì)其替換成一個(gè)空事務(wù)。

再設(shè)置之后都正常加一偏移數(shù)據(jù)。

最后啟動(dòng) slave 。這樣的話當(dāng)我們的 slave 運(yùn)行到這里的時(shí)候會(huì)因?yàn)橐呀?jīng)因?yàn)檫@個(gè) GTID 執(zhí)行了空事務(wù)，而無視跳過 master 傳遞過來的有問題的 binlog 從而達(dá)到跳過有問題事務(wù)的目的。

由于沒有實(shí)操過主備切換，這里注意到資料大部分都提到 GTID 模式下只需要指定 change master to 新的機(jī)器即可。新的 master 會(huì)自動(dòng)計(jì)算相關(guān)的位點(diǎn)。

CHANGE MASTER TO MASTER_HOST='xxxx',MASTER_USER='xxx', MASTER_PASSWORD='xxx';

master_auto_position=1

Reference:

https://yq.aliyun.com/articles/155827 ?MySQL GTID 主從復(fù)制錯(cuò)誤修復(fù)方法

https://www.douban.com/note/446551760/RESET MASTER 和RESET SLAVE 命令的使用方法 注意事項(xiàng)

https://www.cnblogs.com/zhoujinyi/p/4717951.html ?MySQL5.6 新特性之GTID

總結(jié)

以上是生活随笔為你收集整理的mysql slave lock 跳过_处理 MySQL 因为 SLAVE 崩溃导致需要手动跳过 GTID 的问题 | 关于 GTID...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。