mysqldump 是 MySQL 自带的一个极其常用的逻辑备份工具。它的基本原理是将数据库中的数据和结构转换成一系列的 SQL 语句（如 CREATE TABLE、INSERT 等）。
1. 核心特点
逻辑备份：它备份的是 SQL 指令，而不是物理数据文件（.ibd）。跨平台/版本：由于是 SQL 文本，你可以把 5.7 版本的备份恢复到 8.0 版本，或者从 Linux 迁移到 Windows。简单灵活：可以只备份一个表、一个库，或者整个服务器。恢复成本：对于小数据库非常方便，但对于 TB 级别的大数据库，恢复速度比物理备份（XtraBackup）慢得多。
2. 主要优缺点
维度优点缺点可读性备份文件是纯文本，可以直接用编辑器打开看。文件体积相对物理备份较大（压缩前）。细粒度能够很方便地只恢复某一个表的数据。恢复时需要重新构建索引，CPU 和 IO 消耗大。兼容性兼容性极强，适合做数据库升级或迁移。备份大型数据库时，对生产环境的压力持续时间长。锁表情况配合 --single-transaction 可实现 InnoDB 的无锁热备。如果有非 InnoDB 表（如 MyISAM），备份时会锁表。3. mysqldump 的工作流程
连接查询：连接到 MySQL 服务器。获取结构：查询表结构（DDL），生成CREATE TABLE 语句。读取数据：将每一行数据读出来，转换成 INSERT 语句。生成文件：将这些 SQL 语句写入到 .sql 文件中。
4. 常见的备份场景
日常小规模备份：数据量在 50G 以下时，mysqldump 是首选。单表误删找回：物理备份只能整库恢复，而 mysqldump 允许你只把那张误删的表导入回去。环境迁移：把生产环境的数据抽出一部分导给开发环境使用。
5. 执行备份
5.1 推荐创建专用备份账号
CREATE USER 'backup'@'localhost' IDENTIFIED BY 'StrongPass!'; GRANT SELECT, SHOW VIEW, TRIGGER, EVENT, LOCK TABLES, RELOAD, PROCESS ON *.* TO 'backup'@'localhost'; FLUSH PRIVILEGES;
5.2 准备环境（不在备份命令中明文暴露）
[root@localhost ~]# vim /etc/mysql_backup.cnf [client] user=root password=LJFLDskfdjsldkjfl port=3306 #根据自己实际端口填写 socket=/var/lib/mysql/mysql.sock #根据自己实际sock填写
5.3 执行备份
[root@localhost ~]# mysqldump --defaults-extra-file=/etc/mysql_backup.cnf \ --single-transaction \ --routines \ --hex-blob \ --set-gtid-purged=OFF \ --triggers \ --events \ --all-databases \ --flush-logs \ --source-data=2 \ | gzip > "/data/mysql/backup/logical_backup/mysqldump_$(date '+%F_%H-%M-%S').sql.gz"
6. 编写备份脚本
[root@localhost ~]#vim mysqldump_backup.sh #!/bin/bash # # ============================================================================== # MySQL 逻辑备份脚本（基于 mysqldump） # 适用于 MySQL 8.0，支持定时任务 # 作者：Noleaf # 日期：2025-12-31 # ============================================================================== set -euo pipefail #=============================变量定义========================================== # 时间戳 Timestamp=$(date '+%F_%H-%M-%S') # 备份根目录 BACKUP_BASE=/data/mysql8/backup/mysqldump_backup # 备份文件名称 BACKUP_NAME="mysqldump_${Timestamp}.sql.gz" # 日志目录及文件 LOG_DIR=${BACKUP_BASE}/logs LOG_FILE=${LOG_DIR}/mysqldump_${Timestamp}.log # 保留天数 KEEP_DAYS=30 # MySQL 配置文件（包含用户名和密码） MYSQL_CNF=/etc/mysql_backup.cnf #=============================创建目录========================================== mkdir -p "$BACKUP_BASE" "$LOG_DIR" echo "========================== mysqldump备份开始于 [$Timestamp] ===================" | tee -a "$LOG_FILE" #=============================执行备份========================================== #注意mysqldump路径 if /usr/local/mysql-8.0.44/bin/mysqldump --defaults-extra-file=${MYSQL_CNF} \ --single-transaction \ --routines \ --hex-blob \ --set-gtid-purged=OFF \ --triggers \ --events \ --all-databases \ --flush-logs \ --source-data=2 \ | gzip > "${BACKUP_BASE}/${BACKUP_NAME}"; then echo "Success: mysqldump备份成功！文件: ${BACKUP_BASE}/${BACKUP_NAME}" | tee -a "$LOG_FILE" else echo "ERROR: mysqldump备份失败！请检查日志 ${LOG_FILE}" | tee -a "$LOG_FILE" exit 1 fi #=============================清理旧备份========================================== echo "正在清理 $KEEP_DAYS 天之前的旧备份..." | tee -a "$LOG_FILE" find "${BACKUP_BASE}" -maxdepth 1 -type f -name "mysqldump_*.sql.gz" -mtime +${KEEP_DAYS} -exec rm -f {} \; find "${LOG_DIR}" -maxdepth 1 -type f -name "mysqldump_*.log" -mtime +${KEEP_DAYS} -exec rm -f {} \; #=============================统计数据简报======================================== BACKUP_SIZE=$(du -sh "${BACKUP_BASE}/${BACKUP_NAME}" | cut -f1) echo "本次mysqldump备份大小：${BACKUP_SIZE}" | tee -a "$LOG_FILE" echo "=================== mysqldump备份完成于 [$(date '+%F %H:%M:%S')] ===================" | tee -a "$LOG_FILE"
7. MySQL8/GTID 恢复备份流程
7.1 准备环境
确认目标库为 MySQL 8.0，并启用了 GTID 模式 (gtid_mode=ON，enforce_gtid_consistency=ON)。确认目标库已初始化，并有足够磁盘空间。建议在恢复前关闭业务连接，避免写入冲突。
7.2 解压备份文件
如果备份文件是 .sql.gz 压缩格式，先解压：
[root@localhost ~]# gunzip /data/mysql8/backup/mysqldump_backup/mysqldump_2026-01-05_14-30-00.sql.gz
得到解压备份文件：
mysqldump_2026-01-05_14-30-00.sql
7.3 执行恢复命令
直接导入 SQL 文件：
[root@localhost ~]# mysql --defaults-extra-file=/etc/mysqldump8_backup.cnf < mysqldump_2026-01-05_14-30-00.sql
如果是压缩文件，用管道方式：
[root@localhost ~]# gunzip < mysqldump_2026-01-05_14-30-00.sql.gz | mysql --defaults-extra-file=/etc/mysqldump8_backup.cnf
7.4 恢复过程中的注意事项
GTID 设置
如果备份文件包含：
SET @@GLOBAL.gtid_purged='uuid:transaction_id,...';
在恢复时可能报错。
建议在备份时使用 --set-gtid-purged=OFF，恢复后再根据需要手动设置。
如果必须导入 GTID 集合，需先确认目标库为空库，并执行：
SET GLOBAL gtid_purged='uuid:transaction_id,...';
外键检查 mysqldump 会自动关闭/开启 FOREIGN_KEY_CHECKS，避免因表顺序导致外键错误。
唯一性检查 大库恢复时可临时关闭：
SET UNIQUE_CHECKS=0; SET FOREIGN_KEY_CHECKS=0;
导入完成后再开启。
严格模式 MySQL 8 默认开启严格模式，对非法日期（如 0000-00-00）、超长字符串会报错。恢复前可调整：
SET sql_mode='NO_ENGINE_SUBSTITUTION';
对象属性 MySQL 8 对 DEFINER 用户 要求更严格，如果备份文件中定义的用户不存在，恢复后对象可能无法运行。需提前创建：
CREATE USER 'definer_user'@'%' IDENTIFIED BY 'password';
7.5 验证恢复结果
检查库和表数量：
SHOW DATABASES; SHOW TABLES FROM dbname;
检查数据量：
SELECT COUNT(*) FROM dbname.tablename;
检查对象完整性：
SHOW PROCEDURE STATUS; SHOW TRIGGERS; SHOW EVENTS;
检查 GTID 集合：
SHOW VARIABLES LIKE 'gtid_executed';
7.6 恢复后的收尾工作
确认 DEFINER 用户 存在，避免存储过程/触发器报错。
如果是主从环境，执行：
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000123', MASTER_LOG_POS=456789, MASTER_AUTO_POSITION=1; START SLAVE;
在 GTID 模式下，推荐使用 MASTER_AUTO_POSITION=1，自动对齐 GTID。
检查日志，确认没有报错或警告。
✅ 总结
MySQL 8 恢复流程的关键点：
解压备份文件导入 SQL 文件处理 GTID 设置（gtid_purged）注意严格模式与对象属性验证恢复结果（库、表、对象、GTID 集合）收尾工作（用户权限、主从复制、日志检查）
到此这篇关于MySQL8配置mysqldump逻辑备份的实现的文章就介绍到这了,
