看到了一篇server id導(dǎo)致MySQL備份恢復(fù)的時(shí)候丟失事務(wù)的文章,特此重現(xiàn)一下。
成都創(chuàng)新互聯(lián)專注于網(wǎng)站建設(shè),為客戶提供成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、網(wǎng)頁(yè)設(shè)計(jì)開發(fā)服務(wù),多年建網(wǎng)站服務(wù)經(jīng)驗(yàn),各類網(wǎng)站都可以開發(fā),品牌網(wǎng)站設(shè)計(jì),公司官網(wǎng),公司展示網(wǎng)站,網(wǎng)站設(shè)計(jì),建網(wǎng)站費(fèi)用,建網(wǎng)站多少錢,價(jià)格優(yōu)惠,收費(fèi)合理。
主備開啟了GTID,實(shí)驗(yàn)過程如下:
1.主庫(kù)執(zhí)行: create database test1; create database test2; 2.主從沒有延遲后備份,利用從庫(kù)備份,物理或者邏輯都可以: mysqldump -uroot -poracle --single-transaction --master-data=2 --all-databases > dump.sql 3.主庫(kù)執(zhí)行: create database test3; 4.將主庫(kù)干掉 5.從庫(kù)提升為主庫(kù),并且: create database test4; 6.利用從庫(kù)的備份恢復(fù)老的主庫(kù),并指向新主 這個(gè)時(shí)候會(huì)發(fā)現(xiàn),恢復(fù)出來的從庫(kù)丟失了一個(gè)事務(wù)test3: mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | ming | | mysql | | performance_schema | | sakila | | sys | | test1 | | test2 | | test4 | | tt | | world | +--------------------+ 11 rows in set (0.00 sec)
文章說是因?yàn)閟erver_id的緣故。
server id一個(gè)很大的作用是避免數(shù)據(jù)回環(huán)。所以事務(wù)中記錄的sever id會(huì)是持久不變的,就像我們的身份證一樣,
走到哪兒都不變。
老主庫(kù)因?yàn)槭抢脧膸?kù)的備份集還原出來的,執(zhí)行過的事務(wù)是 6f5b02b9-1f08-11ea-9853-000c2970dcdf:1-4,
那么就要去向新主請(qǐng)求6f5b02b9-1f08-11ea-9853-000c2970dcdf:5事務(wù)。
新主的master-bin log文件中該事務(wù)如下:server id是1573854809 。而該server id正好是老主的server id,
此時(shí)該條記錄就會(huì)被過濾掉。就不會(huì)傳遞到老主那邊去。
# at 836 #200328 11:23:25 server id 1573854809 end_log_pos 901 CRC32 0x23ffdc70 GTID last_committed=4 sequence_number=5 rbr_only=no SET @@SESSION.GTID_NEXT= '6f5b02b9-1f08-11ea-9853-000c2970dcdf:5'/*!*/; # at 901 #200328 11:23:25 server id 1573854809 end_log_pos 998 CRC32 0x2f611a1d Query thread_id=2 exec_time=4290974348 error_code=0 SET TIMESTAMP=1585365805/*!*/; create database test3 /*!*/;
那么為什么test4會(huì)被傳遞到老主被應(yīng)用呢?因?yàn)樵撌聞?wù)在新主master-bin log中如下,server id 1051295是新主的,
就不會(huì)被IO thread過濾.
# at 998 #200211 6:19:19 server id 1051295 end_log_pos 1063 CRC32 0xec9c6a1e GTID last_committed=5 sequence_number=6 rbr_only=no SET @@SESSION.GTID_NEXT= '4c312339-ab38-11e9-86a8-000c29050245:1'/*!*/; # at 1063 #200211 6:19:19 server id 1051295 end_log_pos 1160 CRC32 0xaccb28ab Query thread_id=2 exec_time=0 error_code=0 SET TIMESTAMP=1581373159/*!*/; SET @@session.sql_mode=1151336480/*!*/; create database test4 /*!*/;
那么為什么兩條記錄不一致呢?這是因?yàn)閠est3事務(wù)是老主傳遞過來的,那么在relay log中,master-bin log中,
以及向后傳遞到其它從庫(kù)中的時(shí)候,server id是會(huì)一直被帶下去的。test4事務(wù)是新主自己的事務(wù),
那么從他自己的master-bin log,以及向后傳遞的從庫(kù)的relay log和應(yīng)用后生成的master-bin log中都會(huì)是新主的server id。
所以test3會(huì)被過濾,test4會(huì)被應(yīng)用。
老的主庫(kù)此時(shí):
mysql> show master status\G *************************** 1. row *************************** File: mysql-bin.000002 Position: 1443 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 1508afe9-70a7-11ea-8d70-000c2970dcdf:1-3, --自己庫(kù)里執(zhí)行的事務(wù) 4c312339-ab38-11e9-86a8-000c29050245:1,--主從傳遞下來的事務(wù) 6f5b02b9-1f08-11ea-9853-000c2970dcdf:1-4--自己作為主的時(shí)候執(zhí)行的事務(wù) 1 row in set (0.00 sec)
新的主庫(kù):
mysql> show master status\G *************************** 1. row *************************** File: mysql-bin.000002 Position: 1322 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 4c312339-ab38-11e9-86a8-000c29050245:1-2, 6f5b02b9-1f08-11ea-9853-000c2970dcdf:1-5 1 row in set (0.00 sec)
文章名稱:mysql備份恢復(fù)實(shí)例丟失事務(wù)分析
URL鏈接:http://muchs.cn/article6/gecpog.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站改版、品牌網(wǎng)站制作、微信公眾號(hào)、ChatGPT、外貿(mào)建站、全網(wǎng)營(yíng)銷推廣
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)