MySQL如何使用MySQL Shell进行并行备份

MySQL Shell的util.dumpInstance()和util.dumpSchemas()支持真正并行逻辑备份，但默认单线程（threads:1），必须显式指定threads参数（如threads:8）才能启用多线程；二者均能精确记录GTID/binlog位置，但需确保已开启binlog且用户具备REPLICATION CLIENT权限。

MySQL Shell 的 util.dumpInstance() 和 util.dumpSchemas() 支持真正意义上的并行逻辑备份，比 mysqldump 快得多，且能精确记录 GTID / binlog 位置 —— 但默认不启用并行，必须显式指定 threads 参数，否则就是单线程。

如何触发并行备份：必须传 threads，不能依赖默认值

util.dumpInstance() 和 util.dumpSchemas() 默认是单线程（threads: 1），即使你机器有 16 核也不会自动提速。想用多线程，必须手动设参数：

1. threads 值建议设为 CPU 核心数的 1–2 倍（例如 8 核机器可设 4～12），过高反而因 I/O 或锁竞争导致性能下降
2. 不支持小数或动态表达式，只能传整数，比如 threads: 8，不能写 threads: os.cpus().length
3. 如果目标目录非空，备份会直接失败（不是覆盖），必须提前清空或换新路径
4. 备份过程不会自动压缩，如需压缩，得在 dump 完成后用 gzip 处理 .tsv 文件，或用外部管道（但会丢失元数据文件 @.json）

util.dumpSchemas() 与 util.dumpInstance() 的关键区别

选错函数会导致备份范围出错，尤其在多库场景下：

1. util.dumpSchemas(['db1', 'db2'])：只导出指定库的结构 + 数据，不包含用户、权限、存储过程定义（除非显式加 includeUsers: true）
2. util.dumpInstance()：导出整个实例，含所有库、用户账号（@.users.sql）、GTID 状态、binlog 位点（@.json 中的 binlogFile/binlogPosition），适合做全量恢复或搭建从库
3. 两者都支持 excludeTables，但 dumpInstance() 不支持 includeDefiners 这类细粒度控制，而 dumpSchemas() 可以
4. 若只备份部分表，必须用 dumpSchemas() + excludeTables 或 includeTables，dumpInstance() 没有表级过滤能力

常见错误：备份后找不到 binlog 位置或无法建复制

很多人 dump 完发现 @.json 里 binlogPosition 是 0 或为空，导致后续无法基于备份点拉从库 —— 这通常是因为没开 binlog 或连接用户权限不足：

1. 确保 MySQL 已启用 log_bin=ON，且不是 log_bin=OFF 或仅在 slave 上开启
2. 连接用户必须有 REPLICATION CLIENT 权限，否则 util 拿不到当前 binlog 位点，会 fallback 到 GTID 或报 warning
3. 如果实例启用了 GTID，@.json 中的 gtidExecuted 才是可靠的一致性点；若禁用了 GTID，必须靠 binlogFile+binlogPosition，缺一不可
4. 使用 --consistency=archive（默认）时，dump 期间会加全局读锁（FLUSH TABLES WITH READ LOCK），对线上写入有影响；如需无锁，改用 --consistency=none，但一致性由应用层保证

实际执行示例：带并行、含用户、保留 binlog 位点

以下命令在 MySQL Shell 的 JavaScript 模式下运行（先输入 js）：

util.dumpInstance("/data/backup/full_20260810", {threads: 6,excludeSchemas: ["mysql", "information_schema", "performance_schema", "sys"],includeUsers: true,consistency: "archive"});

注意：includeUsers: true 才会生成 @.users.sql；excludeSchemas 必须显式排除系统库，否则备份会失败（因权限或结构特殊）；路径 /data/backup/full_20260810 必须事先不存在。

备份完成后，立刻检查 /data/backup/full_20260810/@.json 是否包含非空的 binlogFile 和 binlogPosition 字段 —— 这个细节容易被跳过，但决定了能不能做精准恢复。