MySQL Shell 并行备份是什么
MySQL Shell 8.0.21 起提供 util.dumpInstance / util.dumpSchemas 这套逻辑备份 API：默认在一致性快照上取数，把每张表切成多个分块并行导出，产物是按表切分的数据文件加元数据描述；恢复侧 util.loadDump 并行导入，并借助进度文件支持中断后继续。它解决的是 mysqldump 单线程导出大库太慢的问题。
基本信息
| 适用平台 | MySQL 8.0.21 及以上 + MySQL Shell（mysqlsh，JavaScript 或 Python 模式） |
|---|---|
| 产物结构 | 每张表按分块切成多个数据文件（可压缩），另有描述库表结构与分块的元数据文件 |
| 一致性 | 默认 consistent 为 true，在一致性快照上取数；非 InnoDB 表无法纳入同一快照 |
| 权限要求 | 导出账号需目标对象的读取与元数据权限（SELECT、SHOW VIEW、TRIGGER、EVENT 等），实例级导出还涉及更宽的权限，以官方权限章节为准 |
典型使用场景
- 大库迁移：并行导出与并行导入，把停机窗口从小时级压到分钟级
- 跨环境同步：从生产导出特定库，导入到验证或测试集群
- 升级前留底：大版本升级前做一份可跨版本回放的逻辑副本
- 按表选导：只导出需要的库表子集，减少导出体积与时间
- 中断续传：长任务失败后依据进度文件从中断处继续，不必从头再来
备份（MySQL Shell JavaScript 模式）
备份（MySQL Shell JavaScript 模式）
# 进入 JavaScript 模式
mysqlsh -u root -p --js
# 整实例导出，4 线程并行，数据文件用 zstd 压缩
js> util.dumpInstance("/backup/dump-all", {threads: 4, compression: "zstd"})
# 只导出指定库，适合按业务分库迁移
js> util.dumpSchemas(["appdb"], "/backup/dump-appdb", {threads: 4})
# 只导结构不导数据：用于快速比对表结构差异
js> util.dumpSchemas(["appdb"], "/backup/dump-ddl", {ddlOnly: true})恢复（loadDump）
恢复（loadDump）
# 目标库应基本为空，避免与既有对象冲突
mysqlsh -u root -p --js
# 4 线程并行导入，进度写入文件便于续传
js> util.loadDump("/backup/dump-appdb", {threads: 4, progressFile: "/backup/load-progress.json"})
# 先演练一遍导入流程而不真正写入
js> util.loadDump("/backup/dump-appdb", {dryRun: true})
# 失败重试前按需重置进度，否则会跳过已标记完成的对象
js> util.loadDump("/backup/dump-appdb", {resetProgress: true})常用选项读法
| 选项 | 作用 | 注意点 |
|---|---|---|
| threads | 并行度，导出与导入各自设置 | 超过机器 IO 与 CPU 承受能力反而变慢 |
| compression | 数据文件压缩方式（如 zstd） | 压缩耗 CPU，带宽受限的反而是主要收益点 |
| consistent | 是否在一致性快照上取数 | 关闭后可能导出到跨时点的数据，慎用 |
| progressFile | 记录导入进度，支持中断续传 | 重复导入前要判断是否需要重置 |
| dryRun | 只演练不落库 | 用于上线前验证目录与目标环境是否匹配 |
导出目录还可以直接指向对象存储桶（操作系统的桶配置或 S3 兼容桶参数），适合云上备份中转，省去先落本地再上传的环节。
loadDump 默认面向空目标库：重复导入未清理的库会因对象已存在而失败或跳过，务必先确认目标环境状态并想清楚进度文件是重置还是复用。