专栏首页爱可生开源社区技术分享 | 使用备份恢复实例时存在的坑

技术分享 | 使用备份恢复实例时存在的坑

作者:林靖华

爱可生服务团队成员,负责处理客户在MySQL日常运维中遇到的问题;擅长处理备份相关的问题,对数据库相关技术有浓厚的兴趣,喜欢钻研各种问题。

本文来源:原创投稿

*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。


前言

在日常数据库运维中,备份是不可缺少的一部分。我们常常用备份集来新建从库或恢复数据不一致的实例等等。但有些时候恢复完实例加回集群后,是有可能会丢失数据的。

实验

环境准备

步骤

1、主从同步验证

先在主库写入一些数据,然后验证数据已经同步到从库

-- master(131)
 
mysql> create database test1;
 
Query OK, 1 row affected (0.00 sec)
 
mysql> create database test2;
 
Query OK, 1 row affected (0.01 sec)
 
mysql> show databases;
 
+--------------------+
 
| Database           |
 
+--------------------+
 
| information_schema |
 
| mysql              |
 
| performance_schema |
 
| sys                |
 
| test1              |
 
| test2              |
 
+--------------------+
 
6 rows in set (0.00 sec)

 
mysql> show master status;
 
+------------------+----------+--------------+------------------+------------------------------------------+
 
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
 
+------------------+----------+--------------+------------------+------------------------------------------+
 
| mysql-bin.000001 |      478 |              |                  | eefac7d8-2370-11e9-bfeb-000c29d74445:1-2 |
 
+------------------+----------+--------------+------------------+------------------------------------------+
 
1 row in set (0.00 sec)

 
-- slave(132)
 
mysql> show databases;
 
+--------------------+
 
| Database           |
 
+--------------------+
 
| information_schema |
 
| mysql              |
 
| performance_schema |
 
| sys                |
 
| test1              |
 
| test2              |
 
+--------------------+
 
6 rows in set (0.00 sec)

 
mysql> show slave status\G;
 
*************************** 1. row ***************************
 
               Slave_IO_State: Waiting for master to send event
 
                  Master_Host: 192.168.13.131
 
                  Master_User: repl
 
                  Master_Port: 3306
 
                Connect_Retry: 60
 
              Master_Log_File: mysql-bin.000001
 
          Read_Master_Log_Pos: 478
 
               Relay_Log_File: 192-168-13-132-relay-bin.000002
 
                Relay_Log_Pos: 691
 
        Relay_Master_Log_File: mysql-bin.000001
 
             Slave_IO_Running: Yes
 
            Slave_SQL_Running: Yes
 
            ......
 
           Retrieved_Gtid_Set: eefac7d8-2370-11e9-bfeb-000c29d74445:1-2
 
            Executed_Gtid_Set: eefac7d8-2370-11e9-bfeb-000c29d74445:1-2
 

2、 在从库上创建备份

逻辑备份或物理备份都可以,这里以逻辑备份为例

mysqldump -uroot -p123456 --single-transaction --master-data=2 --all-databases > dump.sql

3、向主库写入数据

-- master(131)
 
mysql> create database test3;
 
Query OK, 1 row affected (0.00 sec)
 
mysql> show databases;
 
+--------------------+
 
| Database           |
 
+--------------------+
 
| information_schema |
 
| mysql              |
 
| performance_schema |
 
| sys                |
 
| test1              |
 
| test2              |
 
| test3              |
 
+--------------------+
 
7 rows in set (0.01 sec)
 
mysql> show master status;
 
+------------------+----------+--------------+------------------+------------------------------------------+
 
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
 
+------------------+----------+--------------+------------------+------------------------------------------+
 
| mysql-bin.000001 |      640 |              |                  | eefac7d8-2370-11e9-bfeb-000c29d74445:1-3 |
 
+------------------+----------+--------------+------------------+------------------------------------------+
 
1 row in set (0.00 sec)
 
-- slave(132)
 
mysql> show databases;
 
+--------------------+
 
| Database           |
 
+--------------------+
 
| information_schema |
 
| mysql              |
 
| performance_schema |
 
| sys                |
 
| test1              |
 
| test2              |
 
| test3              |
 
+--------------------+
 
7 rows in set (0.00 sec)
 
mysql> show slave status\G;
 
*************************** 1. row ***************************
 
               Slave_IO_State: Waiting for master to send event
 
                  Master_Host: 192.168.13.131
 
                  Master_User: repl
 
                  Master_Port: 3306
 
                Connect_Retry: 60
 
              Master_Log_File: mysql-bin.000001
 
          Read_Master_Log_Pos: 640
 
               Relay_Log_File: 192-168-13-132-relay-bin.000002
 
                Relay_Log_Pos: 853
 
        Relay_Master_Log_File: mysql-bin.000001
 
             Slave_IO_Running: Yes
 
            Slave_SQL_Running: Yes
 
            ......
 
           Retrieved_Gtid_Set: eefac7d8-2370-11e9-bfeb-000c29d74445:1-3
 
            Executed_Gtid_Set: eefac7d8-2370-11e9-bfeb-000c29d74445:1-3
 

4、产生故障

假设现在主库存放数据的磁盘发生故障,HA 将原来的从节点提升为主节点来提供数据的写入,然后插入数据

-- new master(132)
 
mysql> create database test4;
 
Query OK, 1 row affected (0.01 sec)


 
mysql> show databases;
 
+--------------------+
 
| Database           |
 
+--------------------+
 
| information_schema |
 
| mysql              |
 
| performance_schema |
 
| sys                |
 
| test1              |
 
| test2              |
 
| test3              |
 
| test4              |
 
+--------------------+
 
8 rows in set (0.00 sec)


 
mysql> show master status;
 
+------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+
 
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                                                                |
 
+------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+
 
| mysql-bin.000001 |      802 |              |                  | b66b4623-207d-11ea-a993-000c29122c12:1,
 
eefac7d8-2370-11e9-bfeb-000c29d74445:1-3 |
 
+------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+
 
1 row in set (0.00 sec)
 

5、恢复实例

用之前备份的数据来恢复挂掉的实例

-- old master(131)
 
mysql -uroot -p123456 < dump.sql

恢复后拥有的数据

mysql> show databases;
 
+--------------------+
 
| Database           |
 
+--------------------+
 
| information_schema |
 
| mysql              |
 
| performance_schema |
 
| sys                |
 
| test1              |
 
| test2              |
 
+--------------------+
 
6 rows in set (0.00 sec)

mysql> show master status;
 
+------------------+----------+--------------+------------------+------------------------------------------+
 
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
 
+------------------+----------+--------------+------------------+------------------------------------------+
 
| mysql-bin.000001 |      478 |              |                  | eefac7d8-2370-11e9-bfeb-000c29d74445:1-2 |
 
+------------------+----------+--------------+------------------+------------------------------------------+
 
1 row in set (0.00 sec)
 

6、与新主建立复制关系

-- old master(131)
 
mysql> change master to
 
    -> master_host='192.168.13.132',
 
    -> master_user='repl',
 
    -> master_password='123456',
 
    -> master_auto_position=1;
 
Query OK, 0 rows affected, 2 warnings (0.01 sec)

 
mysql> start slave;
 
Query OK, 0 rows affected (0.00 sec)

 
mysql> show databases;
 
+--------------------+
 
| Database           |
 
+--------------------+
 
| information_schema |
 
| mysql              |
 
| performance_schema |
 
| sys                |
 
| test1              |
 
| test2              |
 
| test4              |
 
+--------------------+
 
7 rows in set (0.00 sec)

 
mysql> show master status;
 
+------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+
 
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                                                                |
 
+------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+
 
| mysql-bin.000001 |      640 |              |                  | b66b4623-207d-11ea-a993-000c29122c12:1,
 
eefac7d8-2370-11e9-bfeb-000c29d74445:1-2 |
 
+------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+
 
1 row in set (0.00 sec)
 

现象

可以观察到,在旧主通过备份恢复数据且加回到集群后,丢失了部分的数据。操作的步骤看起来并没有问题,那么原因是什么呢?

丢失的事务的 GTID 是 eefac7d8-2370-11e9-bfeb-000c29d74445:3,我们先到新主的 binlog 中看下是否还有这个事务的记录,保证 binlog 没有被清理。

#200220 14:19:41 server id 1  end_log_pos 543 CRC32 0x3fa9fb8c  GTID    last_committed=2        sequence_number=3       rbr_only=no
 
SET @@SESSION.GTID_NEXT= 'eefac7d8-2370-11e9-bfeb-000c29d74445:3'/*!*/;
 
# at 543
 
#200220 14:19:41 server id 1  end_log_pos 640 CRC32 0x8427b0a3  Query   thread_id=4     exec_time=0     error_code=0
 
SET TIMESTAMP=1582179581/*!*/;
 
create database test3
 
/*!*/;
 

新主的 binlog 中是有这个事务的,那接着我们再来看下旧主的 relaylog 中是否也同样记录。但意外的是,relaylog 中并没有相关的记录,说明这个事务根本没有写进 relaylog。

那么我们可以回想一下,在 MySQL 里面,有没有类似的机制或者参数让主库的 binlog 在传输或写入从库的过程中被过滤掉。正好我们发现,开启 binlog 必须要配置的 server_id 就能起到这样的作用。

分析

由于我们在恢复实例的时候使用的备份集不是最新的备份集,这个备份集中只含有 eefac7d8-2370-11e9-bfeb-000c29d74445:1-2 两个事务,那么恢复回来的实例加入集群变成从实例的时候,需要通过新主库的 binlog 来补偿数据。

在传输事务 eefac7d8-2370-11e9-bfeb-000c29d74445:3 的时候,从实例的 io_thread 发现这个事务记录的 server_id 为 1,与自己的 server_id 一致,会认为这个是自己执行过的事务,就会把这段信息给过滤掉,最终这个从实例的数据就会缺少一部分。

总结

由此可见,在这种情况下,更换 server_id 是最简单的解决办法,所以我们在恢复实例的时候,尽可能的去修改 server_id,保证 server_id 不与之前的重复且与集群中的其他实例不相同。

有不少人并没有碰到类似的问题,是因为他们在恢复实例的时候,通常是直接在线备份线上的实例,用最新的备份集来导入数据,在这种情况下,也可以避免以上问题的发生。

另外还有一个值得一提的参数 --replicate-same-server-id,这个参数的作用是开启后即使 io_thread 收到与自己 server_id 相同的 binlog,也会写入 relaylog。虽然启用这个参数也可以避免以上问题,但在大部分情况下都不推荐开启这个参数,默认值 OFF 是为了避免 binlog 在复制中回环。在 5.7 中想开启这个参数的话需要先关闭 log_slave_updates;8.0 则做了改进,当 gtid_mode=ON 的情况下就可以开启。

参考: https://lefred.be/content/mysql-gtid-restore-a-master-from-a-replicas-backup/ https://www.zhangshengrong.com/p/yOXD5zZM1B/ https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#optionmysqldreplicate-same-server-id

本文分享自微信公众号 - 爱可生开源社区(ActiontechOSS),作者:林靖华

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-03-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 技术分享 | MariaDB 10.1.9 迁移到 MySQL 5.7.25

    爱可生 DBA 团队成员,负责项目日常问题处理及公司平台问题排查,对数据库有兴趣,对技术有想法。一入 IT 深似海,从此节操是路人。

    爱可生开源社区
  • 技术分享 | 七个实验掌握 MySQL 8.0 角色功能

    资深数据库专家,专研 MySQL 十余年。擅长 MySQL、PostgreSQL、MongoDB 等开源数据库相关的备份恢复、SQL 调优、监控运维、高可用架构...

    爱可生开源社区
  • 第05期:外键到底能不能用?

    外键的设计初衷是为了在数据库端保证对逻辑上相关联的表数据在操作上的一致性与完整性。

    爱可生开源社区
  • MySQL的安装、启动和基础配置 —— mac版本

    第一步:打开网址,https://www.mysql.com,点击downloads之后跳转到https://www.mysql.com/downloads/选...

    changxin7
  • MySQL远程代码执行/权限提升漏洞的分析与实践(CVE-2016-6662)

    本文作者:安全小飞侠,原文链接:http://avfisher.win/archives/593 0x00 背景 2016年9月12日,国外安全研究人员Dawi...

    Seebug漏洞平台
  • Mac 下 MySQL5.7.22的安装

    1.使用安装包安装mysql(网上下载实在是太慢了,需要安装包的可以在文章底部留言,我发给您) 双击打开安装文件 ? 双击pkg文件安装 一路向下,记得保存最后...

    JavaEdge
  • mysql 8本地源码安装注意事项

    yum -y install wget cmake gcc gcc-c++ ncurses ncurses-devel libaio-deve...

    算法之名
  • 2分钟玩转腾讯云+yum+mysql实战

    linux上原始安装mysql操作是非常复杂的还容易出错,今天就是用yum来安装mysql是比较简单的。目前只需要准备一个服务器和一个链接工具就好了。如果没有链...

    用户5224393
  • 【防止被脱裤】如何在服务器上设置一个安全的 MySQL

    在进行真正的 mysql 部署之前,我们不妨先来大致了解下,在实际入侵过程中,仅仅利用mysql,我们到底能干些什么,了解了这些最基本的点之后,我们再进行针对性...

    HACK学习
  • CentOS安装mysql

    第二步,进入/usr/local/soft/目录,在里面执行wget 下载链接命令,或者是先下载到windows然后通过xftp上传到CentOS的该目录下,然...

    编程思录

扫码关注云+社区

领取腾讯云代金券