こんにちは、海老原です。

ちょっとMySQL Clusterに興味が湧いたので、
  http://www.mysql.com/products/cluster/index.html
の右側のリンクからホワイトペーパーを入手して読んでみました。

MySQL Clusterの日本語概要はこちら。
http://japan.cnet.com/news/ent/story/0,2000047623,20064908,00.htm?ref=rss

読んだついでに自分なりにサマリーしてみました。
書き方が汚いですが片手間なので勘弁してください。

あと、もし「疑問」のところ、ご存知の方がいればぜひ教えてください。

◆何ができる?
複数のノードで動作するデータベースを協調させることで、
可用性、信頼性、性能を向上させられる。

99.999%の可用性を実現。
 -> 計画停止を含め、1年間で5分のダウンタイム

◆アーキテクチャ
Shared Nothing型クラスタ。
共有ディスク構成だとそこがSingle Point Of Failureになるが、
MySQL ClusterはShared NothingなのでNo SPOF。

Oracleで言うところの同期型マルチマスターレプリケーション
のようなものみたい。
　同期型: 各ノードのDBは常に同じ状態
　マルチマスター: どのノードに対しても更新が可能

疑問)
2フェーズコミットするのかな?

更新系のスケーラビリティには限界がありそうな・・・。

そもそもマルチマスターなんだよな?
(文脈的にはそうなんだけど明言はされてない)

◆高可用性
ノードダウン時はアプリは別ノードに1秒以下でフェイルオーバー。

ノードリカバリは自動的に行われる。

全ノードダウン時も整合性を保持したままリカバリ可能。

Shared Nothingなので構成ノードが地理的に離れていてもOK。
 -> 災害対策にもなりまっせ

疑問)
アプリには透過的にDBセッションがフェイルオーバーするのか?

ノードダウン時点で実行中だったトランザクションも、フェイル
オーバー先で継続できるのだろうか?

◆高性能なMain Memory Database
My SQL ClusterはMain Memory Databaseであり、超・高性能。
全データをIn-memoryに配置し、トランザクションログはディスクに
非同期書き込みする。

疑問)
この機能はクラスタと直接関係あるのか?

ログを非同期書き込みすれば早くなるのは分かるけど障害時の
リカバリは大丈夫?

もしかして非同期書き込み＝コミットされたトランザクションが
障害時に失われる可能性があるから、MySQL Clusterでのみ使える
ということ?

◆その他
初期投資は少なくして、負荷の増大に応じてノードを増やしていく
ことが可能。ちなみにノード追加はダウンタイムが発生しない。

オンラインバックアップ・リストアが可能。

特定のベンダー特有のクラスタリング技術を使う必要がないので、
安価なハードウェアでHAを実現できる。

--
海老原 雄一郎 / EBIHARA Yuichiro
E-mail: Yuichiro.Ebihara@xxxxxxxxxx