生产环境全量备份优先选mysqlbackup，因其支持热备、压缩、加密且不影响主库；社区版可用mysqldump（需加--single-transaction等参数）或percona xtrabackup。
全量备份用 mysqldump 还是 mysqlbackup？
生产环境优先选 mysqlbackup（MySQL Enterprise Backup），它支持热备、压缩、加密，且备份期间不影响主库读写。但它是商业版组件，社区版用户只能用 mysqldump 或 Percona XtraBackup。
mysqldump 简单但有明显限制：
– 备份期间对大表会加 READ LOCK（除非用 --single-transaction 且引擎为 InnoDB）
– 不支持并行、不支持压缩传输、恢复速度慢
– 导出的是 SQL 文本，不是物理文件，无法用于快速挂载恢复
- 若用
mysqldump，必须加--single-transaction --routines --triggers --events - 务必排除
information_schema、performance_schema、sys库（它们不能被 dump） - 导出后建议用
gzip压缩：mysqldump ... | gzip > full_$(date +%F).sql.gz
增量备份依赖 binlog，但开启前必须确认三件事
MySQL 本身没有“增量备份”命令，所谓增量，本质是开启并持续归档 binlog，再配合上一次全备做 PITR（基于时间点恢复）。启用前需检查：
-
log_bin必须为ON（查看SHOW VARIABLES LIKE 'log_bin';） -
binlog_format推荐设为ROW（STATEMENT在某些函数或非确定性语句下无法精确回放） -
expire_logs_days或binlog_expire_logs_seconds要设足够大，确保覆盖最长恢复窗口（例如设为 7 天，即604800）
归档脚本示例（每日截断并拷贝新 binlog）：mysql -e "FLUSH BINARY LOGS;"cp /var/lib/mysql/mysql-bin.* /backup/binlog/
注意：不要直接 cp 正在写的 mysql-bin.0000xx，要用 mysqlbinlog --read-from-remote-server 拉取或依赖 FLUSH 后的归档逻辑。
恢复时最容易漏掉的两个步骤
全量 + 增量恢复不是简单执行 SQL 文件就完事。常见失败原因是跳过了这两步：
- 全量恢复后，必须先
SET SQL_LOG_BIN = 0;，否则重放 binlog 时会再次写入 binlog，导致循环或日志爆炸 - 用
mysqlbinlog解析时，要指定起始位置或时间，且注意时区：mysqlbinlog --start-datetime="2024-05-20 03:00:00" --database=myapp mysql-bin.000012 | mysql -u root
如果不知道从哪开始重放，查全备文件末尾的 CHANGE MASTER TO 注释（mysqldump 默认输出），或用 show binlog events in 'mysql-bin.000011' limit 1\G 找第一个事件时间。
备份计划不能只看频率，关键在验证与隔离
每周全备 + 每日 binlog 归档只是纸面策略。真正决定成败的是：
- 每月至少一次还原演练：把备份拉到隔离环境，完整走一遍恢复流程，记录耗时与报错
- 备份文件必须与生产网络隔离（如存到对象存储、离线 NAS），防止勒索软件一并加密
- 所有备份需校验完整性：
gunzip -t full_2024-05-20.sql.gz，对 binlog 用mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000012 | head -20看是否可解析
最常被忽略的是权限与 SELinux —— 备份脚本用 root 运行没问题，但恢复时若用普通账号，可能因 FILE 权限缺失无法加载本地文件，或 SELinux 阻止 mysqld 读取非默认路径下的备份文件。
