合规备份必须使用--master-data=2以记录binlog位置实现5分钟PITR，配合ROW格式、完整binlog归档、加密分离、专用账号及元数据留痕。
mysqldump 本身不满足合规性，必须配合特定参数、流程和元数据管理才能过关。光有备份文件没用，审计时第一句就问：“能还原到昨天14:37吗？”
为什么 --master-data=2 是硬性门槛
合规要求支持5分钟粒度时间点恢复（PITR），这依赖全量备份与 binlog 的精确对齐。--master-data=2 会在 dump 文件头部写入类似 CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000042', MASTER_LOG_POS=19876543; 的注释——这是后续 PITR 的起点坐标。不用它，备份文件里没有 binlog 位置，等于扔掉了时间轴锚点。
- 别用
--master-data=1：它把CHANGE MASTER写成可执行语句，可能被误执行导致主从错乱 - 别依赖
SHOW MASTER STATUS单独记录：执行时机和 dump 开始时间有微小偏移，位置不准 - 如果用了
--single-transaction，确保库中无 DDL 操作；否则事务快照会卡住，--master-data=2记录的位置可能滞后于实际
binlog 必须是 ROW 格式且归档完整
STATEMENT 或 MIXED 格式在 UUID()、NOW()、存储过程等非确定性场景下无法精确重放，直接导致 PITR 失败。合规检查会抽样验证关键语句的 binlog event 类型。
- 确认方式：
SELECT @@binlog_format;返回必须是ROW - 归档不能只靠
expire_logs_days：它按文件创建时间删，而 binlog 文件可能写满后才滚动，最后写入时间远晚于创建时间。必须用PURGE BINARY LOGS BEFORE '2026-06-25 00:00:00';手动控制 - 归档目标（如 S3）需保留至少 7 天内所有 binlog 文件，且文件名不得重命名或压缩后丢弃原始时间戳
备份文件加密与元数据必须分离落地
明文备份文件在审计中一票否决。MySQL 不提供备份加密能力，必须由外部机制兜底，且密钥不能和备份共存。
- 加密命令示例：
mysqldump -u backup_user -p db_name | openssl enc -aes-256-cbc -pbkdf2 -iter 100000 -out backup.sql.enc，但密钥不能存在同一台服务器上 - 禁止用
--all-databases：某个库权限不足或损坏会导致整个备份中断；应循环执行mysqldump -B db_name，失败单库隔离 - 每次成功备份后，必须向独立数据库的
backup_meta表插入一行，含end_time、binlog_pos、file_path、checksum；清理脚本只能查这张表，不能靠ls -t或文件名时间戳
权限与执行用户必须严格隔离
用 root 或 mysql 用户跑备份，等于把钥匙和锁放一起。合规检查会直接查看进程属主和备份目录 ls -ld 权限。
- 创建专用账号：
CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'StrongPass@123'; GRANT SELECT, LOCK TABLES, RELOAD, REPLICATION CLIENT, PROCESS ON *.*; - 系统层面：备份目录
/backup/mysql属主设为backup用户，权限700；禁止mysql用户对该目录有读写权 - 备份脚本本身不能包含明文密码；推荐用
~/.my.cnf（权限600）配 credential，且该文件属主也必须是backup用户
