MySQL基于gtid特性与xtrabackup的数据恢复

网友投稿 713 2023-05-02

MySQL基于gtid特性与xtrabackup的数据恢复

MySQL基于gtid特性与xtrabackup的数据恢复

一、gtid特性介绍:

GTID(global transaction identifier)是MySQL 5.6的新特性,可以唯一的标识一个事务,由UUID+TID组成:

UUID是MySQL实例的唯一标识TID是该实例上已提交的事务的数量

在主从复制中,GTID代替了classic的复制方法,不再使用binlog+pos开启复制,而是使用master_auto_postion = 1的方式自动匹配GTID断点进行复制。

要开启GTID,只需在MySQL参数文件中添加以下参数:

gtid-mode                       = ON enforce_gtid_consistency        = 1

二、数据恢复需求:

需要将MySQL(以下简称A库)恢复到一天前的凌晨12:00左右的状态 需要具备的前提条件如下:

开启GTID有A库昨天凌晨12:00前的xtra备份文件开启binlog日志(废话)

三、恢复操作:

在另一台MySQL(B库)上进行数据的恢复,这样可以避免影响线上业务

1. 将B库data目录移走,拷贝A库备份文件到B库

mv data data_20160716           #移走B库data mv A_back_20160714 data         #移入A库备份文件 chown -R mysql12300.mysql data/

2. 开启B库,配置主从

查看data目录下xtrabackup_binlog_info文件中记录的GTID:

[root@service-test1 data]$ cat xtrabackup_binlog_info  mysql-bin.000012        46455554        8133046e-4282-11e6-848e-026ca51d284c:1-4920155

在B库(slave)设置@@global.gtid_purged跳过备份包含的GTID,并执行change master to指定A库为主库:

mysql> SET GLOBAL gtid_purged="8133046e-4282-11e6-848e-026ca51d284c:1-4920155";  Query OK, 0 rows affected (0.00 sec)  mysql> change master to Master_Host ='10.11.21.14',Master_Port=3306,Master_User='replica',Master_Password='XXXXXXXXX',MASTER_AUTO_POSITION=1;  Query OK, 0 rows affected, 2 warnings (0.01 sec)

注意: xtrabackup_binlog_info中的GTID有时不止一个,设置@@global.gtid_purged时指定多个即可,以逗号隔开。

四、在A库binlog中找到恢复点并进行恢复

需要特别注意的是,在上述操作后,不要直接start slave,否则B库也又会跑到当前A库的状态

将A库binlog转换为sql语句:

mysqlbinlog -vv mysql-bin.000011 > mysql-bin.000011.sql

找到前一天凌晨12:00左右的位置并记录GTID:

在B库开启slave并指定恢复到的位置:

mysql> start slave until SQL_BEFORE_GTIDS='542ef021-9a64-11e5-bc49-025d3d22c211:1348360';  Query OK, 0 rows affected (0.00 sec)

当执行到了指定的GTID,SQL线程便会停止,但IO线程还会继续复制:

mysql> show slave status\G *************************** 1. row ***************************                Slave_IO_State: Waiting for master to send event                   Master_Host: 10.30.21.11                   Master_User: replica                   Master_Port: 7500                 Connect_Retry: 60               Master_Log_File: mysql-bin.000011           Read_Master_Log_Pos: 810203081                Relay_Log_File: relay-bin.000002                 Relay_Log_Pos: 5707357         Relay_Master_Log_File: mysql-bin.000011              Slave_IO_Running: Yes             Slave_SQL_Running: No               Replicate_Do_DB:           Replicate_Ignore_DB:            Replicate_Do_Table:        Replicate_Ignore_Table:       Replicate_Wild_Do_Table:    Replicate_Wild_Ignore_Table:                    Last_Errno: 0                    Last_Error:                  Skip_Counter: 0           Exec_Master_Log_Pos: 561467475               Relay_Log_Space: 254443161               Until_Condition: SQL_BEFORE_GTIDS                Until_Log_File:                 Until_Log_Pos: 0            Master_SSL_Allowed: No            Master_SSL_CA_File:            Master_SSL_CA_Path:               Master_SSL_Cert:             Master_SSL_Cipher:                Master_SSL_Key:         Seconds_Behind_Master: NULL Master_SSL_Verify_Server_Cert: No                 Last_IO_Errno: 0                 Last_IO_Error:                Last_SQL_Errno: 0                Last_SQL_Error:   Replicate_Ignore_Server_Ids:              Master_Server_Id: 21117500                   Master_UUID: 63f38fe7-9e3b-11e5-9554-02eeb2c1042f              Master_Info_File: /data1/mysql10070/data/master.info                     SQL_Delay: 0           SQL_Remaining_Delay: NULL       Slave_SQL_Running_State:            Master_Retry_Count: 86400                   Master_Bind:       Last_IO_Error_Timestamp:      Last_SQL_Error_Timestamp:                Master_SSL_Crl:            Master_SSL_Crlpath:            Retrieved_Gtid_Set: 542ef021-9a64-11e5-bc49-025d3d22c211:1341313-1368005             Executed_Gtid_Set: 44226252-9e38-11e5-9540-02212401d46f:1, 542ef021-9a64-11e5-bc49-025d3d22c211:1-1348359, 63f38fe7-9e3b-11e5-9554-02eeb2c1042f:1                 Auto_Position: 1 1 row in set (0.00 sec)

好啦,想看昨天凌晨的哪些数据呀?都在B库里啦~~~

附:常见问题

在设置@@global.gtid_purged时,可能会遇到报错:

mysql> SET GLOBAL gtid_purged="8133046e-4282-11e6-848e-026ca51d284c:1-4920155"; ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.

这是因为这台MySQL的@@GLOBAL.GTID_EXECUTED并不是空的,执行以下reset master操作就好了:

mysql> SET GLOBAL gtid_purged="8133046e-4282-11e6-848e-026ca51d284c:1-4920155"; ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty. mysql> show master status; +------------------+----------+--------------+------------------+-------------------------------------------+ | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         | +------------------+----------+--------------+------------------+-------------------------------------------+ | mysql-bin.000002 |      191 |              |                  | 3857c25c-2caa-11e6-b61b-021feddc3827:1-14 | +------------------+----------+--------------+------------------+-------------------------------------------+ 1 row in set (0.00 sec)  mysql> reset master; Query OK, 0 rows affected (0.01 sec)  mysql> show master status; +------------------+----------+--------------+------------------+-------------------+ | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000001 |      151 |              |                  |                   | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec)  mysql> SET GLOBAL gtid_purged="8133046e-4282-11e6-848e-026ca51d284c:1-4920155"; Query OK, 0 rows affected (0.00 sec)

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:一张思维导图纵观MySQL数据安全体系
下一篇:MySQL备份原理详解
相关文章