MySQL 8.0 最为良心的功能是什么？
是快速加列功能么？（见：MySQL 8.0使用三周后，我再也看不上5.7版本了）
是 DoubleWrite 拆分带来的写入性能巨大提升么（见：真香，MySQL 8.0.20，10倍性能提升！！！）？
是 JSON 字段支持 Multi-value Indexes 功能么？
以上全错。
若把 MySQL 8.0 比作一个渣男，那么能让用户无条件投降并投入到 8.0 怀抱的功能莫过于 MySQL 8.0.17 版本推出的 Clone Plugin 功能。
有了它，用户就拥有了开源免费的物理备份功能，甚至还能直接克隆出新的 MySQL 实例。
而在这之前，仅收费的 MySQL Enterprise 版本才独享物理备份的功能。今天，就让姜老师带来全网最完整的 Clone Plugin 硬核分析。
Xtrabackup
由于之前开源社区版本的 MySQL 并没有提供物理备份的机制，所以数据库备份大多使用逻辑备份工具 mysqldump 。
然而，mysqldump 是单线程备份，串行地从数据库中一张张导出表中的记录，备份速度是该工具最大的问题。
好在开源社区提供了 mydumper 工具，一种并行的逻辑备份工具，极大解决了逻辑备份的速度问题。
但随着单个实例数据库容量的不断增长，单实例500G、1T已经不再少见，通过逻辑备份工具备份和恢复 MySQL 速度依然难以让生产用户满意，特别是在克隆一个新的 MySQL 节点时。
Percona 公司提供开源的 Xtrabackup 工具，用以对 MySQL 数据库进行物理备份，使用的用户也蛮多。
但这个工具使用中翻车的情况也不少，见：Xtrabackup备份原理实现细节——对淘宝数据库内核月报的补充
因为相比逻辑备份，物理备份是需要侵入数据库内核，对比逻辑备份工具 mydumper，这个难度提升了远远不止一个等级。
终于，现在社区版 MySQL 提供了物理备份/克隆的工具 Clone Plugin。
Clone Plugin
Clone Plugin 是 MySQL 8.0.17 版本推出一个插件，用于进行数据库的物理备份，但官方用 Clone （克隆）而不仅仅是 Backup 描述插件的功能。
需要强调的是，Clone Plugin 只备份 InnoDB 存储引擎表，其他类型表不进行备份。
BTW，其他存储引擎 MySQL 官方后续也不会提供开发和维护，应尽快迁移到 InnoDB 存储引擎 —— 这个星球上最伟大的关系型事务存储引擎。
接着，我们先看下 Xtrabackup 物理备份的过程：
上图显示了 15：00 ~ 15：30 进行 Xtrabackup 物理备份的过程，总共用时 30 分钟，其中经历4个过程：
1. 重做日志文件拷贝；
2. InnoDB 拷贝文件；
3. 保存二进制日志点位（通过加FTWRL全局锁）
4. 拷贝其他非 InnoDB 文件；
特别要指出的是，Xtrabackup 的备份过程中 redo copy 的这个过程是持续整个备份周期的，即 redo copy 进行了几乎整整30分钟。
若通过备份文件进行恢复，恢复到的时间点是15：30。
好了，让我们看看官方的物理备份 Clone Plugin 是如何实现的：
从上图可以发现，Clone Plugin 很不同的一点是 redo copy 的过程非常短，不需要备份30分钟内所产生的所有 redo log。
这意味着通过 Clone Plugin 恢复物理备份的速度要远远快于 Xtrabackup 。
在 redo copy 前有一个 page copy，这是 Xtrabackup 所没有的步骤。
也就是在备份完 InnoDB 磁盘文件后，Clone Plugin 还会对 Buffer Pool 中的脏页进行备份，这样就可以减少对于 redo 日志的拷贝。
脏页的备份会先对（space，page_no）排序，以比较顺序的方式写入备份文件。
同时，为了记录在拷贝脏页过程中，又有新的变化产生，所以在 file copy 后启用 page tracking 的机制，记录当前已经 Checkpoint 完成的 LSN。
后续的redo copy 只需要拷贝该 LSN 之后的重做日志即可。
总结来看，对比 Xtrabackup，Clone Plugin 额外实现了以下几个功能：
1. page copy：拷贝脏页，减少重做日志的备份量，提升恢复速度；
2. page tracking：记录 LSN 的变化，用于后续重做日志的备份；
3. redo archiving：备份重做日志，避免重做日志文件写入太快，覆盖写入无法备份的场景，这点Xtrabackup就无能为力了；
最后，Clone Plugin 的一大优势是远程备份。
不可否认，在 Xtrabackup 中也可以实现流式物理备份到远程服务器，但其需打通 ssh 的免密登录，这在生产环境是很难被允许的操作，往往会触发安全红线。
Clone Plugin 通过 MySQL 通信协议，可直接将物理备份文件备份到远程 MySQL 实例，甚至直接恢复出一个实例，这在做节点 Clone 时，简直太香了！
其中备份的目标 MySQL 实例称为 Donor（捐赠者）；远程接收的实例称为 Recipient（接收者）。
远程备份的原理和上述分析的 Clone Plugin 备份原理一样，只是将备份文件通过 MySQL 通信协议传送到了远程 Recipient 服务器中。
Clone Plugin 的限制
Clone Plugin 虽好，但也有一些限制。
进行远程克隆的两个 MySQL 实例版本号必须完全一样。5.7 和 8.0 显然不行，8.0.19 和 8.0.20 小版本不同也不行。
MySQL 8.0.27 版本前不允许 DDL 操作，DDL 操作会被阻塞，甚至影响后续的 SELECT查询操作；MySQL 8.0.27 版本已经可以在备份过程中进行并发的 DDL 操作。
Clone Plugin 不备份 MySQL 配置文件，而 Xtrabackup 是备份的。
更多关于 Clone Plugin 的使用限制可见：
https://dev.mysql.com/doc/refman/8.0/en/clone-plugin-limitations.html
总结
Clone Plugin 是官方推出的物理备份工具，能提供更快、更安全、更可靠的本地/远程物理备份和恢复机制。
对于数据库容量较大的实例，通过物理备份和恢复机制，能大大缩短节点克隆的时间，提升生产效率。
那么，这个功能你会在生产环境中使用或已经使用了么？
欢迎在留言区发表你的评论。
热门跟贴