s這是學(xué)習(xí)筆記的第?2031?篇文章

? 最近有個(gè)業(yè)務(wù)的MySQL復(fù)制問題還是比較多，做了事務(wù)降維之后，把一些敏感操作和線上環(huán)境隔離起來，整體的效果好了許多，不過今天在外面的時(shí)候，又收到一條報(bào)警短信，讓我心里咯噔一下。?

? 這個(gè)環(huán)境是一個(gè)中間件的分布式環(huán)境，有8個(gè)物理節(jié)點(diǎn)(主庫)，即有6個(gè)主庫+8個(gè)從庫，我查看了下郵件，發(fā)現(xiàn)報(bào)錯(cuò)的這個(gè)環(huán)境是昨天同事幫忙新建的從庫，到今天才這么短的時(shí)間，而且是基于GTID復(fù)制的模式，又出現(xiàn)了這類問題，我的心里還是比較忐忑的，因?yàn)槿绻以偈盏綆讞l其他環(huán)境類似的復(fù)制錯(cuò)誤，那么毫無疑問就屬于一起計(jì)劃外的故障了。

? ?故障離我們很近，但是在不同的時(shí)間有不同的理解。因?yàn)檫@段時(shí)間的做了數(shù)據(jù)遷移的一些高可用測(cè)試，壓力測(cè)試，數(shù)據(jù)重構(gòu)，整體該做的工作都做差不多了，到了臨門一腳的時(shí)候，出現(xiàn)一些頻繁的問題，我讓我有所措手不及，而問題能夠定位可控，很容易理解，可以查漏補(bǔ)缺，而如果問題是集中出現(xiàn)，那就說明之前的工作沒有做到位，一旦發(fā)現(xiàn)嚴(yán)重的bug導(dǎo)致服務(wù)不可用，如果反復(fù)出現(xiàn)，不管過程如何，結(jié)果就是不合格的。這種感覺就好比是高速公路給汽車換輪胎，時(shí)間緊，任務(wù)重。

??所幸的是，我等了一會(huì)沒有再收到其他環(huán)境的問題，所以一個(gè)基本的定位：不是很嚴(yán)重。?

? 等我回到酒店之后，開始處理的時(shí)候，腦海里一直在琢磨，到底是一條什么樣的SQL語句會(huì)導(dǎo)致這樣奇怪的問題。

??很快就查到了相關(guān)的描述信息：

? ?LAST_ERROR_MESSAGE: Worker 0 failed executing transaction 'db8f9860-8202-11e9-991e-005056b7f69e:854286845' at master log mysqlbin.000601, end_log_pos 936077509; Could not execute Update_rows event on table dbo_testdb.dbo_testdata; Can't find record in 'dbo_testdata', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysqlbin.000601, end_log_pos 936077509

看起來問題是在binlog日志000601的偏移量936077509附近，看到這個(gè)偏移量心里一糾，可以看到文件已經(jīng)超過900M了，解析起來已經(jīng)有一些性能問題了。?

查看show slave status的結(jié)果：

?????????????Slave_IO_Running: Yes

? ? ? ? ? ? Slave_SQL_Running: No

可以看到IO_thread依然可用，說明復(fù)制的過程中整體的數(shù)據(jù)傳輸是OK的，是在應(yīng)用的時(shí)候出現(xiàn)了問題 。?

我使用如下的語句開始解析這個(gè)偏移量附近的一些錯(cuò)誤。?

/usr/local/mysql/bin/mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS mysqlbin.000601 | grep -A '10' 936077509

得到了如下的結(jié)果：

#190705 19:27:15 server id 211? end_log_pos 936077509 CRC32 0x590574c3? Update_rows: table id 599753 flags: STMT_END_F

### UPDATE `dbo_testdb`.`dbo_testdata`

### WHERE

###? ?@1=748890203 /* LONGINT meta=0 nullable=0 is_null=0 */

###? ?@2=60 /* INT meta=0 nullable=0 is_null=0 */

###? ?@3=13 /* INT meta=0 nullable=0 is_null=0 */

###? ?@4='2019-07-05 19:27:15' /* DATETIME(0) meta=0 nullable=0 is_null=0 */

###? ?@5='2019-07-05 19:27:15' /* DATETIME(0) meta=0 nullable=0 is_null=0 */

###? ?@6=0 /* LONGINT meta=0 nullable=0 is_null=0 */

### SET

###? ?@1=748890203 /* LONGINT meta=0 nullable=0 is_null=0 */

--

# at 936077509

#190705 19:27:15 server id 211? end_log_pos 936077540 CRC32 0x78404313? Xid = 221915192

COMMIT/*!*/;

# at 936077540

#190705 19:27:15 server id 211? end_log_pos 936077605 CRC32 0x6e307159? GTID? ? last_committed=1762227? sequence_number=1762248

SET @@SESSION.GTID_NEXT= 'db8f9860-8202-11e9-991e-005056b7f69e:854286846'/*!*/;

# at 936077605

#190705 19:27:15 server id 211? end_log_pos 936077696 CRC32 0x00c8479d? Query? ?thread_id=854? ?exec_time=0? ? ?error_code=0

SET TIMESTAMP=1562326035/*!*/;

BEGIN

可以看到這是一條update語句，它的格式比較奇怪，如下：

update xxx

where userid=xxxx,value=xxxx

set userid=xxxx

從語句來看明顯是不符合業(yè)務(wù)場(chǎng)景的，自己變更自己，明顯不合理的。

我們來進(jìn)一步驗(yàn)證。

主庫端查看數(shù)據(jù)，把上面的update轉(zhuǎn)義成select語句：

select * from `dbo_testdb`.`dbo_testdata`

WHERE

userid=748890203 and?

xxx=60 and

value=13 and

moddate='2019-07-05 19:27:15' and

crtdate='2019-07-05 19:27:15' and

modver=0?

發(fā)現(xiàn)主庫端和從庫端都不存在這條語句。?

所以這就牽扯出來兩個(gè)問題：

1)如果MySQL在主庫端的SQL語句沒有發(fā)生數(shù)據(jù)變更，是否會(huì)依然產(chǎn)生binlog

2)一條update語句，在MySQL里的解析應(yīng)該是類似如下的形式：

update xxxx set xxxxx ?where 的形式，在這里明顯沒有走這種解析的方式。?

3)這條語句如何修復(fù)，因?yàn)楹竺娴臄?shù)據(jù)都等著這個(gè)斷點(diǎn)。

4)如果后續(xù)還有這種問題，該如何預(yù)防。?

我們?yōu)榱丝焖傩迯?fù)，經(jīng)過評(píng)估，主從庫端都沒有相應(yīng)的數(shù)據(jù)，說明這條語句是沒有產(chǎn)生影響的，我們可以跳過這個(gè)事務(wù)。?

stop slave;

SET @@SESSION.GTID_NEXT= 'db8f9860-8202-11e9-991e-005056b7f69e:854286846';

begin;commit;

SET SESSION GTID_NEXT = AUTOMATIC;

start slave;

再次嘗試這個(gè)問題暫時(shí)正常了，在反復(fù)驗(yàn)證中暫時(shí)沒有發(fā)現(xiàn)問題。?

而后續(xù)的進(jìn)一步驗(yàn)證得找下環(huán)境，會(huì)后續(xù)繼續(xù)說明。

對(duì)于問題本身，也需要和研發(fā)團(tuán)隊(duì)做一下確認(rèn)，這種操作的需求需要引導(dǎo)，后續(xù)不要再出現(xiàn)。

總結(jié)

以上是生活随笔為你收集整理的mysql decode语句_MySQL复制问题的分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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