以前に書いた、MySQL Clsuterを使ったシステム本運用開始直後のログから2年近くが経過しました。ちょうどいい機会なので、その後の運用を踏まえての感想と、今後の展開について記録を残します。現時点で秘密でない事項についてのみ書きます。


１．SunからOracleへ

知っての通り、MySQLはSunを経てOracleの所有物になりました。
気がついてみるとOSSの主要なデータベース技術のうち、Berkeley DB、InnoDB、MySQLがOracleになってしまいました。

（よかったこと）
GPLのデュアルライセンスは今のところ守られています。そのためMySQLにお金を払ってくれるユーザは、今まで通り限られたままで財政的には厳しいはずなんですが、今のところOracleはMySQLに対してコミットを守っているようです。特に変わったところとして、「リリースのスケジュールが守られるようになった」、「GA版のソフトウェア品質を高いものにするためによりコストをかけるようになった」、「リファクタリングを積極的に展開している」というような話を、しばしば聞く機会が多くなりました。

（よくなかったこと）
僕達のようなユーザ側にしてみると契約絡みが面倒になった以外では良くなかったことというのはありませんでした。とはいえ、Oracleと言う会社はそういうことをやって大金を稼いでいるわけで、商品・役務の売り方と、契約には個人的には興味深いです。


２．MySQL Clusterのバージョンについて

導入時には7.0.8aを使用し、当時はまだ7.1.xはGAになっていなかったわけですが。２年を経た現在においては２つともGAになっています（7.0.28、7.1.17が最新）。community版では7.0.xの積極的な配布は行わず、最新版は提供されていないようです。


品質としてはかなり安定的であるように感じます。バージョンアップ不可避な事象に当たったのはこの２年で１回で、データが壊れる、不整合が生じるといったようなデータベースとして最低限守らなければならないラインで疑義が生じた事はありませんでした。ただ、コンサルタント、サポートも知らなかった隠れた仕様、性能限界、その裏にある設計思想が導入後に明らかになったことは残念でした。


7.0.x系と7.1.x系はEOLのスケジュールが同時タイミングに設定されており、今すぐ新規構築するのであれば、7.1.x系(7.1.17)になるでしょうし、既存の7.0.x系のシステムが動いているのであれば、7.0.28になるでしょう。
ただ、噂では7.0.xの最新版には7.1.xの新機能がバックポートされているため、完全なメンテナンスリリースとも言い難いという話もあるようです。

本当はバージョンアップはなるべく近いバージョンで細かく実施することが、継続的デリバリ(CD)の観点からは必須なのですが、現実には、商用環境において、DBのバージョンアップは、相当難しく、セットアップした使ったバージョンを使い続ける傾向があるため、バージョンの選択は慎重にする必要があります。

何故バージョンを上げないかというと、業務システムのような特殊なアプリでは発行されるクエリは一定のサイクル（時間、日、週、月、年）で似ているため、そうやって一回商用環境で業務を遂行したこと自体が、（DBを含む）システムが枯れた、と認識されるからなのです。このため、逆にDBのバージョンアップとは、それが故の問題が発生する可能性が否定出来ないリスクの高い行為と考えられ、業務が全部問題なく遂行できるだけの担保が求められてしまいます。（※もっとも自社サービスであるならば、状況は違うかもしれません）。