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

前言

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 也提供捐赠，我会觉得他说的更有底气一些 :-)

代码规范

然后 svoj 来简单总结了下 10.2 还剩下的 Issue，Replication 剩下的不算多，12月 GA 我应该赶得上 ^_^

然后就是代码规范了，无规矩不成方圆，所有开发者都需要遵循一套规范，这样大家的代码才可以交流，才可以相互修改。

所有的代码提交前都要自己编译一遍先自测通过所有的测试集，当然这是废话，必须的，这都通不过就提交，我直接给加入黑名单 -_-

对于 Dead Code 讲了要怎么处理，无意义的条件分支，没用了就干掉。

对于注释，有些注释十几年了，不打算做就干脆去掉，有些注释根本没写清楚意思，有些注释不用写也都知道简直废话。

给社区提交代码一定要注意这些。

社区要做的事

然后 Eric 主持讨论接下来 MariaDB Foundation 要在社区做的事。

大家认为包括 MariaDB Corporation 和 MariaDB Foundation 应该在所有社交平台有不一样的账号，不能共用 MariaDB 这个账号，讨论这个我只能是个吃瓜群众了，反正什么 Facebook、Twitter 我都访问不了 (＞﹏＜) 你们开心就好……

还有基金会要把代码规范更加文档化，针对各种情况应该怎么写代码，要有明确的指导，减少合并者的工作量和打回次数。

还有 JIRA 对于安全性 Issue 的私密保护和公告方式，每个版本 Release 的时间集中公告之类的。

兼容性

然后 Colin 作为社区代表对比了目前 MySQL 和 MariaDB 的兼容性。

其实总的来说，功能上基本都兼容，代码实现上完全是两套。就比如说加密，这个是差异最大的，MySQL只加密数据文件，MariaDB 还加密了 Binlog 和 Redo。

虽说 MariaDB 的加密更全面，但是这就要求使用者需要知道这些差异，这些差异，MariaDB 也应该提供更多的文档一一对比说明。

这个我是很赞同的。

Roadmap

最后就讨论 10.2 GA 的 Roadmap 和 10.3 的计划了。

比如默认字符集是不是要改成 UTF8MB4，这个投票基本上都认为要，但是也有反对的声音，认为这样做临时表会无谓的增大，没必要用 UTF8MB4 的人只浪费了空间没得到好处。

这个吧，移动互联网是趋势，是在不需要就自己手动设置参数改一下吧，毕竟看起来需要的人更多， 8.0 也要改了不是么。

10.3 的计划，很开放的讨论。

（这位绿衣服的同学就是Percona的CEO，Peter）

TokuDB 可能要被移除了，Facebook 当然是无比赞成，TokuDB 去掉自然就是 RocksDB 顶上了。

但是 Percona 就伤心了，好不容易买了个自己的引擎，竟然要从上游移除，求 Peter 心理阴影的面积……

但是话也说回来，Peter 自己也支支吾吾说不清到底有几个人在开发 TokuDB，看起来就像没人维护一样。

最后，梳理还在等待进入 10.2 的功能，包括我的 DML 闪回功能，还要最后做一点优化。

还有 MyRocks 要赶在 10.2 GA 前加进去。

DES 加密也要移除了，毕竟这玩意在当前的技术条件下已经不安全了~

总结

最后，基金会的所有开发者一起合照。（我和腾讯的梁飞龙分别代表 阿里 和 腾讯 两家中国对 MySQL/MariaDB 研发贡献最大的公司）

非常开心看到国内越来越多的公司和开发者加入上游的开发，Commit Log 中可以看到越来越多的中国名字，无论公司之间如何，能够参与开源，贡献自己的智力，就是非常好的！