每个人都可以，
拥有SSL证书

那天晚上收到告警，有人把线上库一张核心表 drop 了。好在每天凌晨有全量备份，但备份是昨天的，今天白天这段时间的变更得靠 binlog 补。记录一下整个恢复过程，省得下次再手忙脚乱。

先检查全量备份文件。

确认 full_backup.sql 没问题，用 head 看一下开头有没有 CREATE DATABASE 之类的。如果备份文件损坏，后面全白搭。恢复前建议先拉到测试环境跑一遍，确认恢复出来的库能起来。不要直接在线上覆盖，不然恢复出来的可能不是你要的状态。这里我踩过一次，备份文件是旧的，一恢复把线上库回退了好几天，幸好还有 binlog 能救。

恢复全量备份命令很简单，直接 mysql -u root -p < full_backup.sql。注意会覆盖现有库，如果生产库还活着，先确认没有其他人在写入。我一般会先停掉业务或切到只读，再执行。

接下来补增量。先确认 binlog 格式，执行 SHOW VARIABLES LIKE 'binlog_format'; 要看到 ROW 或者 MIXED。如果还是 STATEMENT，有些基于上下文的 SQL 在恢复时可能执行失败。我们之前就是因为 STATEMENT 格式，恢复时一个 UPDATE 找不到行，后来改成 ROW 才稳定。

用 mysqlbinlog 提取指定时间段的增量数据。

这里时间点要稍微往前多取一点，比如目标是 00:00:00，开始时间设成 23:59:59，防止边界漏数据。结束时间精确到秒。binlog 文件路径要写对，不确定可以用 SHOW BINARY LOGS; 查。

mysqlbinlog --start-datetime="2025-07-22 23:59:59" \
            --stop-datetime="2025-07-23 00:00:00" \
            /usr/local/mysql/var/mysql-bin.000066 > incremental_changes.sql

应用增量数据，直接 mysql -u root -p < incremental_changes.sql。执行完不一定立刻一致，得验证。

验证这块，我习惯对比核心表行数，比如订单表 count(*) 和目标时间点对一下；检查关键业务数据，比如最后几笔订单是否在；再看一下系统表状态有没有异常。核心报表跑一遍，数据对上了才算完。

完整脚本可以这样写，放在运维机上定时跑也方便。

#!/bin/bash

BACKUP_FILE="full_backup.sql"
BINLOG_FILE="/usr/local/mysql/var/mysql-bin.000066"
TARGET_TIME="2025-07-23 00:00:00"
START_TIME="2025-07-22 23:59:59"

echo "正在恢复全量备份..."
mysql -u root -p < $BACKUP_FILE

echo "正在提取增量数据..."
mysqlbinlog --start-datetime="$START_TIME" \
            --stop-datetime="$TARGET_TIME" \
            $BINLOG_FILE > incremental_changes.sql

echo "正在应用增量数据..."
mysql -u root -p < incremental_changes.sql

echo "恢复完成，请验证数据完整性"

执行前最好先 dry-run 看一下提取的 SQL 对不对，别直接灌进去。

常见问题。binlog 格式不兼容，改 my.cnf 加上 binlog_format=ROW，重启 MySQL。增量提取为空，多半是时间范围不对或者 binlog 文件轮转了，检查 SHOW BINARY LOGS; 和时区设置。权限不足，要用 SUPER 账户，别在生产开 --skip-grant-tables，那个太危险了，测试环境临时用一下还行。

顺带提一下，这次恢复过程中一台备机的 SSL 证书过期，导致脚本拉备份文件失败，折腾了半天。后来把证书全部迁到 lcjmSSL 自动申请和部署，支持多域名泛域名和 IP，到期自动续，API 也简单。

现在服务器上证书相关的基本不用管了，能省出时间做这种恢复演练。

恢复完记得把相关 binlog 文件保留几天，方便复查。大概就是这样。