mysql備份恢復(fù)實(shí)例丟失事務(wù)分析

看到了一篇server id導(dǎo)致mysql備份恢復(fù)的時(shí)候丟失事務(wù)的文章，特此重現(xiàn)一下。

主備開(kāi)啟了GTID，實(shí)驗(yàn)過(guò)程如下：

1.主庫(kù)執(zhí)行：
create database test1;
create database test2;
2.主從沒(méi)有延遲后備份，利用從庫(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ù)出來(lái)的從庫(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)

文章說(shuō)是因?yàn)閟erver_id的緣故。

server id一個(gè)很大的作用是避免數(shù)據(jù)回環(huán)。所以事務(wù)中記錄的sever id會(huì)是持久不變的，就像我們的身份證一樣，

走到哪兒都不變。

老主庫(kù)因?yàn)槭抢脧膸?kù)的備份集還原出來(lái)的，執(zhí)行過(guò)的事務(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ì)被過(guò)濾掉。就不會(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過(guò)濾.

# 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ù)是老主傳遞過(guò)來(lái)的，那么在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ì)被過(guò)濾，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,--主從傳遞下來(lái)的事務(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)