【MySQL】备份神器 mydumper：原理、实操与恢复全指南

By - YunYang
Posted on 2026-02-09
Posted in MySQL

【MySQL】备份神器 mydumper：原理、实操与恢复全指南

在 MySQL 数据库运维中，备份是数据安全的核心保障。相较于传统的 mysqldump，mydumper 凭借多线程并发、文件易管理、数据一致性强等优势，成为中大型数据库备份的优选工具。本文将从核心特点、安装配置、备份 / 恢复实战、原理剖析四个维度，带你全面掌握 mydumper 的使用技巧。

一、mydumper 核心优势

mydumper 之所以成为运维人员的 “心头好”，核心在于三大特性：

多线程并发备份：多线程并行处理不同数据表，备份速度较单线程工具提升数倍，适配海量表场景；
文件结构清晰：表结构（.sql）与数据文件分离存储，支持单表快速恢复，无需解析完整备份包；
一致性保障：
- InnoDB 引擎：通过事务快照（REPEATABLE READ 隔离级别）确保数据一致性；
- MyISAM 引擎：通过全局读锁（FTWRL）避免备份过程中数据写入冲突。

二、安装与环境准备

2.1 安装 mydumper（CentOS 7）

# 1. 下载 RPM 包（v0.14.5-2 稳定版）
cd /usr/src/
wget https://github.com/mydumper/mydumper/releases/download/v0.14.5-2/mydumper-0.14.5-2.el7.x86_64.rpm

# 2.  yum 安装（自动解决依赖）
yum install mydumper-0.14.5-2.el7.x86_64.rpm -y

# 3. 验证安装
mydumper --help  # 显示帮助信息即安装成功

2.2 环境配置（必做步骤）

2.2.1 创建备份专用用户

避免 root 账号直接操作，创建最小权限备份用户：

-- 创建用户（用户名：u_mydumper，密码：Ud8agc_a）
create user u_mydumper@'%' identified WITH mysql_native_password BY 'Ud8agc_a';

-- 授予备份必需权限
grant create,insert,select,reload,process,lock tables,replication client,replication_slave_admin,show view,trigger,backup_admin on *.* to 'u_mydumper'@'%';

2.2.2 配置备份目录

# 创建专用备份目录（示例路径）
mkdir -p /data/backup/mydumper_bak
cd /data/backup/mydumper_bak

2.2.3 开启 General Log（可选，用于问题排查）

-- 开启全局日志
set global general_log=on;

-- 查看日志存储路径（默认：/var/lib/mysql/[主机名].log）
show variables like 'general_log_file';

三、实战：mydumper 备份操作

3.1 执行备份命令

以备份 bak1 数据库为例，备份文件存储至 /data/backup/mydumper_bak/bak1：

cd /data/backup/mydumper_bak/
mydumper -u 'u_mydumper' -p 'Ud8agc_a' -S /tmp/mysql.sock -B bak1 -o ./bak1

3.2 关键参数说明

参数	作用
`-u`	指定数据库用户名
`-p`	指定用户密码
`-S`	MySQL 套接字文件路径（默认 `/tmp/mysql.sock`）
`-B`	待备份的数据库名
`-o`	备份文件输出目录
`-t`	并发线程数（默认 4，可按需调整）

3.3 备份文件结构

备份完成后，进入输出目录查看文件：

cd /data/backup/mydumper_bak/bak1
ll  # 列出所有备份文件

典型文件清单：

bak1-schema-create.sql：数据库创建语句；
bak1.t1-schema.sql、bak1.t2-schema.sql：表结构文件；
bak1.t1.00000.sql、bak1.t2.00000.sql：表数据文件；
metadata：备份元信息（备份时间、GTID、binlog 位点等）。

3.4 分析备份过程的 General Log

通过 General Log 可观察 mydumper 的备份细节，关键操作片段如下（截取部分日志）：

2026-02-09T03:05:32.300231Z 28 Query	FLUSH NO_WRITE_TO_BINLOG TABLES  -- 刷新表到磁盘

2026-02-09T03:05:32.307325Z 28 Query	FLUSH TABLES WITH READ LOCK     -- 加全局读锁

2026-02-09T03:05:32.313811Z 32 Connect	u_mydumper@localhost on  using Socket  -- 创建子线程

2026-02-09T03:05:32.320569Z 31 Query	START TRANSACTION /*!40108 WITH CONSISTENT SNAPSHOT */  -- 开启事务

2026-02-09T03:05:32.377741Z 32 Query	SELECT /*!40001 SQL_NO_CACHE */ * FROM `bak1`.`t1`  -- 读取表数据

2026-02-09T03:05:32.382764Z 28 Query	UNLOCK TABLES /* FTWRL */  -- 释放全局读锁

四、 mydumper 备份原理深度解析

结合上述实验与日志分析，mydumper 的备份流程可拆解为以下 6 个关键步骤，确保效率与一致性兼顾：

刷新表数据到磁盘：执行 FLUSH NO_WRITE_TO_BINLOG TABLES，将所有打开的表的脏页刷新到磁盘，避免内存数据未持久化导致备份不完整。
加全局读锁：主线程执行 FLUSH TABLES WITH READ LOCK，防止备份过程中其他会话修改数据（MyISAM 表依赖此锁保障一致性，InnoDB 表后续通过事务快照避免锁阻塞）。
创建子线程并初始化事务：默认创建 4 个子线程（可通过 -t 参数调整线程数），每个子线程设置事务隔离级别为 REPEATABLE READ（RR） 并开启事务，获取一致性快照。
获取元信息与表结构：子线程分别查询数据库的 GTID 信息、binlog 位点，以及各表的建表语句，存储至对应的 schema 文件。
多线程并发读取数据：不同子线程通过 SELECT /*!40001 SQL_NO_CACHE */ * FROM 表名 语句读取不同表的数据，避免使用缓存提升效率，并将数据写入对应的数据文件。
释放锁并结束线程：所有表备份完成后，主线程释放全局读锁（UNLOCK TABLES），子线程提交事务并退出，备份任务完成。

五、实战：myloader 恢复操作

mydumper 配套恢复工具 myloader 支持多线程恢复，操作流程如下：

5.1 恢复前准备

-- 创建目标恢复数据库
create database bak1_recover;

5.2 执行恢复命令

myloader -u 'u_mydumper' -p 'Ud8agc_a' -S /tmp/mysql.sock -B bak1_recover -d /data/backup/mydumper_bak/bak1/

5.3 验证恢复结果

use bak1_recover;
show tables;  -- 确认表结构存在
select * from t1;  -- 验证数据完整性

5.4 分析恢复过程的 General Log

通过 General Log 可观察 myloader 的备份细节，关键操作片段如下（截取部分日志）：

2026-02-09T03:22:52.480771Z	   33 Connect	u_mydumper@localhost on  using Socket  -- 创建子线程

2026-02-09T03:22:52.504057Z	   37 Query	USE `bak1_recover`  --切换到目标恢复数据库

2026-02-09T03:22:52.507328Z	   35 Query	CREATE TABLE `t2` (
  `id` int NOT NULL AUTO_INCREMENT,
  `a` varchar(20) DEFAULT NULL,
  `b` int DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci   -- 创建表结构

2026-02-09T03:22:52.528705Z	   34 Query	START TRANSACTION -- 开启事务

2026-02-09T03:22:52.529636Z	   34 Query	INSERT INTO `t2` VALUES(1,"one",1)
,(2,"two",2)   -- 插入数据

2026-02-09T03:22:52.600323Z	   34 Query	COMMIT  -- 提交事务

六、 myloader恢复原理解析

myloader 的恢复流程与 mydumper 的备份流程相呼应，同样通过多线程提升效率，核心步骤如下：

初始化恢复线程：创建多个子线程（默认与备份线程数一致），并切换到目标恢复数据库（USE bak1_recover）。
多线程创建表结构：不同子线程分别执行备份文件中的表结构语句（如 CREATE TABLE），确保表结构先于数据创建。
开启事务并写入数据：每个子线程针对不同的表开启事务，执行 INSERT 语句将备份数据写入目标表，避免单条插入导致的性能问题。
提交事务：单个表的数据写入完成后，子线程提交事务，确保数据持久化。
收尾与退出：所有表恢复完成后，子线程退出，恢复流程结束。

总结

mydumper 凭借多线程并发、文件结构化、一致性保障三大核心优势，完美解决了传统备份工具速度慢、恢复灵活度低的痛点。通过本文的安装配置、实战操作与原理解析，相信你已能熟练运用 mydumper 完成 MySQL 数据库的备份与恢复工作。在实际运维中，可根据数据库规模调整线程数（-t 参数），结合定时任务（crontab）实现自动化备份，进一步提升数据安全性。

Tags:MySQL

云扬のBlog