MySQL Cluster 7.0.8aの時点での現状について、僕の認識をメモ。

（使えるかどうかの観点）

・地雷を踏みまくることを覚悟するのであれば使える。7.x系列はまだ枯れていない。最近でも、どんどんバージョンが上がっている。

・したがって、急いでいるときに早いレスポンスで応答してくれる、有償のテクニカルサポートは必須（でも、メールベースなので、やりとりを重ねると解決には結局、半日くらいはかかる。それ以上を求めるのであれば、コンサルティング契約を購入するか、あるいは自分でソースコードをデバッガで追うかが必要）。

・本当にMySQL Clusterでなければならないのか？バッチ処理や、大きなテーブル操作が中心になるのであればInnoDBの方が断然パフォーマンスが出る（特にテーブルがinnodb_buffer_pool_size以内で収まる場合）。

・件の可用性の話で、99.999%の稼働率を実現したいのであれば、SPOFを持たないシステムを構築できる点で、MySQL Cluster（というか、ベースとなっているNDB Cluster）を使う意味がある。

・しかし、構成要素が多くなるため(データノード、SQLノード、MGMノードの３種類）、それらをちゃんと組み合わせて、システムとして高い信頼性を確保するには監視機能とか、結構作り込みが必要になり大変だ。

・ちょっとしたこと（操作、条件）で、データノード全体が落ちてしまったりとか、要するにバグ的な不具合（まさに地雷）がある。

・パフォーマンスの点で、InnoDBと比べて、常に、圧倒的に高速であるとは言えないのが現状（逆に言えば、InnoDBの完成度が非常に高いレベルにあるということである）。

・OracleのSun買収が完了してしまうと、MySQL Clusterの立場はどうなる？というところが不透明である。

（ありえないと思うひどい点）

・特定の危険なクエリが原因で、データノード自体が落ちることが、まま有る（安全側に倒してキャンセルしてくれない。。）

・SQL文の最適化が、まだまだである（インデックスを使ってほしいところで使ってくれない、とか、特定のクエリでは何故かフルテーブルスキャンが走ってしまい激重であることなど）

・そもそも、Primary Key（主キー）に帰着できない、インデックスを使うSQL文を発行すると、すべてのデータノードに対してアクセスが行ってしまうという仕様（同様の理由でJOINも原則使えない）。

・したがって、データノードの性能向上について、スケールアウトできない（主キーで完結するクエリだけ投げるならばスケールアウトすると思われるが、そうであるならば、無理にMySQLとして使う必要はなく、NDB Clusterとして使うのが普通）。

・MySQLのテクニカルサポートを受けるためには、Commercial版のバイナリを使う必要があるのだが、これにはInnoDBのコードが入っていない（なので、NDBを使わない他のテーブルはMyISAMを使うことになる、あるいは、別個にMySQL Enterpriseを入れるか）。


（その他豆知識）

・InnoDBは元々GPLであり、フリーで公開されているGPL版のMySQL Clusterには入っているのだが、こちらのバイナリではサポートが受けられない。

・その一方で、通常の商用版のMySQL EnterpriseはGPLライセンスであり、こちらはそのバイナリでサポートが受けられる、という変則的なルールである。

・Carrier Grade Edtion(CGE)とStandard Editionの区別はversion 6.2から無くなった(CGEに統一された）。