备份前必须加--single-transaction且显式指定--set-gtid-purged=OFF，因mysqldump默认不保证GTID安全性，还原时易因GTID_PURGED冲突致主从断裂；跨机房容灾需严格校验、加密及命名规范以保障一致性与可恢复性。
备份前必须加 --single-transaction 且显式指定 --set-gtid-purged=OFF
跨机房容灾对数据一致性要求极高，mysqldump 默认不保证 GTID 安全性，还原时可能因 GTID_PURGED 冲突导致主从断裂。尤其当源库启用了 GTID（gtid_mode=ON），而目标对象存储只是归档用途、不参与复制链路时，必须禁用自动注入 GTID 信息。
常见错误现象：mysql 还原时报错 ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty，或后续接入新从库时跳过事务失败。
-
--single-transaction是安全前提：确保备份期间读取一致快照，避免锁表又不影响线上写入 -
--set-gtid-purged=OFF必须显式加，不能依赖版本默认行为（MySQL 5.7 默认 ON，8.0 默认 AUTO） - 若需保留 GTID 用于后续构建复制，改用
--set-gtid-purged=ON+ 手动记录SELECT @@global.gtid_executed;输出，单独存为元数据文件
加密不能只靠 gzip，得用 gpg 或 openssl aes-256-cbc
对象存储（如 AWS S3、阿里云 OSS、腾讯云 COS）本身不校验或解密上传内容，gzip 压缩 ≠ 加密，仅防传输中被截获是不够的；真实威胁来自存储桶权限误配、内部人员越权访问、或合规审计要求（等保三级、GDPR）。
推荐用 gpg 对称加密，密钥由运维离线保管，不硬编码进脚本：
mysqldump -u root -p --single-transaction --set-gtid-purged=OFF mydb | \ gpg --cipher-algo AES256 --compress-algo 1 --symmetric --armor --passphrase-fd 0 \ > mydb_$(date +%Y%m%d_%H%M%S).sql.asc
注意点：
-
--passphrase-fd 0表示从 stdin 读密码，可配合echo "xxx" |或交互输入，避免明文出现在进程参数里 - 别用
openssl enc -aes-128-cbc：128 位密钥在部分合规场景不达标，强制选-aes-256-cbc - 加密后文件扩展名建议用
.sql.asc（ASCII armored）或.sql.gpg，避免和未加密压缩包混淆
同步到对象存储时必须启用服务端加密（SSE）+ 传输层强制 HTTPS
即使本地已加密，上传过程仍可能被中间人嗅探（尤其跨公网机房），且对象存储默认不开启加密存储，一旦桶策略泄漏，密文文件也可能被批量下载后离线爆破。
实操关键项：
- CLI 工具必须用最新版（
aws-cli v2/ossutil v5+），旧版本不默认校验证书或忽略 SSE 参数 - 上传命令中显式指定加密方式：
aws s3 cp --sse AES256 file.sql.gpg s3://bucket/... - 禁止使用
http://endpoint，所有配置项检查是否含https://，ossutil需确认endpoint配置以https开头 - 对象存储 bucket 策略应拒绝非 HTTPS 请求（
"s3:SecureTransport": false拒绝）
备份文件名必须含时间戳、校验码、环境标识
跨机房容灾不是“有备份就行”，而是“能快速定位、验证、还原指定时刻的正确副本”。纯靠人工翻找 mydb_backup.sql.gpg 极易出错，尤其当多个机房、多套环境（prod/staging）、每日多轮备份并行时。
命名规范直接决定恢复效率：
- 格式示例：
mysql_prod_mydb_20261014_163022_sha256_9a3f...8c1d.sql.gpg - 时间戳用
$(date +%Y%m%d_%H%M%S)，精确到秒，避免同分钟多任务覆盖 - 必须附带 SHA256 校验值（生成后立即算）：
sha256sum file.sql.gpg | cut -d' ' -f1 - 环境标识（
prod/dr）和数据库名不可省略，防止误还原到错误集群 - 建议额外上传一个
.meta.json文件，记录mysqldump版本、源实例 IP、GTID 状态、加密工具及参数
最易被忽略的是校验环节——很多团队只传不验，等真要恢复才发现文件损坏或中途断连，此时再重传已错过 RTO 窗口。每次上传完成后，务必在目标端用 aws s3 ls + sha256sum 对比原始校验值。
