MariaDB 10.0 和 MySQL 5.6
去年五月,我首次撰写了关于 MariaDB 10.0 的博客。我们收到了一些反馈,进行消化后,我进一步解释了 MariaDB 10.0。现在,随着 MariaDB 10.0 的第一个 Alpha 版本发布,新的一年刚刚开始,是时候进一步解释一下了,特别是关于 MariaDB 10.0 和 MySQL 5.6,因为我和 MariaDB 项目中的其他人经常被问及它们之间的区别。
首先,以下是一些关于为什么我们没有简单地以 MySQL 5.6 为基础并创建一个本应被称为 MariaDB 5.6 的版本的原因的详细信息。这些细节以前并未广泛分享过。
- MySQL 5.6 中代码库的文件结构发生了变化。单个代码文件被拆分成多个,代码也在文件之间移动。将 MariaDB 合并到这个新的文件结构中将是一项非常耗时的工作。至于 MySQL 方面文件结构为什么发生了变化,我也不知道答案。
- MariaDB 5.5 与 MySQL 5.5 有大量的代码差异,并包含许多直到现在才在 MySQL 5.6 中引入的功能。在这些情况下,会对相同功能的 MySQL 和 MariaDB 版本进行比较,并进行设计和质量保证 (QA) 审查。显然,得分较高的版本将用于 MariaDB。在大多数情况下,决定是使用 MariaDB 版本的功能。
- MySQL 中的所有新代码(至少是错误修复)不一定都有相应的测试用例了。当您将此类功能合并到与原始代码不同的其他代码中时,测试用例对于评估功能是否按预期工作至关重要。
与上面的第二和第三个论点非常一致,Percona 的 Stewart Smith 昨天撰文谈到 MySQL 中最新的安全修复引入了一个回归问题,以及 MariaDB 项目中进行的质量保证工作和测试用例的重要性如何避免了将该回归问题引入 Percona Server。
MariaDB 不仅仅是作为 MySQL 的替代品。MariaDB 在很大程度上是关于创新和改进 MySQL 技术。MySQL 5.6 不是一个适合创新的基础,因此发生了以下情况:
- 我们需要引入一个新的版本,因为我们已经处于引入新功能的过程中,例如多源复制、Cassandra 集成、引擎独立统计信息等等。无论何时引入新功能,通常都会升级到一个新的主要版本。
- 将下一个版本称为“MariaDB 5.6”是错误的,因为它并非基于 MySQL 5.6。因此,我们决定跳到 10.0。
- 我们知道 MariaDB 需要实现 MySQL 5.6 中引入的许多功能才能成为 MySQL 5.6 的可行替代品,并且我们已采取分步方法来合并或重新创建 MySQL 5.6 的功能。
第一个主要版本 MariaDB 10.0 例如将包含合并的 InnoDB、合并的 Performance Schema 以及全局事务 ID 的新实现。MariaDB 10.0 计划于夏季发布 GA (General Availability) 版本。
我们采取分步方法的目的是最终将 MySQL 5.6 的所有功能要么合并,要么重新实现。所有重新实现的功能都将与其 MySQL 版本兼容。最终,MariaDB 10 应该与 MySQL 5.6 完全功能兼容,当然,在此基础上还将包含许多 MariaDB 独有的额外功能。
重新实现功能的决定非常简单。如果 MySQL 5.6 中的某个实现从我们或用户的角度来看有所欠缺,我们就会重新实现。重新实现的决定并非出于“我想这样做”的心态,也不会受到“非我发明”症候群的影响。每个案例都经过认真评估和广泛讨论。您可以通过加入邮件列表 maria-developers@lists.launchpad.net(地址:https://launchpad.net/~maria-developers)来参与这些讨论并发表您的意见。
可以选择另一条路径吗?是的。我们可以将 MySQL 5.6 的最新版本作为 MariaDB 5.6 版本的基础,然后开始打补丁。但需要记住的是,MariaDB 并非一套有限的补丁。尽管 MariaDB 以 MySQL 为基础,但在其之上进行了大量的工程工作。MariaDB 的工程师和质量保证人员正在全职工作,以改进 MariaDB 内部的 MySQL 技术。
还有另一种可能性——成为一个真正的分支,停止从 MySQL 合并,并破坏兼容性。但我们不想走那条路——我们和 MariaDB 用户总体上确实非常重视 MySQL 中引入的许多功能,并希望将其包含在 MariaDB 中。
MariaDB 5.5 是 MariaDB 日益流行的关键部分,我们仍然乘着这股浪潮向上发展。每周下载量不断增加,更多发行版采用 MariaDB,以及更多大型用例。
在 MariaDB 项目内部,我们正在谨慎地进行平衡,既要尽可能成为 MySQL 的便捷替代品,又要引入亟需的创新,同时还要保持所有这些的现实性。没有创新,MariaDB 就不是自己的产品。
参加 MariaDB 和 SkySQL 联合路演,了解 MariaDB 的最新消息并与我们交流!您可以在此处找到路演日程和注册信息。
那 innodb 全文搜索和 ipv6 支持(如 INET6_ATON()、INET6_NTOA())怎么样?
Innodb 全文搜索不会包含在 10.0 中,可能会在 10.1 中。也就是说,10.0 中的 innodb 支持全文搜索,但服务器不使用它。
INET6_ATON() 和 INET6_NTOA() 仍然可以在 10.0 中,是的。
https://mariadb.atlassian.net/browse/MDEV-4051
是否有关于何时发布与 MySQL 5.6 完全兼容的版本的路线图?听起来近期不会发生。
MariaDB 的主要卖点之一是它可以直接替代 MySQL,但听起来这基本上不再是真的,对吗?一旦有人使用 MySQL 5.6,他们大多会失去直接替换的能力。
告诉我关于“InnoDB 记录、间隙和 Next-Key 锁”
这种行为将来会得到修复吗?
那么从 MySQL 5.6 升级到 10.0 的最佳选择是什么?
a) 使用 innobackupex 并将其导入到一个新的并行数据库中,然后切换
b) 降级到 5.5 并更改为 mariadb 5.5。然后升级到 5.6
我认为直接替代是 MariaDB 变得流行的主要原因之一。
谢谢!