千万级库灾备演练必须用XtraBackup物理备份而非mysqldump，因后者恢复慢、锁表风险高、不保GTID；须验证prepare成功、binlog校验通过、临时实例数据一致；binlog定位需依end_log_pos而非时间；演练后须查索引一致性、JSON有效性及自增ID连续性。
千万级库容灾演练不能照搬小库流程，核心卡点在恢复耗时、binlog解析精度、以及备份与生产环境的一致性验证——不跑通全链路，大促当天就可能RTO超4小时。
为什么 mysqldump 恢复在千万级库上基本不可行
不是语法错，是物理现实压垮流程：一个 20GB 的 mysqldump 全量 SQL 文件，在普通 SSD 上导入通常要 1.5–3 小时；若含索引重建、外键约束、触发器，时间翻倍。更致命的是，mysqldump 默认不带 --single-transaction 时会锁表，而加了该参数后，若存在长事务或非 InnoDB 表，仍可能卡住或不一致。
- 实测案例：某电商用户积分库（1200万行，18GB），
mysqldump导入耗时 227 分钟，期间无法提供读服务 - 风险点：
mysqldump不保留 GTID_EXECUTED，跨主从切换后易引发同步中断 - 替代方案必须用物理备份：Percona XtraBackup 是唯一能支撑 TB 级、分钟级 RTO 的生产级工具
演练前必须验证的三个备份有效性硬指标
很多团队“有备份”但“没验证”，演练一跑就崩。以下三项必须在演练前完成，且记录 timestamp：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
xtrabackup --prepare --target-dir=/backup/full要成功返回，且输出中含completed OK!—— 否则说明备份时 redolog 截断异常 - 用
mysqlbinlog --verify-binlog-checksum /var/lib/mysql/mysql-bin.000123校验最近 3 个 binlog 文件无 CRC 错误，否则增量恢复必丢数据 - 从备份启动一个临时实例，执行
SELECT COUNT(*) FROM important_table并与生产库比对，误差 >0.1% 即判定备份不完整（常见于mysqldump未加--skip-lock-tables导致部分表被跳过）
千万级库恢复中 binlog 定位最易出错的两个细节
误删发生在凌晨 2:15，你却用 --start-datetime="2026-11-04 02:15:00" 开始解析？大概率跳过关键事件——因为 binlog 记录的是 commit 时间，而非语句执行起始时间，且存在主从延迟、批量提交等扰动。
- 正确做法：先查误删事务的
gtid_set，用SHOW BINLOG EVENTS IN 'mysql-bin.000123' FROM 12345 LIMIT 20定位到Delete_rows事件的end_log_pos，再以该位置为--stop-position - ROW 格式下必须加
--base64-output=DECODE-ROWS -v，否则生成的 SQL 是乱码，sed替换会失效 - 切记：解析出的
recovery_data.sql必须先在沙箱库执行source recovery_data.sql验证语法和主键冲突，不能直灌生产
演练后必须检查的“隐形断点”
数据行数对得上 ≠ 数据可用。千万级业务库最常忽略的是二级索引一致性、JSON 字段校验、以及自增 ID 断层。
- 执行
SELECT COUNT(*) FROM important_table USE INDEX (PRIMARY)和USE INDEX (idx_status)对比，若差异 >0，说明索引未同步更新 - 对含 JSON 字段的表，抽查 10 条记录执行
JSON_VALID(content)，避免 binlog 解析时损坏结构 - 检查
SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t'，确认自增值已推进到故障点之后，否则后续 INSERT 会报主键冲突
