これに答えるための方策として、まだ、僕自身うまい方法を考えついていないのですが、全く同じデータをコピーした新環境に全く同様にクエリを旧環境と新環境の両方にミラーして投げ続けて検証する、といったことができないかな、と考えています（RBRミラーリングではデータはコピーされますが、データベースへのクエリを再現することはできないですし）。


３．初めてMySQL CLusterの導入を考える皆さんへのアドバイス

MySQL Clusterに求める機能として、【高速な読み書き】、【Active/Active構成の高可用性システム】のどちらかに大きなメリットを感じないのであれば、採用を見送ることを考えるべきでしょう。特に、今はSSDという選択肢もありますから、まずはそれで十分か、不足があるかの観点で考えてみてはいかがでしょうか。

以下には、MySQL Cluster導入時の検討事項について導入後〜２年間の運用を振り返って記載します。

・MySQL Clusterの皮を被ってはいるが、完全ではない。できることが、できなかったりするので、差違について十分に調査・見当すること。そのままInnoDBがオンメモリになったつもりで使うと、GCP Stopが発生する。

・高速な読み書きができるのは、基本的に主キー（プライマリキー）に帰着できるケースのみ。インデックスを使ったアクセスは性能上の限界値が低い。

・JOINは使えるがパフォーマンスが出ない（開発中の7.2のAQLで改善の見込みあり）。

・ユニークインデックスは主キーに次いで高速なアクセスを実現するけれども、特別なサポートテーブルを内部に生成するため、それが故の制約が存在する。

・ストレージエンジンが異なるテーブル通したトランザクションを張ることはやめるべき(InnoDBとNDBなど、分離レベルも異なるし、出来ないと考えるべき）。

・ここで言うところの高可用性は、Active-Active構成で、SPOF無しの構成を本気で組む前提がある場合で、そうでないならば、無理にMySQL Clusterではなく、通常版のMySQLを使用することを勧める。


最初に書いたとおり、MySQL Clusterと通常版のMySQLは似て非なるものです。普通のMySQLの知識は30%くらいしか通用しないので注意して下さい。できれば、そばに詳しい人を置くか、最低でもサポート契約が無いと、プロダクション環境で使用するのは厳しいと思います。



４．今後の展開に期待すること

昨年ぐらいにNoSQLがもてはやされましたが、MySQL ClusterのベースとなっているNDBはもともとそのNoSQLで、NoSQLは速いけれど、スキーマを投入してデータ抽出をSQL構文でやりたいというのがそのモチベーションなわけで、ある意味、時代を先取りした部分もあると考えています。

SSDが安価になり、性能観点で、無理にインメモリDBにこだわる時代では無くなりましたが、超高可用性と、比較的容易にスケールアウト可能なアーキテクチャーであることにはまだまだ魅力的な所があります。僕は試していませんが、NDB Disk storageも（スピードは出ませんが）安定して動いているという噂です。

今後もMySQL Clusterが主要な柱となるべく開発リソースが投入され続けるといいですね。