MySQL备份与恢复需确保一致性、日志依赖和恢复边界：mysqldump须用--single-transaction或--lock-all-tables保证一致性；必须备份binlog并推荐GTID实现精确恢复；物理备份须用XtraBackup等工具，禁用直接cp/rsync；恢复后须重置复制信息并验证同步状态。
MySQL备份与恢复不是“导出再导入”那么简单，很多看似稳妥的操作，实际埋着数据丢失、恢复失败或主从不一致的隐患。关键在于理解备份一致性、日志依赖和恢复边界。
误以为 mysqldump 导出就等于“全量备份”
mysqldump 默认不锁表（--lock-tables=false），在高并发写入场景下，导出的 SQL 文件各表数据可能来自不同时间点，导致逻辑不一致。例如：订单表导出时已包含新订单，但关联的用户表还没更新该用户信息，恢复后出现外键断裂或业务校验失败。
- 对一致性要求高的库，必须加 --single-transaction（仅对 InnoDB 有效），利用 MVCC 获取一致性快照
- 若含 MyISAM 表或需强一致，应配合 --lock-all-tables，但会阻塞写入，需评估业务窗口
- 务必加上 --routines --triggers --events，否则存储过程、触发器等元数据丢失
忽略二进制日志（binlog）的备份与定位
只备份数据文件或 dump 文件，等于放弃“任意时间点恢复”能力。没有 binlog，你只能回滚到上次备份时刻，中间所有变更全部丢失。
- 确认 log_bin=ON 已启用，并定期归档 binlog 文件（如用 mysqlbinlog --read-from-remote-server 或 rsync + 清理策略）
- 恢复时不能只靠 position 恢复，推荐用 GTID（需开启 gtid_mode=ON），避免因主从切换、日志轮转导致 position 错位
- 执行 SHOW MASTER STATUS 和 SHOW BINLOG EVENTS 配合备份时间戳，精准定位起始位置
直接用 cp/rsync 备份运行中的数据目录
InnoDB 数据文件（ibdata1、ib_logfile*、.ibd）在 MySQL 运行时处于持续写入状态，直接拷贝会产生不一致的物理文件，启动时大概率报错 “InnoDB: Database page corruption” 或无法识别表空间。
- 若要用物理备份，必须使用 Percona XtraBackup（支持热备、压缩、流式）或 mysqlbackup（MySQL Enterprise Backup）
- 即使停库备份，也要确保 innodb_fast_shutdown=0，让 InnoDB 彻底刷脏页并关闭，否则恢复时仍可能损坏
- 备份后务必验证：用备份文件启动临时实例 + 执行 CHECK TABLE，或用 xtrabackup --apply-log 检查日志回放是否成功
恢复时没重置复制信息，导致主从错乱
从备份恢复一台从库后，若未正确设置复制起点（尤其是 GTID_PURGED 或 master_log_file + master_log_pos），会导致从库跳过部分事件或重复执行，最终与主库数据不一致。
- mysqldump 备份默认包含 SET @@GLOBAL.GTID_PURGED 语句（需加 --set-gtid-purged=ON），恢复后该语句自动生效；若手动关闭，必须在恢复后执行 RESET MASTER; SET GTID_PURGED = 'xxx';
- 传统 binlog 位点恢复，需在 CHANGE MASTER TO 前执行 STOP SLAVE;，且 MASTER_LOG_FILE 必须是备份时刻对应的 binlog 名（非当前正在写的那个）
- 恢复完成后，用 SHOW SLAVE STATUS\G 检查 Seconds_Behind_Master、IO/SQL 线程状态，再查 SELECT MASTER_POS_WAIT() 确认同步无延迟
备份不是一次性动作，而是“策略+验证+演练”的闭环。没经过恢复测试的备份，和没备份一样危险。
