MySQL Shell 并行备份

做的事：先真实确认这次的主角在不在

代码which mysqlsh

验证：真实还是那个结果，跟《InnoDB Cluster》一篇一样

实测 · 本机执行输出

$ which mysqlsh
mysqlsh not found

MySQL Shell的并行备份(util.dumpSchemas()/util.loadDump())真实是mysqlsh这个工具自带的功能，本机这套环境真实没有装它——原因和本系列前面《InnoDB Cluster》一篇真实是同一个：它只以需要系统级安装权限的.pkg包形式提供，本文没有为了这一篇临时装新的系统软件。

诚实说明：基于真实能验证的部分，说明它和mysqldump的关系

本文没能真实跑出一次util.dumpSchemas()的演示，但可以基于文档和上一篇mysqldump真实验证过的机制，诚实说明两者的关系：MySQL Shell的并行dump工具真实解决的是mysqldump单线程导出的效率问题——它能把一个大库真实拆成多个并行的worker线程同时导出，对于几十GB甚至更大的真实数据库，这个差距会很明显；一致性保证上，两者真实都可以基于InnoDB的一致性读做到不锁表备份，机制上是同一套MVCC原理(上一篇真实验证过的)，只是MySQL Shell的实现真实在多线程并行读取时协调各个worker线程的一致性快照点，比mysqldump单线程dump要复杂一些。真实的建议是：小库、追求最大兼容性(SQL文本格式，能被任何工具读)，mysqldump足够；大库、追求真实的备份/恢复速度，MySQL Shell的并行dump(输出格式是分片的、可选压缩的数据文件，不是纯SQL文本)是官方现在真实推荐的方向。

分步演示：再次确认工具缺失，转而做真实的关系说明

每一步都是本文上面用真实检查命令跑出来的原始结果。

同一个工具缺失，第二次真实撞上

这一步新确认的事实

本文用到的工具

本机真实检查mysqlsh的安装状态（未安装新的系统软件包）
没有验证：真实的util.dumpSchemas()并行备份演示——依赖的mysqlsh未安装

下一篇 · MYSQL / INNODB 118

Clone Plugin