當前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

mysql gtid坑_通过mysqlbinlog --skip-gtids恢复后再备份可能造成的坑

發布時間：2023/12/9 数据库 44 豆豆

生活随笔收集整理的這篇文章主要介紹了 mysql gtid坑_通过mysqlbinlog --skip-gtids恢复后再备份可能造成的坑小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

版本

[root@uz22199 backup]# innobackupex --version

innobackupex version 2.4.8 Linux (x86_64) (revision id: 97330f7)

[root@uz22199 backup]# mysql -e"select @@version"

+------------+

| @@version |

+------------+

| 5.7.18-log |

+------------+

源庫

表結構與數據

root@mysqldb 21:51: [fandb]> show create table users\G

***************************1. row ***************************

Table: users

Create Table: CREATE TABLE `users` (

`email` varchar(10) DEFAULT NULL,

UNIQUE KEY `email` (`email`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

1 row in set (0.00 sec)

root@mysqldb 18:43: [fandb]> select* from users;

+-------+

| email | +-------+

| 1 |

| 10 |

| 20 |

| 30 |

| 5 | +-------+

插入一條數據

insert into users values(50); --GTID=1297

再刪掉

delete from users where email=50; ----GTID=1298

當前Executed_Gtid_Set

root@mysqldb 18:35: [fandb]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000005 | 495 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1298 | +------------------+----------+--------------+------------------+---------------------------------------------+

1 row in set (0.00 sec)

源庫再次應用一下已經執行過得binlog, 再次應用insert into users values(50); 這一條

這里先不考慮有沒有可能這樣子去恢復數據,只做實驗

[root@test43100 backup]# mysqlbinlog --skip-gtids --include-gtids='5c351518-78ec-11e7-8e7a-005056a610c3:1297' mysql-bin.000005 |mysql

root@mysqldb 18:43: [fandb]> select* from users;

+-------+

| email | +-------+

| 1 |

| 10 |

| 20 |

| 30 |

| 5 |

| 50 | +-------+

root@mysqldb 18:43: [fandb]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000005 | 617 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1299 | +------------------+----------+--------------+------------------+---------------------------------------------+

源庫Executed_Gtid_Set 已經到1299了

備份

innobackupex --user=backup --password='backup' --stream=tar /tmp | gzip -> full.tar.gz

170907 18:45:15 Backup created in directory '/tmp/'

MySQL binlog position: filename 'mysql-bin.000005', position '617', GTID of the last change '5c351518-78ec-11e7-8e7a-005056a610c3:1-1299'

170907 18:45:15 [00] Streaming

170907 18:45:15 [00] ...done

170907 18:45:15 [00] Streaming

170907 18:45:15 [00] ...done

xtrabackup: Transaction log of lsn (3112759) to (3112768) was copied.

170907 18:45:16 completed OK!

從備份輸出信息和xtrabackup_binlog_info都可以看到,這個全備備份了1-1299

[root@uz22199 full2]# more xtrabackup_binlog_info

mysql-bin.000005 617 5c351518-78ec-11e7-8e7a-005056a610c3:1-1299

把備份隨便搞到一個地方恢復出來

(恢復過程省略)

查看恢復出來的庫的Executed_Gtid_Set

root@mysqldb 18:48: [(none)]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000001 | 154 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1298 | +------------------+----------+--------------+------------------+---------------------------------------------+

1 row in set (0.00 sec)

雖然知道1298,但是50這條數據有了

root@mysqldb 18:43: [fandb]> select* from users;

+-------+

| email | +-------+

| 1 |

| 10 |

| 20 |

| 30 |

| 5 |

| 50 | +-------+

如果此時我們直接將該庫作為從庫,change master到源庫,那么start slave會報錯,1299會再執行一邊insert 50,會報1062錯誤.這就是坑

而如果我們flush binary logs一次,再做全備

root@mysqldb 21:51: [fandb]> flush binary logs;

Query OK, 0 rows affected (0.19 sec)

root@mysqldb 21:59: [fandb]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000006 | 194 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1299 | +------------------+----------+--------------+------------------+---------------------------------------------+

1 row in set (0.00 sec)

170907 22:00:58 Backup created in directory '/tmp/'

MySQL binlog position: filename 'mysql-bin.000006', position '194', GTID of the last change '5c351518-78ec-11e7-8e7a-005056a610c3:1-1299'

170907 22:00:58 [00] Streaming

170907 22:00:58 [00] ...done

170907 22:00:58 [00] Streaming

170907 22:00:58 [00] ...done

xtrabackup: Transaction log of lsn (3115326) to (3115335) was copied.

170907 22:00:58 completed OK!

[root@uz22199 full3]# more xtrabackup_binlog_info

mysql-bin.000006 194 5c351518-78ec-11e7-8e7a-005056a610c3:1-1299

Executed_Gtid_Set依舊是1-1299

再次將備份恢復出來,查看新恢復出來的庫

root@mysqldb 22:02: [(none)]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000001 | 154 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1299 | +------------------+----------+--------------+------------------+---------------------------------------------+

此時恢復出來的庫Executed_Gtid_Set為1-1299了

總結

那么要么以后通過mysqlbinlog –skip-gtids 恢復數據之后flush 一下binary logs;

要么恢復出來的庫都手動根據xtrabackup_binlog_info去set global gtid_purged

又做了一次

源庫:

root@mysqldb 17:14: [(none)]> flush binary logs;

Query OK, 0 rows affected (0.24 sec)

root@mysqldb 17:16: [(none)]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000008 | 194 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1300 | +------------------+----------+--------------+------------------+---------------------------------------------+

root@mysqldb 17:17: [(none)]> select * from fandb.users order by 1;

+-------+

| email | +-------+

| 1 |

| 10 |

| 20 |

| 30 |

| 5 |

| 50 |

| 60 | +-------+

7 rows in set (0.00 sec)

root@mysqldb 17:23: [(none)]> insert into fandb.users values(70);

Query OK, 1 row affected (0.06 sec)

root@mysqldb 17:23: [(none)]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000008 | 448 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1301 | +------------------+----------+--------------+------------------+---------------------------------------------+

1 row in set (0.00 sec)

root@mysqldb 17:24: [(none)]> delete from fandb.users where email=70;

Query OK, 1 row affected (0.05 sec)

root@mysqldb 17:24: [(none)]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000008 | 702 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1302 | +------------------+----------+--------------+------------------+---------------------------------------------+

1 row in set (0.00 sec)

root@mysqldb 17:24: [(none)]> select * from fandb.users order by 1;

+-------+

| email | +-------+

| 1 |

| 10 |

| 20 |

| 30 |

| 5 |

| 50 |

| 60 | +-------+

7 rows in set (0.00 sec)

mysqlbinlog --skip-gtids --include-gtids='5c351518-78ec-11e7-8e7a-005056a610c3:1301' /data/mysqldata/3306/binlog/mysql-bin.000008 |mysql

root@mysqldb 17:26: [(none)]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000008 | 956 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1303 | +------------------+----------+--------------+------------------+---------------------------------------------+

1 row in set (0.00 sec)

root@mysqldb 17:26: [(none)]> select * from fandb.users order by 1;

+-------+

| email | +-------+

| 1 |

| 10 |

| 20 |

| 30 |

| 5 |

| 50 |

| 60 |

| 70 | +-------+

8 rows in set (0.00 sec)

innobackupex --user=backup --password='backup' --stream=tar /tmp | gzip -> full4.tar.gz

MySQL binlog position: filename 'mysql-bin.000008', position '956', GTID of the last change '5c351518-78ec-11e7-8e7a-005056a610c3:1-1303'

170908 17:27:42 [00] Streaming

170908 17:27:42 [00] ...done

170908 17:27:42 [00] Streaming

170908 17:27:42 [00] ...done

xtrabackup: Transaction log of lsn (3121237) to (3121246) was copied.

170908 17:27:42 completed OK!

[root@uz22199 full4]# more xtrabackup_binlog_info

mysql-bin.000008 956 5c351518-78ec-11e7-8e7a-005056a610c3:1-1303

[root@uz22199 full4]# more xtrabackup_binlog_pos_innodb mysql-bin.000008 956

恢復出來的庫:

root@mysqldb 17:31: [(none)]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000001 | 154 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1300 | +------------------+----------+--------------+------------------+---------------------------------------------+

1 row in set (0.00 sec)

root@mysqldb 17:31: [(none)]> select * from fandb.users;

+-------+

| email | +-------+

| 1 |

| 10 |

| 20 |

| 30 |

| 5 |

| 50 |

| 60 |

| 70 | +-------+

8 rows in set (0.00 sec)

root@mysqldb 17:37: [(none)]> reset slave all;

Query OK, 0 rows affected (0.03 sec)

root@mysqldb 17:38: [(none)]> change master to master_host='10.4.3.100',master_port=3306,master_user='repl',master_password='repl',master_auto_position=1;

Query OK, 0 rows affected, 2 warnings (0.26 sec)

root@mysqldb 17:38: [(none)]> start slave;

Last_SQL_Error: Could not execute Write_rows event on table fandb.users; Duplicate entry '70' for key 'email', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000008, end_log_pos 417

總結

以上是生活随笔為你收集整理的mysql gtid坑_通过mysqlbinlog --skip-gtids恢复后再备份可能造成的坑的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。