高能预警：这还不是一篇纯技术的月报……

前言

Percona Live 之后紧接着第二天就是 MariaDB Developer Meeting，会议地点就在Booking的办公大楼这次会议的主题就是讨论 10.3 的规划，以及 10.2 的 GA 计划，以及还需要加入 10.2 的功能。

先哭一会别人家的办公楼，这风景。

MariaDB Foundation 不比各种商业公司，全靠捐赠维持，所以能简化就简化，因此没有高大上的参会证了，就这么个手写的……

本次作为基金会 Replication 模块的负责人以及阿里的代表参加，对 Replication 模块在 MariaDB 10.3 的计划需要作出决定。

讨论

首先是 Booking 在 MariaDB Foundation 的代表 Eric 和 MariaDB Foundation 的 CEO —— Otto 介绍本次会议的主要议题。（我前面的一篇说了Booking的MySQL工程师都是长发飘飘……）

去年总结

首先例行总结 10.2 开发周期内的事件，以及目前 MariaDB 潜在的风险，后面可能的解决方案。

最先提出来的是现在 MariaDB 既有官方的 InnoDB，也有 Percona 提供的 XtraDB，在目前 XtraDB 和 InnoDB 差异并不是很大的情况下，是否还要保持两个引擎？还是直接把 XtraDB 的 Patch 加上开关直接合并到 InnoDB？

我个人也不赞同一直保持两个相似度 99% 的引擎。而且 Jan（MariaDB 的 InnoDB 负责人）提出当前代码出现了一个问题，同时编译 XtraDB 和 InnoDB 会导致内核 mini-transaction 无法正确工作，不知道这是不是Oracle故意埋得坑…… 他暂时没有解决方案。

所以可能未来还是会选择去掉 XtraDB，直接把相关补丁放到 InnoDB。

（这位一脸懵逼的同学是 Spider 引擎的创始人 Kentoku）

然后对 GSoC （Google Summer of Code）2016 的成果做了总结，今年还是有几个不错的学生出色地完成了任务，像隐藏列（Invisible Columns）、BLOB索引、超长字段的唯一键约束，都是学生开发的。

江山带有才人出啊，这些任务就算对我们来说也不是简单的活。

这里也鼓励国内的同学（或者你的小师弟师妹）多多参加 GSoC，参与开源，不仅仅是很好的技术积累，还可以获得 Google 的现金奖励和实习机会，以及非常优秀的同学可能被开源项目直接雇佣，这次 MariaDB Corporation 就雇佣了一位 GSoC 中表现优秀的同学。

虽然我也带了一个学生做 GTID 的项目，但是很可惜我带这位同学最终没有完成。

RocksDB

到了开发者沟通环节，Facebook 还是继续推广他们的 RocksDB。

Mark 作为 Facebook 的代表继续从压缩率，读写速率上对 RocksDB、InnoDB、TokuDB 进行比较。

还是那句话，任何测试一定要自己做一遍，PPT 中的结果看看就可以了。

BSL

今年争议最大的就是 BSL（Business Source Lisence）了，MariaDB 和 Percona 在讨论 BSL 的时候都快吵起来了。

BSL 简单来说就是延迟开源最新代码，开放所有旧版本的资料（包括完整的代码）。

比如说目前可以提供给用户的最新版本是 2.0，然后只开放 1.0 的源代码，只有付费用户才能获得最新的源码和无限制使用最新的二进制，免费用户获得延迟的源码和有限制的使用最新的二进制。

Monty 认为这比 Open Core 要好，Open Core 只是纯粹的公开代码，没有文档没有 Test Case 没有注释，这样的开源还不如不开源。BSL 是完整的开放所有的源码，包括文档测试集注释，跟内部使用的一模一样。

争议点在于，Percona 认为 MariaDB 应该所有东西都开源，延迟开源是个什么鬼，BSL 会不会用在 MariaDB Server 上。

Monty 的解释其实很简单，MariaDB Corporation 和 MariaDB Foundation 是两个完全不同的主体，MariaDB Foundation 是 NPO（非营利性组织），并不带有任何经营，纯粹靠捐赠支持，持有 MariaDB Server 的版权，MariaDB Server 引用了大量 GPL 源码，所以必须永久保持 GPL。

而 MariaDB Corporation 本质上跟 Booking，跟阿里没有区别，只是 MariaDB Foundation 的一个贡献者，给 MariaDB Foundation 贡献代码，最终代码合并依然是 MariaDB Foundation 的社区开发者来完成。例如我负责 Replication 模块的代码合并，原则上我有权拒绝 MariaDB Corporation 提交的代码。

而使用 BSL 授权的 MaxScale 是属于 MariaDB Corporation 从0开始开发的产品，从法律上说使用任何授权都是开发者的自由，要求 MaxScale 也强行 GPL，有点占据道德制高点来指责人的意思。

其实做开源的都知道，如果背后没有商业公司输血，纯粹做开源是很难的，很少有人会自愿付费。Monty 将 MaxScale 修改为 BSL，也是希望大规模使用的用户提供一点费用支撑 MariaDB Corporation 的运营，毕竟公司都没了，靠几个社区开发者，是不足以把 MariaDB 做好的。毕竟 MariaDB 不像 Linux 一样背后有大量的商业公司贡献人力和资金给予支撑。

Percona 的点又转移到了 MariaDB 需要有一个完整的生态，缺少 Proxy 并不是一个完整的生态链的问题。

这点我是赞同的，不过如果 Percona 能够给 MariaDB Foundation 也提供捐赠，我会觉得他说的更有底气一些 :-)