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

[[195974]]

一、gtid特性介绍:

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

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

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

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

  1. gtid-mode                       = ON 
  2. enforce_gtid_consistency        = 1  

二、数据恢复需求:

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

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

三、恢复操作:

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

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

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

2. 开启B库,配置主从

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

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

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

  1. mysql> SET GLOBAL gtid_purged="8133046e-4282-11e6-848e-026ca51d284c:1-4920155"
  2.  
  3. Query OK, 0 rows affected (0.00 sec) 
  4.  
  5. mysql> change master to Master_Host ='10.11.21.14',Master_Port=3306,Master_User='replica',Master_Password='XXXXXXXXX',MASTER_AUTO_POSITION=1; 
  6.  
  7. 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语句:

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

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

  1. at 561467475 
  2. #160521  0:24:31 server id 212177500  end_log_pos 561467523 CRC32 0x216072ca    GTID [commit=yes] 
  3. SET @@SESSION.GTID_NEXT= '542ef021-9a64-11e5-bc49-025d3d22c211:1348360'/*!*/;  

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

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

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

  1. mysql> show slave status\G 
  2. *************************** 1. row *************************** 
  3.                Slave_IO_State: Waiting for master to send event 
  4.                   Master_Host: 10.30.21.11 
  5.                   Master_User: replica 
  6.                   Master_Port: 7500 
  7.                 Connect_Retry: 60 
  8.               Master_Log_File: mysql-bin.000011 
  9.           Read_Master_Log_Pos: 810203081 
  10.                Relay_Log_File: relay-bin.000002 
  11.                 Relay_Log_Pos: 5707357 
  12.         Relay_Master_Log_File: mysql-bin.000011 
  13.              Slave_IO_Running: Yes 
  14.             Slave_SQL_Running: No 
  15.               Replicate_Do_DB: 
  16.           Replicate_Ignore_DB: 
  17.            Replicate_Do_Table: 
  18.        Replicate_Ignore_Table: 
  19.       Replicate_Wild_Do_Table:  
  20.   Replicate_Wild_Ignore_Table: 
  21.                    Last_Errno: 0 
  22.                    Last_Error: 
  23.                  Skip_Counter: 0 
  24.           Exec_Master_Log_Pos: 561467475 
  25.               Relay_Log_Space: 254443161 
  26.               Until_Condition: SQL_BEFORE_GTIDS 
  27.                Until_Log_File: 
  28.                 Until_Log_Pos: 0 
  29.            Master_SSL_Allowed: No 
  30.            Master_SSL_CA_File: 
  31.            Master_SSL_CA_Path: 
  32.               Master_SSL_Cert: 
  33.             Master_SSL_Cipher: 
  34.                Master_SSL_Key: 
  35.         Seconds_Behind_Master: NULL 
  36. Master_SSL_Verify_Server_Cert: No 
  37.                 Last_IO_Errno: 0 
  38.                 Last_IO_Error: 
  39.                Last_SQL_Errno: 0 
  40.                Last_SQL_Error: 
  41.   Replicate_Ignore_Server_Ids: 
  42.              Master_Server_Id: 21117500 
  43.                   Master_UUID: 63f38fe7-9e3b-11e5-9554-02eeb2c1042f 
  44.              Master_Info_File: /data1/mysql10070/data/master.info 
  45.                     SQL_Delay: 0 
  46.           SQL_Remaining_Delay: NULL 
  47.       Slave_SQL_Running_State: 
  48.            Master_Retry_Count: 86400 
  49.                   Master_Bind: 
  50.       Last_IO_Error_Timestamp: 
  51.      Last_SQL_Error_Timestamp: 
  52.                Master_SSL_Crl: 
  53.            Master_SSL_Crlpath: 
  54.            Retrieved_Gtid_Set: 542ef021-9a64-11e5-bc49-025d3d22c211:1341313-1368005 
  55.             Executed_Gtid_Set: 44226252-9e38-11e5-9540-02212401d46f:1, 
  56. 542ef021-9a64-11e5-bc49-025d3d22c211:1-1348359, 
  57. 63f38fe7-9e3b-11e5-9554-02eeb2c1042f:1 
  58.                 Auto_Position: 1 
  59. 1 row in set (0.00 sec)  

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

附:常见问题

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

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

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

  1. mysql> SET GLOBAL gtid_purged="8133046e-4282-11e6-848e-026ca51d284c:1-4920155"
  2. ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty. 
  3. mysql> show master status; 
  4. +------------------+----------+--------------+------------------+-------------------------------------------+ 
  5. | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         | 
  6. +------------------+----------+--------------+------------------+-------------------------------------------+ 
  7. | mysql-bin.000002 |      191 |              |                  | 3857c25c-2caa-11e6-b61b-021feddc3827:1-14 | 
  8. +------------------+----------+--------------+------------------+-------------------------------------------+ 
  9. 1 row in set (0.00 sec) 
  10.  
  11. mysql> reset master; 
  12. Query OK, 0 rows affected (0.01 sec) 
  13.  
  14. mysql> show master status; 
  15. +------------------+----------+--------------+------------------+-------------------+ 
  16. | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | 
  17. +------------------+----------+--------------+------------------+-------------------+ 
  18. | mysql-bin.000001 |      151 |              |                  |                   | 
  19. +------------------+----------+--------------+------------------+-------------------+ 
  20. 1 row in set (0.00 sec) 
  21.  
  22. mysql> SET GLOBAL gtid_purged="8133046e-4282-11e6-848e-026ca51d284c:1-4920155"
  23. Query OK, 0 rows affected (0.00 sec)  

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/229795.html<

(0)
管理的头像管理
上一篇2025-04-18 22:42
下一篇 2025-04-18 22:43

相关推荐

  • 高防服务器的防御原理是什么,如何选择高防服务器?

    高防服务器的防御原理,简单说就是通过流量清洗、防火墙规则和黑洞路由等机制,在攻击流量到达业务服务器之前将其过滤或阻断,从而保障正常访问,流量清洗机制是核心防线高防服务器对抗DDoS攻击,靠的不是单一技术,而是一套组合动作,最常见的攻击类型是流量型攻击,比如UDP洪水、SYN洪水、ICMP放大等,核心思路是耗尽带……

    2026-07-26
    0
  • BGP线路到底是什么意思呢,有什么优势?

    BGP线路是一种通过边界网关协议实现多运营商网络互联的接入方式,能自动选择最优路径,极大提升跨网访问速度和稳定性,是解决国内南北网络瓶颈的核心方案,什么是BGP线路BGP,全称Border Gateway Protocol,边界网关协议,是互联网核心路由协议之一,它负责在自治系统之间交换网络可达性信息,BGP线……

    2026-07-26
    0
  • 增值电信业务经营许可证对IDC有多重要,如何办理?

    增值电信业务经营许可证是IDC服务商合法运营的核心凭证,它直接决定了机房能否接入骨干网、客户能否放心托管业务,以及服务商自身能否长期稳定发展,许可证是IDC进入市场的硬门槛互联网数据中心业务属于增值电信业务中的B1类,依据工信部《电信业务经营许可管理办法》,任何从事服务器托管、虚拟主机、云服务等业务的企业,必须……

    2026-07-26
    0
  • 站群服务器一个IP放几个网站合适?,怎么选

    站群服务器一个IP放3-5个网站是大多数情况下的最佳平衡点,但具体数量需根据网站权重、内容质量及IP资源成本灵活调整,这个结论基于搜索引擎对同IP站点的关联判定逻辑,以及站群运营的长期实践,如果你刚接触站群,可能会纠结于IP分配,但核心原则是:不要让搜索引擎轻易识别出这些网站属于同一实体,站群IP分配的底层逻辑……

    2026-07-26
    0
  • DDoS攻击和CC攻击有什么区别,怎么防御?

    DDoS攻击和CC攻击最核心的区别在于攻击目标不同:DDoS攻击主要消耗网络带宽和基础设施资源,而CC攻击专门针对应用层逻辑,耗尽服务器CPU和数据库连接数,两者从原理到防御手段完全不同,攻防视角下的本质差异攻击目标:一个砸门,一个撬锁DDoS攻击(分布式拒绝服务)瞄准的是网络层和传输层,通过大量伪造数据包或畸……

    2026-07-26
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注