MySQL 8.0.17，改变格局的大杀器来了

周一和官方MySQL的Philip大叔吃饭聊天，其中少不了各种江湖八卦。当然，我们习惯的见面问候语是：今年IHG至悦保级了么。

Philip大叔之前负责MySQL在韩国和日本的业务，最近几年刚调回中国，谁知没多久就将MySQL业务带上一个新高度。除了数据库，和Philip大叔聊得最多的话题就是酒店，我差不多每年要住至少60晚酒店，Philip大叔至少100晚吧。然后我们又屯了一堆酒店积分，交流着每年去哪烧分。大家猜猜，常见的国际连锁酒店，万豪、凯悦、洲际、希尔顿，他们酒店后台用的数据库是哪个呢？

和Philip大叔吃完饭回公司继续工作，倏地发现MySQL新版本8.0.17发布。昨天看到很多公众号有推送这个消息，问题他们的文章全是流水账，废话连篇，毫无重点。

如果要姜老师总结的话，8.0.17是即5.7版本之后，真正可以走上生产的版本。而新推出的Clone Plugin，将真正改变目前MySQL的格局，再次敲响了MariaDB的丧钟。

官方对于Clone Plugin的介绍是这样的：

The clone plugin permits cloning data locally or from a remote MySQL server instance. Cloned data is a physical snapshot of data stored in  InnoDB  that includes schemas, tables, tablespaces, and data dictionary metadata. The cloned data comprises a fully functional data directory, which permits using the clone plugin for MySQL server provisioning.

简单来说，这就是个免费版物理备份工具啊，对于MySQL社区版的最大馈赠。Clone Plugin可以将备份文件保存在本地，亦可直接将数据（目前仅支持InnoDB）复制到远程实例，其中复制源实例称为Donor，接受实例称为Recipient。同学们可以看下面两张图来体会下（来自官方文档）：

虽然是Clone Plugin的第一个版本，还是考虑得非常完整，提供了一系列参数用以控制备份的并发度、压缩、安全、网络限速等各方面。同时performance_schema库下的表clone_status可以查看当前Clone的进度（sys库应该快速跟进这个查询视图）：

SELECT STAGE, STATE, CAST(BEGIN_TIME AS TIME) as "START TIME",    CASE WHEN END_TIME IS NULL THEN    LPAD(sys.format_time(POWER(10,12) * (UNIX_TIMESTAMP(now()) - UNIX_TIMESTAMP(BEGIN_TIME))), 10, ' ')    ELSE    LPAD(sys.format_time(POWER(10,12) * (UNIX_TIMESTAMP(END_TIME) - UNIX_TIMESTAMP(BEGIN_TIME))), 10, ' ')    END as DURATION,    LPAD(CONCAT(FORMAT(ROUND(ESTIMATE/1024/1024,0), 0), " MB"), 16, ' ') as "Estimate",    CASE WHEN BEGIN_TIME IS NULL THEN LPAD('0%', 7, ' ')    WHEN ESTIMATE > 0 THEN    LPAD(CONCAT(CAST(ROUND(DATA*100/ESTIMATE, 0) AS BINARY), "%"), 7, ' ')    WHEN END_TIME IS NULL THEN LPAD('0%', 7, ' ')    ELSE LPAD('100%', 7, ' ') END as "Done(%)"FROM performance_schema.clone_progress;+-----------+-------------+------------+------------+-----------+---------+| STAGE     | STATE       | START TIME | DURATION   | Estimate  | Done(%) |+-----------+-------------+------------+------------+-----------+---------+| DROP DATA | Completed   |   11:50:01 |  500.88 ms |      0 MB |    100% || FILE COPY | In Progress |   11:50:02 |    1.92 m  | 54,729 MB |     63% || PAGE COPY | Not Started |       NULL |       NULL |      0 MB |      0% || REDO COPY | Not Started |       NULL |       NULL |      0 MB |      0% || FILE SYNC | Not Started |       NULL |       NULL |      0 MB |      0% || RESTART   | Not Started |       NULL |       NULL |      0 MB |      0% || RECOVERY  | Not Started |       NULL |       NULL |      0 MB |      0% |+-----------+-------------+------------+------------+-----------+---------+

Clone Plugin的实现基于InnoDB物理文件的备份，机制大致与Xtrabackup相同。物理备份过程中存在一种可能性：即当备份大容量实例过程中，由于业务不断发生变化，重做日志还未备份就被覆盖了，从而导致备份文件无法恢复的情况。

为此MySQL 8.0.17版本“再次”恢复了InnoDB重做日志文件归档的功能，遥想当年最早的MySQL 3.23版本，InnoDB重做日志文件归档功能就是默认开启的。但8.0.17版本设计更好地是，可以手动控制是否开启重做日志文件归档的功能，比如在Clone过程中开启归档即可。

SELECT innodb_redo_log_archive_start(‘label’, ‘subdir’);

SELECT innodb_redo_log_archive_stop();

其实，有了InnoDB重做日志文件的归档，可以玩出很多新花样的，比如姜老师非常关心的：

• 去除doublewrite机制，目前虽然有多个线程并行去刷新脏页，但脏页刷新最后都要先集中到单一的doublewrite对象中，目前这是一个比较大的性能瓶颈。虽然Percona已经做了些优化，但为什么不直接去除doublewrite对象？正如Oracle数据库一样，partial write通过重做日志归档进行恢复。

• 实现类似于Oracle DG的复制，甚至是InnoDB MGR。至于二进制日志，姜老师早就调研过binlog日志存放到InnoDB表的可能性，也是能行得通。只要官方有愿意，肯投入，再加上BAT大厂倒逼MySQL，MySQL的未来，星辰大海。

基于Clone Plugin，MGR、传统Replication的运维门槛又降低不少，基于MySQL的云数据库自动化实现难度进一步降低。DBA可以将更多精力集中到业务中去。

上篇文章 如果时间可以重来，我依然会选择MySQL ，有同学留言问我对于MariaDB的看法，其实在2年多前的文章中姜老师早就已经说啦： 为什么我不再看好MariaDB 。

其实吧，自从2005年Oracle收购InnoDB存储引擎开发商Innobase伊始，MySQL的命运已然注定。MariaDB从2009年创立到现在的10年间，一直扮演的只是追随者的角色。随着MySQL 5.6开始的源码重构，MySQL已经驶上了快车道，MGR给了PXC致命一击，而Clone Plugin的推出宣判了MariaDB的死刑。 Ma ri aDB ，或许只能拿来 缅怀曾经的青春吧。

屌丝才讲情怀，聪明人，跟趋势 

长期坚持原创真的很不容易，多次想放弃。 坚持是一种信仰，专注是一种态度！ 打赏 和点击 在看 是对作者最好的褒奖哟~~

PS： 想要加入IMG微信群的同学（目前仅峨眉群有坑，少林、武当两群已满），可私信我微信82946772，备注：申请加入峨眉，猎头勿扰

最会讲故事的破产码农