mysqldump 备份是否还够用？
在单机或主从架构下，
mysqldump仍是主流逻辑备份手段，但它的适用边界正在收窄。它会锁表（除非加
--single-transaction且引擎为 InnoDB），备份大库时可能拖慢线上查询；恢复只能全量，无法按时间点回滚；备份文件是 SQL 文本，压缩率低、网络传输慢。
实操建议：
仅对小于 50GB 的库、RPO 要求宽松（可接受小时级丢失）的场景用mysqldump务必配合
--single-transaction --routines --triggers --databases，避免漏存过程和触发器 不要依赖
mysqldump做高可用切换后的数据校验——它不保证一致性快照与 binlog 位点严格对齐
物理备份为什么推荐 Percona XtraBackup？
xtrabackup是目前 MySQL 生产环境事实标准的物理备份工具，核心价值在于热备、增量、快速恢复。它直接拷贝 InnoDB 数据文件，同时记录
lsn和
binlog position，能精确对接主从或 PITR（基于时间点恢复）。
关键注意点：
8.0 版本必须用percona-xtrabackup-80，与官方 MySQL 8.0.33+ 的 redo log 格式兼容，旧版会报错
Invalid log block checksum增量备份依赖上一次全备的
xtrabackup_checkpoints，路径不能丢、不能手动修改 备份后必须执行
xtrabackup --prepare（尤其增量链），否则恢复时会提示
Log block checksum mismatch
高可用架构下，备份该打在哪个节点？
不是“随便选个从库”，而是必须避开流量入口和复制延迟敏感节点。典型错误是把备份任务放在 VIP 指向的读写分离中间件后端从库上，导致备份 IO 抢占查询资源，触发中间件自动摘除该节点。
推荐方案：
专用备份从库：独立部署、不接入任何业务流量，配置read_only=ON+
super_read_only=ON，并关闭
innodb_flush_log_at_trx_commit=2（降低刷盘压力） 跳过 SQL 线程备份：在备份前执行
STOP SLAVE SQL_THREAD，等
Seconds_Behind_Master = 0后再启停，确保 binlog 位点与数据文件完全一致 禁止在 MGR 或 Orchestrator 自动切换集群中对 primary_candidate 节点跑长时间备份——它可能在备份中途被升为主
备份验证比备份本身更容易被忽略
90% 的备份失效发生在恢复环节。没验证过的备份等于没备份。常见假象包括：备份脚本返回 0 但实际只备份了部分库；
xtrabackup日志里出现
Warning: Failed to read from /proc/sys/vm/swappiness导致内存不足中断；或者备份后忘记
--copy-back时指定
--force-non-empty-directories，恢复失败却不报警。
最低成本验证方式：
每日随机抽一个备份集，在隔离环境执行完整恢复流程（含--prepare和
--copy-back），并连上 MySQL 验证
SELECT COUNT(*) FROM mysql.user是否可查 所有备份任务必须配置超时（如
timeout 7200 xtrabackup ...）和退出码检查，失败立即通知 备份元信息（时间、大小、binlog_file/pos、checksum）要落库或写入 Prometheus，便于交叉比对
备份策略不是静态配置，它得跟着你的主从延迟毛刺、大事务频率、磁盘 IOPS 波动实时调优。每次扩容从库、升级 MySQL 小版本、切换高可用组件前，都要重跑一遍备份恢复验证。
