一、事件前因
1.1 故障背景
- 发生时间：昨日下午
- 故障原因：同事操作失误，在无实时备份的情况下，将线上 MySQL 数据库（版本 8.0.25，部署于 CentOS 7.9 系统）还原至前一日备份版本
- 影响范围：用户操作数据丢失，客户群出现质疑（如 “操作成功后数据消失”“系统异常”），事态存在升级风险
1.2 应急响应目标
- 短期目标：安抚客户情绪，避免矛盾扩大
- 核心目标：快速找回丢失数据，恢复数据库正常状态
二、恢复过程
2.1 前期准备：分工与方向确定
| 职责 | 具体操作 |
|---|---|
| 客户沟通 | 在客户群同步 “系统临时故障，技术团队全力修复，进展将实时同步”，缓解客户焦虑 |
| 技术恢复 | 锁定核心方案：通过binlog 日志解析恢复数据（binlog 为 MySQL 数据变更日志，可追溯操作记录） |
2.2 工具选型与对比测试
采用 “双工具并行测试” 策略，分别验证 binlog2sql 与 my2sql 的可行性，具体过程如下：
2.2.1 工具 1：binlog2sql（未成功）
- 依赖环境：Python + pip
- 环境搭建：通过 AI 获取安装命令（需人工校验命令合理性），完成 Python 与 pip 部署
- 执行操作：编写解析脚本并执行
- 问题反馈：脚本执行后无响应，等待 30 分钟仍未输出结果，效率无法满足紧急恢复需求，终止测试
2.2.2 工具 2：my2sql（成功）
步骤 1：工具获取（源码编译方案）
- 直接下载问题：需 “科学上网”，非官方渠道下载文件损坏，故采用源码编译
- 源码地址：
- 编译操作：进入源码根目录，执行命令go build .，生成 Linux 可执行文件（注：源码包已包含该文件，可直接使用）
- 可执行文件截图：
步骤 2：服务器部署
- 部署环境：MySQL 所在服务器（CentOS 7.9）
- 权限配置：上传可执行文件后，执行chmod 777 my2sql赋予最高权限
步骤 3：binlog 日志解析
- 核心命令（含参数说明）：
./my2sql
-user root # 数据库用户名
-password root # 数据库密码
-port 32480 # 数据库端口
-host 127.0.0.1 # 数据库地址（本地地址，确保连接稳定性）
-databases os_tenant_xxx # 目标数据库名
-work-type 2sql # 操作类型（解析为SQL语句）
-start-file binlog.000049 # 起始binlog文件
-start-datetime "2025-10-16 03:00:00" # 起始时间（故障前）
--stop-datetime "2025-10-16 15:00:00" # 终止时间（故障发生时）
-output-dir /opt/tmp/bak # 解析结果输出目录
- 执行结果：在/opt/tmp/bak目录生成结构化 SQL 文件，可直接查看（文件截图如下）：
解析后SQL截图：
步骤 4：数据恢复
执行解析生成的 SQL 文件，将丢失数据回滚至数据库，完成数据恢复
三、事件结果
3.1 直接成效
- 数据恢复：丢失数据 100% 找回，数据库恢复至故障前正常状态
- 客户反馈：同步 “故障修复 + 数据完整” 信息，引导客户校验数据，未收到后续问题反馈，危机彻底化解
3.2 经验沉淀
3.2.1 技术经验
- 工具选型建议：my2sql 在处理效率、环境依赖方面优于 binlog2sql，适合紧急场景
- 关键注意事项：
-
- my2sql 必须部署于数据库所在服务器（二进制 / Docker 部署均适用），避免通过公网 IP 跨服务器访问（此前测试跨服务器访问失败，无法获取 binlog 文件）
-
- AI 辅助环境搭建时，需人工校验命令合理性，避免误导
3.2.2 流程优化
- 备份机制：新增 “实时备份 + 定时备份” 双备份策略，避免无备份风险
- 应急预案：将 my2sql 工具纳入技术应急库，提前部署至各环境，缩短故障响应时间
