全量备份用 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读取非默认路径下的备份文件。
