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

作者: f435aab7aefb | 来源:发表于2016-07-17 14:43 被阅读472次

    一、gtid特性介绍:

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

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

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

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

    shellgtid-mode = ON
    enforce_gtid_consistency = 1
    

    二、数据恢复需求:

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

    1. 开启GTID
    2. 有A库昨天凌晨12:00前的xtra备份文件
    3. 开启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:

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

    在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)
    

    相关文章

      网友评论

        本文标题:MySQL基于gtid特性与xtrabackup的数据恢复

        本文链接:https://www.haomeiwen.com/subject/jjzujttx.html