移植 spider 到 MySQL 5.6

MariaDB 中自带了很多 MySQL 中没有的插件。我对其中的 spider 存储引擎很有兴趣。这个引擎可以让 MySQL 作为一个 proxy ，来实现 sharding、高可用等功能。这些功能已经有一些产品实现了，比如 MaxScale、Cobar、OneProxy、Atlas。但是我觉着 spider 把自己作为一个存储引擎来实现这些功能是有其优势的。SQL 解析和查询优化是个非常复杂而且很难做好的工作。其他替代产品都是自己实现，由于复杂性，这些产品都带来了一下限制，没能支持全部常见的 SQL 语句，给使用和实施带来了困难。而作为一个存储引擎，这些工作都由 MySQL 自身完成了，后面的工作就会简单很多，想做点优化的话也会容易些。

由于 MariaDB 从 MySQL 5.5 时代就分道扬镳了，做过很多改动后，和目前版本的 MySQL 已经有了不小差异，所以插件基本上没法直接拿到 MySQL 里编译使用。我就花了点功夫，把 spider 引擎移植到了 MySQL 5.6。

https://github.com/xiezhenye/mysql-plugin-spider-engine

编译使用和一般的插件差不多

cp -r src /path/to/mysql-src/storage/spider  cd /path/to/mysql-src  cmake . -DBUILD_CONFIG=mysql_release -DCMAKE_INSTALL_PREFIX=<mysql install dir>  cd storage/spider  make  make install

之后，执行附带的 install_spider.sql 安装插件，创建所需要的系统表。

mysql ... < scripts/install_spider.sql

具体文档参见 https://mariadb.com/kb/en/mariadb/spider/

在测试过程中，发现安装插件以后，重启 MySQL 后会 crash，然后再也启动不了，移除 ha_spider.so 后才行。然而在 MariaDB 中却是正常的。开始以为是自己移植过程带来的 bug，或者有什么兼容问题未解决。追踪到后来，发现这居然是 MySQL 自身的 bug。于是去提交了一下。http://bugs.mysql.com/bug.php?id=78050

在使用外部 XA 的时候，如果没启用 binlog，会把 XA 信息通过 TC_LOG_MMAP 来持久化。然后 bug 就出在了那里。

这个 bug 曾经在 2009 年就被发现过，2012 年被 fix 过。但是显然并没有改对。待我自己做了 fix 以后，进一步发现，这个 bug 在 MariaDB 中已经被修复过，然后发现原来在 MySQL 5.7 分支下也是修复过的，但是并没应用到 5.6 分支。

都是几个相当低级的 bug。有成员未初始化，指针计算时搞错了指针类型，未判断空指针…… 。虽然这个地方确实是一般使用很难碰到，但是这代码质量简直无语。