MySQL 删库到恢复 失误删库不一定要跑路，只要有合理的备份策略，绝大多数情况都可以恢复到删库之前的那一刻。如果要恢复，一般采用的办法是使用上一次全备先恢复数据，增量数据通过导入从全备开始到误操作之前的 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。在目标实例上查询数据（此时的数据已经恢复到误操作前一刻）： 最终可以将误删除的库恢复到原实例。