MySQL大数据量备份核心是“不锁表、不拖垮服务、可恢复、可验证”，推荐Percona XtraBackup物理热备为主，辅以分库分表逻辑备份与严格校验演练。
MySQL 大数据量数据库的备份，核心在于“不锁表、不拖垮服务、可恢复、可验证”。直接 mysqldump 全库导出会阻塞写入、耗尽内存、生成超大单文件，不适用于生产环境中的 TB 级库。实际可行方案需分场景选择：逻辑备份（结构+数据）适合中小规模或需跨版本迁移；物理备份（文件级拷贝）才是大库主力，配合增量与校验才能落地。
一、优先用物理备份：Percona XtraBackup（
推荐）
推荐）专为 InnoDB 设计，支持热备（不锁表）、压缩、流式传输、增量备份，是 TB 级 MySQL 生产环境事实标准。
- 全量备份示例：xtrabackup --backup --target-dir=/backup/full_$(date +%F)（自动记录 binlog 位置，用于后续恢复或增备）
- 增量备份（基于上次全量）：xtrabackup --backup --incremental-basedir=/backup/full_2025-06-01 --target-dir=/backup/inc_2025-06-02
- 备份后必须 prepare（回滚未提交事务、前滚已提交事务）：xtrabackup --prepare --apply-log-only --target-dir=/backup/full_2025-06-01；再合并增量：xtrabackup --prepare --apply-log-only --target-dir=/backup/full_2025-06-01 --incremental-dir=/backup/inc_2025-06-02；最后完整 prepare（去掉 --apply-log-only）
- 恢复时停库，清空 datadir，用 xtrabackup --copy-back 拷回，改权限，重启
二、逻辑备份优化：mysqldump 分库分表 + 并行 + 压缩
适用于百 GB 级、需跨版本/云厂商迁移、或仅部分表需备份的场景。关键不是不用 mysqldump，而是“怎么用”。
- 禁用自动提交 + 关闭唯一检查 + 单事务导出（避免长事务）：mysqldump -u user -p --single-transaction --skip-extended-insert --no-autocommit --databases db1 > db1.sql
- 按表拆分，用脚本并行导出（如 8 张表开 4 个进程），避免单点瓶颈
- 边导出边压缩：mysqldump ... | gzip > db1.sql.gz，节省磁盘与网络带宽
- 跳过日志表、临时统计表等非核心数据，减少备份体积和时间
三、备份策略必须配套：保留周期、校验、异地
备份本身没价值，能恢复且恢复正确才有价值。大库更需刚性流程。
- 保留策略建议：1 天全量 + 6 天增量（或 7 天全量轮转），至少保留 1 套离线备份在另一台机器或对象存储（如 S3、OSS）
- 每次备份后自动校验：用 xtrabackup --check-privileges 和 innobackupex --apply-log --no-timestamp 测试 prepare 是否成功；对逻辑备份可抽样导入测试表，查 count 或 checksum
- 定期恢复演练：每月至少一次从备份还原到测试实例，验证 RTO（恢复时间目标）是否达标
四、避坑要点：别让备份反成故障源
大库备份失败常因配置或操作细节被忽略，这些比工具选择更致命。
- 确保 innodb_log_file_size 与 buffer_pool_size 匹配，XtraBackup prepare 阶段可能因日志文件不匹配报错
- 备份用户需最小权限：RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT, SELECT；禁止 root 直接跑备份
- 不要在主库高峰期执行全量备份；若必须，用 --throttle 限速（XtraBackup）或降低 mysqldump 的 --skip-extended-insert 行数
- 监控备份过程：记录开始/结束时间、大小、exit code；失败立即告警，不能只看 cron 是否运行
