一次事故的回顾金沙官网线上:

背景:MySQL5.6.40,库比较小,row+gtid复制环境,但由于以前种种原因,备份还原在从库后,开启复制存在大量1062,1032错误,gtid卡在靠前位置。做复制的时候没有任何从库,每小时的备份也被运维停了。

要讨论如何恢复从库,我们得先来了解如下一些概念:

以前从来没遇到过这种情况,相对测试环境正式环境比较复杂,而且猜测可能是之前备份还原从来没用过备份一致性参数导致,并且发现错误也没有手工检查(这个问题还在研究中,有遇到并知道原因的小伙伴欢迎指导)。

GTID_EXECUTED:它是一组包含已经记录在二进制日志文件中的事务集合

为了今后避免因为恢复不及时导致的数据丢失,特别总结本次故障过程和大家讨论、分享。

GTID_PURGED:它是一组包含已经从二进制日志删除掉的事务集合。

简化时间轴如下图:

 

开始---->备份主库---->恢复从库---->复制error1032,1062---->删除从库再次恢复---->复制error1032,1062---->reset master从库、主库---->准备删除从库---->误操作删主库----->恢复主库----->跳过大量1062、1032错误---->找drop db位置恢复从库---->对比主从数据---->手工补数据---->结束

 

下面按照我的记忆描述下当时的场景:

在继续讨论时,我们先来看下如何新建一个基于GTID的slave。

一、首次备份主库、搭建从库

第一次搭建从库,从主库的备份未使用master-data=2 single-transaction(保证事务备份时的一致性)参数迁移后,报大量1062和1032错误(家家有本难念的经,不多说了)

 

金沙官网线上 1

通过了解上面的两个参数,我们现在只需要:

二、第二次还原主库到从库

于是第二次重新导入。

同样报错。在导入从库前使用reset master;将从库binlog清除。

由于操作人员不了解reset master含义及执行结果,又在主库做了reset master;

结果导致主库所有binlog日志被清除并且binlog position置为1;

这里贴以下官方说明,别没事干就在主库上用这条。

 

金沙官网线上 2

再次导入发现依旧大量报1032,1062错误。

由于怀疑是因为备份时没使用--single-transaction参数,准备删除从库,加参数重新备份主库。

1.从主库上做一个备份时记录备份时gtid_executed的值。

三、误删除主库

结果误操作删除主库(这个锅一部分原因要甩给mysql naivcat这个工具,垂直排列库,稍微不注意就容易点错。还是建议大家听吴老师的用官方的workbench),删库还是两人校对,在操作系统上执行,删前没把握最好备份一遍。

删库这种操作谨慎谨慎再谨慎,重要的事情说三遍!

删库这种操作谨慎谨慎再谨慎,重要的事情说三遍!

删库这种操作谨慎谨慎再谨慎,重要的事情说三遍!

drop database;(在naivcat上右键删除库,但binlog日志中还是会记录DROP DATABASE这条记录)

这时候为了保证业务不中断,立马在主库上通过之前的备份文件恢复了一套库,当然数据肯定丢失了,但可以推算丢失数据的时间段(从备份完毕开始--->DROP DATABASE)。

PS.请不要问我为什么删库,为什么删完又恢复了一套库,因为都不是我干的。。。。。。

万幸的是误删除主库但并未删除从库,而且从库的io_thread仍然处于yes状态(回顾吴老师的课程,也就是说虽然库被删除了但其实删库前的数据=备份数据+io_thread已下载的删除主库前的数据),由于sql_thread仍然停到gtid靠前的位置

 

金沙官网线上 3

2.在新的slave上恢复此备份时设置从库的gtid_purged的值为备份时master上gtid_executed的值。

四、跳过大量1032,1062错误

这个时候只要看下备份文件的gtid位置,并purge到该位置(之前备份丢了,随便找了一个备份的截图,理解万岁)。

##这里说明一下为什么直接purge到备份的结尾位置,因为书库备份的数据中1032和1062错误太多,且主库已经删除没办法通过脚本对比跳过大量1032,1062错误(吴老师友情提供),在能够保证是从主库逻辑备份过来的情况下(主从数据一致),我们选择快速跳过大量错误(偷懒加情况急),直接purge到备份最后的位置。

 

金沙官网线上 4

##上图是随便截的一个备份文件最开头的位置,请忽略那个gtid的值,意思明白就行。

set @@gtid_purged='fb1f83af-1915-11e8-811b-000c29c4d77d:1-500';

注:‘500’代表备份文件最后一个执行的事务的gtid。gtid_purged代表数据库已经在从库上重放过1-500这段事务。

 

五、找到主库DROP DATABASE的GTID位置

purge到该位置然后再确定drop database的位置上(思路:如果不确定dropdatabase的位置就start slave 那么从库会应用主库的binlog也就会执行主库drop database的操作,为了避免从库重放主库drop database的操作,我们要设法让gtid在从库停到drop database前一个gtid的位置)

注:可以通过大致删库时间或者从从库的show slave statusG上看到主库的binlog位置从后往前找DROP DATABASE的位置,如果删库后做了reset master那就只能从从库的relay-bin-log上找了(切记主库没事别reset master);

mysqlbinlog    -vvv  --base64-output=decode-rows  relay-bin.000017

 

金沙官网线上 5

通过mysqldump可以完成我们需要的功能。

六、启动从库SQL_THREAD

在从库上执行start slave sql_thread until的命令,这里需要说明,因为主库已经还原,业务跑起来了,这时候开启io_thread没有什么意义,所以只用让从库的sql_thread线程重放DROP DATABASE之前的事务就行。

root@localhost[{none}]>start slave sql_thread until sql_before_gtid='fb1f83af-1915-11e8-811b-000c29c4d77d:2343';

启动slave,并且让从库gtid停在主库drop database操作之前一个gtid就可以,再还原到主库就能立马投入使用,还不会导致数据丢失。

 

金沙官网线上 6

确保从库executed_gtid_set到了我们before的前一个值就可以备份了,然后dump这份数据还原主库,当然如果从库性能不错的话可以考虑应用端更改连接,这样速度更快一些。

但比较麻烦的就是,要保证生产的实时性,删库后立即在主库上还原了之前用来恢复从库的备份文件,这就肯定会导致中间数据丢失。

 

七、数据对比还原

这时候只能使用用之前用来搭建从库的备份再恢复一个库,再用pt-table-checksum对比主库和恢复库,从库和恢复库不一致的数据,用pt-table-sync生成对应语句。然后手工把数据补进系统中。

对比1:主库:备份数据还原的库---->目标:找到主库在删库之后应用又写入了哪些数据。

对比2:从库:备份数据还原的库---->目标:找到备份数据之后,删库之前应用在主库里写了哪些数据。

因为量不是很大,手工对比一下就行,当然数据还原的坑也有很多,不过基本上都被研发填了。

 

总结:

头一回碰到删库情况还是有点蒙,还好主库用的是GTID找binlog日志中的位置相对容易一点。这次恢复最幸运的就是还好从库卡在靠前的位置,要不然即使有了从库,数据也会被删了,恢复起来相对更麻烦些。

对于gtid的恢复,课上吴炳锡老师都讲过,但是一上手还是慢了几拍,还是要通过实战多练习加深手感避免在真实情况下懵逼。

最后特别鸣谢:知数堂叶金荣老师和吴炳锡老师在故障发生时给予的帮助和支持。

转载请注明出处 https://www.cnblogs.com/Lemon-DBA/p/9396546.html

目前主库上的状态(3301):

金沙官网线上 7

[zejin] 3301>show global variables like 'gtid_executed';
+---------------+-------------------------------------------+
| Variable_name | Value |
+---------------+-------------------------------------------+
| gtid_executed | a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-15 |
+---------------+-------------------------------------------+
1 row in set (0.00 sec)

[zejin] 3301>show global variables like 'gtid_purged';
+---------------+-------------------------------------------+
| Variable_name | Value |
+---------------+-------------------------------------------+
| gtid_purged | a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-13 |
+---------------+-------------------------------------------+
1 row in set (0.00 sec)

金沙官网线上 8

 

 

 

step1:用mysqldump做一个全备

mysqldump --all-databases --single-transaction --triggers --routines --events --host=127.0.0.1 --port=3301 --user=root --password=123 > dump3301.sql

 

打开dump3301.sql我们可以看到如下语句:

SET @@GLOBAL.GTID_PURGED='a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-15';

此值即为master3301上gtid_executed的值。

 

step2:全新启动一个新的库3303,注意在配置文件中配置enforce_gtid_consistency及gtid_mode=on

金沙官网线上 9

mysqld_safe --defaults-file=/home/mysql/my3303.cnf &
此时新库3303上的状态应该是这样的:

[(none)] 3303>show global variables like 'gtid_executed';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_executed | |
+---------------+-------+
1 row in set (0.01 sec)

[(none)] 3303>show global variables like 'gtid_purged';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_purged | |
+---------------+-------+
1 row in set (0.00 sec)

金沙官网线上 10

 

 

step3:导入备份文件并查看状态值:

金沙官网线上 11

mysql -uroot -h127.0.0.1 -p123 -P3303 < dump3301.sql
[(none)] 3303>show global variables like 'gtid_executed';
+---------------+-------------------------------------------+
| Variable_name | Value |
+---------------+-------------------------------------------+
| gtid_executed | a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-15 |
+---------------+-------------------------------------------+
1 row in set (0.02 sec)

[(none)] 3303>show global variables like 'gtid_purged';
+---------------+-------------------------------------------+
| Variable_name | Value |
+---------------+-------------------------------------------+
| gtid_purged | a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-15 |
+---------------+-------------------------------------------+
1 row in set (0.00 sec)

金沙官网线上 12

 

金沙官网线上, 

 

step4:做主从change语句

金沙官网线上 13

[zejin] 3303>change master to master_host='192.168.1.240',master_port=3301,master_user='repl',master_password='123',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.01 sec)

[zejin] 3303>start slave;
Query OK, 0 rows affected (0.00 sec)

[zejin] 3303>show slave statusG
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.240
                  Master_User: repl
                  Master_Port: 3301
                Connect_Retry: 60
              Master_Log_File: binlog57.000014
          Read_Master_Log_Pos: 194
               Relay_Log_File: zejin240-relay-bin.000002
                Relay_Log_Pos: 365
        Relay_Master_Log_File: binlog57.000014
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              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: 194
              Relay_Log_Space: 575
              Until_Condition: None
               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: 0
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: 3301
                  Master_UUID: a97983fc-5a29-11e6-9d28-000c29d4dc3f
             Master_Info_File: /home/mysql/I3303/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-15
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
1 row in set (0.00 sec)

金沙官网线上 14

 

至此完成了加入一台新的slave的GTID主从环境。

 

 

假如我们目前拥有一主带两从的环境:

master(3301)

slave(3302)

slave(3303)

 

本文由金沙官网线上发布于数据库,转载请注明出处:一次事故的回顾金沙官网线上:

您可能还会对下面的文章感兴趣: