生产Mysql数据库数据恢复实战

重要数据请联系兆柏数据恢复公司

线上环境

    mysql数据库一主多从的架构，主写从读进行读写分离，专用从库做数据备份，每天0点全备一次，12点增量备份一次，初始阶段数据量很小的情况按此方案，后续数据量大，读写频繁时，再进行相关调整，增加增量备份频次

系统环境

[root@mysql-1 ~]# cat /etc/redhat-release 

CentOS release 6.8 (Final)

[root@mysql-1 ~]# uname -r

2.6.32-642.el6.x86_64

[root@mysql-1 ~]# mysql -v

mysql  Ver 14.14 Distrib 5.7.17, for linux-glibc2.5 (x86_64) using  EditLine wrapper

主从同步

 3306---->3307 

3307 开启binlog日志，用做备份服务器，0点全备，12点增量备份

[root@mysql-1 ~]# netstat -lntup|grep 33

tcp 0 0 :::3306  :::* LISTEN  42473/mysqld        

tcp  0 0 :::3307  :::*  LISTEN  42769/mysqld

2   模拟线上数据写入

数据库同步完成，开启3307从库的binlog日志功能

查看目前的日志文件

写入数据测试同步

注：查看日志文件修改时间发现有数据写入

此时执行全备文件

全备之后写入数据

此时出现误操作删除了一个数据

出现误操作不可能第一时间发现，因此，继续写入数据

此时发现数据库数据出现问题，某个数据无法访问了，需要进行恢复

3  恢复数据

数据恢复具体操作如下

1、停止主从同步，应用与数据库的读写操作，防止数据再次写入

2、刷新binlog，生成新的日志文件

3、恢复全备文件到主库

4、合并binlog文件生成sql，删除误操作语句

5、进行增量恢复

此时主库数据恢复成功

4  测试主从同步

重新开启同步来测试数据是否同步

ySQL 删库到恢复

失误删库不一定要跑路，只要有合理的备份策略，绝大多数情况都可以恢复到删库之前的那一刻。如果要恢复，一般采用的办法是使用上一次全备先恢复数据，增量数据通过导入从全备开始到误操作之前的 Binlog，但是这种方式如果 Binlog 多，通常是比较慢的，并且很容易导入到一半时报错，这篇文章就介绍另外一种方式进行误操作的恢复。环境IP作用环境192.168.150.253源实例（误操作的实例）CentOS 7.4、已安装 MySQL 8.0.25、已安装 XtraBackup 8.0.25192.168.150.123目标实例（用于恢复数据）CentOS 7.4、已安装 MySQL 8.0.25、已安装 XtraBackup 8.0.25大致过程：在源实例写入基础数据，然后进行全量备份，再写入增量数据，之后模拟在源实例误删除一个数据库，之后通过全量备份在目标实例上进行恢复，把源实例的 Binlog 传输到恢复数据的实例，然后修改成 relay log，再通过 start slave sql_thread until sql_before_gtids="xxx" 同步数据到误操作前面的一个位点。在源实例创建测试库和测试表：

写入数据：

查询数据：

在源实例增加备份用户：

在源实例进行全量备份：

将全量备份传到目标实例上：

在源实例写入一条数据：

在源实例模拟删库误操作：

关闭目标实例运行的 MySQL：

清空目标实例数据目录和事务日志目录：

将全备导入目标实例：

修改目标实例 MySQL 数据目录的属主：

修改配置文件 /data/mysql/conf/my.cnf（配置启动时不启动复制、relay log 元数据通过文件形式记录，server-id 不能跟原实例相同）：

启动 MySQL：

查看数据（此时只是恢复了全量数据，所以数据不完整）：

清空目标实例的系统变量 gtid_purged 和 gtid_executed：

设置 gtid_purged（这个位点取至 xtrabackup_binlog_info）：

让该 MySQL 知道自己是一个从库（192.168.1.1 是随便指定的 IP）：

关闭目标实例：

删除该实例的 relay-log.info：

删除所有 relay log：

拷贝源实例 MySQL 全备之后的 Binlog：

在目标实例中，将 Binlog 改成 Relay 文件：

写入 relay log 的索引文件：

查看  relay log 的索引文件：

修改事务日志目录下文件的属组：

启动目标实例：

执行 change master：

(这个位点来源于 备份 xtrabackup_binlog_info)解析误操作时间点的 Binlog（Binlog 较大的情况可以增加时间范围）：

解析 Binlog 的结果文件 /data/0702.sql 内容如下：

启动 sql 线程，同步数据到误操作之前的一个事务：

该 gtid 值取至上面解析的 Binlog，为误操作这个事务的 GTID。在目标实例上查询数据（此时的数据已经恢复到误操作前一刻）：

最终可以将误删除的库恢复到原实例。

至此，整个数据恢复过程结束，通过binlog日志增量文件恢复数据成功