MySQL Cluster セミナーのレポート

September 9th, 2009 by naoya | Filed under day.

Sun が主催した MySQL Cluster セミナーに行ってきました。普段、MySQL Community Server を使用していますが、MySQL Cluster を実際に使われている貴重なセミナーのため参加してみました。

MySQL ダウンロード数: 893,092 DL（過去1年間、Windos 版が一番多い）
MySQL Cluster 7.0: 2009年4月 GAリリース
MySQL 5.1 2008年 GAリリース
MySQL 5.4 2009年 プレビュー版リリース

今回のセミナーは、次のとおり。

• MySQL Cluster 7.0 の紹介 by Sun
• MySQL Cluster 7.0 に最適な Sun の x86 プラットフォーム by Sun
• MarketSpeed における MySQL Cluster 適用事例紹介 by 楽天証券
• MySQL Cluster 導入のケーススタディ by 住商情報システム株式会社

MySQL Cluster 7.0 の紹介

無償と有償で、できるものがある。

無償
ライセンスは、GPL

• MySQL Community Server
• MySQL Cluster Community(OSS) Edition
• MySQL GUI 管理ツール
• MySQL コネクタ(JDBCなど）
• ドキュメント
• フォーラム

有償

• MySQL Enterprise
• MySQL Enterprise Unlimited(サーバ台数無制限）
• MySQL Cluster: Standard Edition, Carrier Grade Edition
• トレーニング
• プロフェッショナルサービス

MySQL Enterprise は、MySQL Community Server の機能はまったく同じで、付加価値をつけての有償契約になっている。モニタリングツール、MySQL Query Analyzer、など。MySQL Query Analyzer は、時間別にクエリーの内容などを見ることができる。

MySQL Cluster の特徴は、次のとおり。

• シェアードナッシング型クラスタ
• コスト: 共有ディスクや特別なハードウェアは不要
• 耐障害性: SPOFなし（素敵！）
• 高可用性: 複数のノード（データノード）に同期型レプリケーションで記録される
• 自動的にフェイルオーバー
• スケーラビリティ: 参照は、コピーされた複数のデータノードで参照される
• 高性能
  - インメモリデータベース（ディスクへのデータ格納も可能）
  - 100,000 QPS のリクエストに対応する
  - マルチスレッド対応

MySQL Cluster と MySQL Enterprise は、まったくの別々の製品になっている。

MySQL Cluster のコンポーネントは、次のとおり。

SQL Node
- 標準的な SQL インターフェース
NDB API
- 組み込み用途などに向けた高いパフォーマンスが必要なときに使える
- C++ API として使える
Data Node
- データストレージ（ディスクあるいはメモリ）
- 自動的なパーティショニング
- 同期型なので、どの Data Node にもまったく同じデータがあることを保証されている
- ディスクには、メモリ上の REDO ログバッファに記録されたトランザクションをディスク上の REDO ログファイルに書き出す（書き出す実行間隔は、デフォルトは 2000ms になっているが設定可能）
Management Node
- 管理および設定
- 2ノードでの可用性

JOIN をしたい場合、MySQL Cluster 単独ではパフォーマンスがでないため、MySQL Cluster から MySQL Community Server に非同期レプリケーションした先で行うことができる。

MySQL Cluster の有償ライセンスは、Standard Edition と Carrier Grade Edition の二種類ある。動的なノード追加は、Carrier Grade Edition のみで利用可能。

MySQL Cluster のベンチマークとして DBT2 を使ったベンチマーク結果が、ここで公開されている。

MySQL Cluster 7.0 に最適な Sun の x86 プラットフォーム

タイトルのとおり、Sun x86 プラットフォームの紹介。
AMD/Intel 両方のハードウェアがある。メモリスロット数は、AMD CPU x 2 で 16 スロット、Intel CPU x 2 で 8 スロットある。ベンダーによっては、メモリスロット数が少ないという情報があったので注意したい。サーバのハードウェア障害が発生する箇所として、電源、 ファン、ハードディスク、がほとんどのこと。Sun のサーバは、SSD を搭載可能。

楽天証券での MySQL Cluster 事例

※このセッションは、極秘のため非公開にしないといけなくなりました。残念です。

MySQL Cluster 導入のケーススタディ

※このセッションは、楽天証券のケーススタディとして取り上げられていたので非公開にしておきます。また、資料は別途修正して公開される予定とのことでした。

MySQL Cluster は、まったく使ったことはなかったけれど、今回のセミナーで概要を把握できたのでよかった。

MySQL Cluster は、基本的にはインメモリデータベース、SPOF なし、JOIN などのクエリーに弱い、などかなり大きなクセがあるので、本番へ導入するにはかなり要注意だと思った。楽天証券でも、テストの段階でいろいろとはまって、 サポートしてもらったそうだ。

このことから、僕が担当しているサービスに MySQL Community Server のかわりに MySQL Cluster を導入するのは、次の点でかなり敷居が高いと思った。

• 物理メモリを多く搭載しているサーバが必要（インメモリデータベースなので、サーバ1台のコストアップにつながる）
• 個人的にクラスターソリューションを導入した経験がまったくないので、導入・検証・運用などにおいて別途サポート契約が必須であること（おそらくけっこうなコストがかかると想定される）
• JOIN のクエリがけっこうある
• MySQL Cluster は仮想化に未対応なので、少なくても Data Node 2 台、Management Node 2台は物理的に必要であること（さらにいうと SQL Node も別のサーバにする場合は、さらに物理的なサーバ台数が必要）

今の段階では上のような考察にはなるが、ミッションクリティカルなシステムを担当しているので、かなり興味深いソリューションであることは間違いないので、引き続きウォッチしていきたい。

データベースまわりでは、DB Magazine 今月号を読んでそろそろ SSD を導入するのは、かなり現実的であると思っています。

更新：2009/09/10 11:01 カテゴリ： MySQL  > Cluster ▲トップ

MySQL Cluster導入のポイント

・sqlノード多く・dataノード少なく
・インメモリtableとして利用すべし
    (ディスクストレージ機能に期待するな)
    共有メモリストレージとしては利用価値あり
        事例：楽天FX
・単純なクエリのみ利用すべし
    join・サブクエリは使うな
・HDDはDBサイズの7倍を用意すべし
    ホント？
・大量データの一括削除は苦手
    分割削除すべし
・dataノードは増やすだけ遅くなる
・仮想OS上ではうまく動かない

更新：2009/09/10 09:38 カテゴリ： MySQL  > Cluster ▲トップ

セミナー
    タイトル
        マルチコアシステムを最大限に活かすMySQLのスケーラビリティと高可用性実現セミナー
    日時
        09/09/09
    楽天での導入事例
        事例
            楽天FX
                ポイント
                    共有メモリストレージとして利用
                メリット
                    他社と比較して安い
                構成
                    sqlノード
                        4
                            2台とめてメンテできた
                    dataノード
                        2
        メモ
            sqlノード
                4
                    2台とめてメンテできた
            管理ノード
                遊んでいる
                dataノードよりアーカイブ化したデータを保存
            仮想OS上では動作せず
            導入前
                大量データのアーカイブ化のところでNG
                    MySQL設定：sendバッファメモリを増やすことで解消
            3ヶ月間問題なく動作
                アラートなし
                停止なし
        要望
            仮想化に対応して
            日本語サポート時間が短すぎ
            レプリケーションのライセンスについて
    住商情報システム
        DBマガジン2008/08号にMySQL Clusterの記事
        楽天での設定値
            data
                50GB
            index
                2GB
            LCP
                12GB×2
        varchar
            ~6.x
                固定長
            7.x~
                可変長対応(8桁まで)
        スレッド対応
            ~6.x
                シングルスレッドのみ
                ndbd
            7.x~
                マルチスレッドOK
                ndbmtd
    MySQL Cluster導入のポイント
        sqlノード多く・dataノード少なく
        インメモリtableとして利用すべし
            (ディスクストレージ機能に期待するな)
            共有メモリストレージとしては利用価値あり
                事例：楽天FX
        単純なクエリのみ利用すべし
            join・サブクエリは使うな
        HDDはDBサイズの7倍を用意すべし
            ホント？
        大量データの一括削除は苦手
            分割削除すべし
        dataノードは増やすだけ遅くなる
        仮想OS上ではうまく動かない

更新：2009/09/10 09:37 カテゴリ： MySQL  > Cluster ▲トップ

MySQL Cluster構成変更がパフォーマンスに与える影響

ベンチマークツールにmBenchを利用して、構成の変更がパフォーマンスに与える影響を調べた。
調査項目は、次の通りである。
尚、グラフ内のパターン表記に関しては、2005年度上期オープンソースソフトウェア活用基盤整備事業「OSS性能・信頼性評価 / 障害解析ツール開発」DB層〜DBMSクラスタ評価編〜（http://www.ipa.go.jp/software/open/forum/development/download/051115/db-cls.pdf）表 8.1-1テスト構成一覧を参照のこと。

計測項目	計測方法
パラレル処理能力	SQL Nodeの数を1〜4に変化させて計測
ノード構成	レプリカ数、ノードグループ数を変化させて計測
インターコネクト	Ethernetの場合とSCIの場合を計測
64bit対応	64bit対応のOS及びソフトウェアを利用して計測

図1 CPU利用率（A2-1-2）

図2 CPU利用率（A2-4-2）

図3 CPU利用率（A2-1-1）

図4 CPU利用率（A6-1-3）

図5 CPU利用率（Ethernet）

図6 CPU利用率（SCI Socket）

図7 CPU利用率（SCI Transporter）

パラレル処理能力
今回の環境では、SQL Nodeの数を増やすほどパフォーマンスが向上した。SQL Nodeを一つ増やすと、スループットは倍以上向上する。
CPUの稼働率に注目すると、SQL Node１台構成ではCPUリソースをうまく扱えていない。SQL Nodeが50 - 60%, Data Nodeが5 - 20%である。
一方SQL Node４台構成ではSQL Nodeが60 - 80%, Data Nodeが20 - 50%と比較的効率良く稼働している。
MySQL 4.1.13では、Data Nodeが2台、レプリカ数が2の構成でSQL Nodeを4台にした時にInnoDBよりもパフォーマンスが向上している。
マシンリソースの関係で今回の検証はSQL Node４台までのテストとなったが、SQL Node数を増加させた時にどこまで性能が向上するか調査すべきである。

レプリカ数及びノードグループ数と性能
更新系トランザクションの劣化は、二層コミットメントにかかるオーバヘッドが増加したためと判断できる。
しかし参照系トランザクションも同様に、レプリカ数の増加と共にパフォーマンスが劣化している。これは、SQL Node側のロスが大きくなったためと推測出来る。接続するData Nodeの数が増えたことでトランザクション処理にかかるロス（特にコミュニケーションに必要なコスト）が増えると予想される。
ところが全表走査した場合は逆転しており、レプリカ数１が最もパフォーマンスが悪く、レプリカ数2と3で10%ほど向上している。同じパーティションへアクセスが集中した時に、1サーバよりも複数サーバで分担することで効率が向上すると思われる。
SQL Node数を十分増やした後に同様のテストを実施すると異なる結果が得られるのでは無いか。SQL Nodeが１つではData Node側のリソースを効率的に使用出来ていないと考えられる。

標準テストの参照系処理（主キーでのアクセス）はA1-4-1が最も早い。データが分散配置しているとコミュニケーションのコストなどが発生するためと思われる。
全表走査では、パラレルスキャンの成果が現れている。
因みにSQL Nodeの数が4つと多いため、全体的にパフォーマンスは良くなっている。
インターコネクト種別と性能
SCIをインターコネクトとして指定した場合に、より高いTPS値を出している。
因みにSCI Socketでの構成は、実際にはData NodeとSQL Nodeとの通信にはTCP/IPが利用されていることを確認した。MySQL ABによれば、現在のバージョンでの仕様とのことである。

更新：2009/09/03 00:22 カテゴリ： MySQL  > Cluster ▲トップ

MySQL Cluster の問題点

・Dataノード上のプロセスがマルチスレッドによる並列処理に対応していない為、マルチコアCPUを活かせない(7.x系で解消？)
・ノードの追加、レプリケーション数の変更などが面倒(7.x系以降、サービスをとめる必要ななくなったらしい？)
・外部キー制約が使えない→トランザクション機能があるので、参照整合性は自前（PHPとかストアドプロシージャー）でなんとか維持可能
・複雑なJOINに弱い(おそくなる)
・オンライン（サービスの停止ないでの）のデータノードの追加が可能な、Carrier Grade Editionが「商用」だということです。
→ http://www-jp.mysql.com/products/database/cluster/features.html

更新：2009/08/24 10:40 カテゴリ： MySQL  > Cluster ▲トップ

== ■管理ノード ==
◆管理ノードプロセス：
/usr/libexec/ndb_mgmd

◆ndb_mgmdを起動するコマンド
/usr/libexec/ndb_mgmd -f /var/lib/mysql-cluster/config.ini

※config.iniの場所はmy.cnfの[mysql_cluster]セクションにおいて指定することも可能です。その場合、コマンドライン引数から-f /path/to/config.iniオプションを省くことが可能です。


◆管理コマンド
ndb_mgm

⇒クラスタの状態を監視したり起動停止／バックアップなどの各種管理作業を行うためのもの
・遠隔のホストで動いている管理ノードへ接続することも可能
・デフォルトではローカルホストの1186番ポートへ接続を試みます
・管理ノードと同じホストで実行する場合には、引数なしで実行すると良い
・　管理ノードは最低限各ノードの開始時に存在していれば良い

各ノードの状態を見る
ndb_mgm> SHOW

起動
ndb_mgm> ALL START

各ノードの状態を見るには、STATUSコマンドを使用します。
ndb_mgm> ALL STATUS

== ■dataノード ==
◆データnode⇒☆各サーバにて行う
○初期化スタート：
/usr/libexec/ndbd --initial

○通常スタート:
/usr/libexec/ndbd

○参考：
/usr/libexec/ndbd
/usr/local/ndb/libexec/ndbd --daemon --ndb-connectstring "nodeid=21;host=192.168.1.1"

== ■SQLノード ==
MySQLサーバーを起動するにはmysqld_safeスクリプトを使用します。通常の場合と全く同じ手順ですね。

shell@sql1> mysqld_safe &

MySQLサーバーが起動したら、mysqlコマンドを使って接続しましょう。

shell@sql1> mysql -root
mysql> SHOW ENGINES;
mysql> SHOW ENGINE NDB STATUS\G

------------------
（参考）
今回は/var/lib/mysqlというディレクトリを、データディレクトリとして使用します。ここにはMySQL Clusterのデータは格納されませんが、各テーブルに対応した.frmファイルや、権限テーブルが格納されます。mysql_install_dbスクリプトを用いてデータディレクトリを初期化しましょう。

shell@sql1# su - mysql
shell@sql1> /user/local/mysql-cluster/scripts/mysql_install_db --datadir=/var/lib/mysql
------------------


◆create table 指定

CREATE TABLE table03 (
    id INT UNSIGNED AUTO_INCREMENT NOT NULL, PRIMARY KEY(id),
    title VARCHAR(255),
    body TEXT
) ENGINE=ndbcluster DEFAULT CHARSET=utf8;

---

○参考
《起動》
service ndb_mgmd start 
service ndbd start 
service mysqld start

《停止》
service mysqld stop
service ndbd stop
service ndb_mgmd stop

更新：2009/08/24 06:49 カテゴリ： MySQL  > Cluster ▲トップ

◆CentOSセットアップ
◆Remi & EPELのパッケージをインストール⇒webmemo.uzuralife.com/article/856
◆yumインストール
yum -y --enablerepo=remi,epel,rpmforge install mysql-server mysql-cluster

◆/var/lib/mysql-cluster/config.ini の設定　⇒管理ノードの設定
管理ノード：[mgm]
データノード：[ndbd]
SQLノード：[mysqld]
【設定例】： webmemo.uzuralife.com/article/1340

※各種ノードの共通の構成情報：[mgm default]、[ndbd default]、[mysqld default]
⇒これらデフォルトの構成情報は、個別の構成情報を記述する前に記載しなければなりません。

◆/etc/my.cnf の設定
[mysqld]
#MySQL Clusterのストレージエンジン（NDB）を有効化する
ndbcluster

#データノードと同様に管理ノードへの接続を確立する
connect-string=192.168.1.40

※すべてのデータをMySQL Clusterへ格納するのであれば、skip-innodbオプションを使用して、InnoDBを無効化するといいでしょう。そうすることでMySQLサーバーの起動が早くなりますし、メモリやCPUの使用を抑えることが可能です。
※MySQL Clusterを使用する場合にはクエリキャッシュを無効にしておきましょう。MySQL Clusterのデータは複数のMySQLサーバーで共有されるのですが、クエリキャッシュは個別のMySQLサーバーだけで有効なのでデータの同期が取れない場合が生じるからです。

MySQL Clusterにおいて使用するMySQLサーバーではあまり多くのメモリは必要ありません。ただしソートや結合を処理する必要があるので、接続ごとに必要なバッファ（ソートバッファなど）を適切に割り振りましょう。

更新：2009/08/24 06:46 カテゴリ： MySQL  > Cluster ▲トップ

他のパーティショニングタイプと違い、KEY によるパーティショニングに使用されたカラムは整数や NULL 値に制限されません。例えば、以下の CREATE TABLE ステートメントは有効です。

CREATE TABLE tm1 (
    s1 CHAR(32) PRIMARY KEY
) 
PARTITION BY KEY(s1) 
PARTITIONS 10;

他のパーティショニングの種類が指定された場合、先のステートメントは有効 ではありません。(注:この場合、単純に PARTITION BY KEY() を使用すれば、有効である上 PARTITION BY KEY(s1) と同等の効果となります。これは、s1 がテーブルのプライマリキーとなるからです。

この件の詳細については 項15.5. 「パーティショニングの制約と制限」 を参照してください。

注:MySQL 5.1.6に始まり、NDB Cluster ストレージエンジンを使用しているテーブルは、テーブルのプライマリキーをパーティショニングキーとして、KEY によって暗黙にパーティショニングされています。クラスタテーブルに明確にプライマリキーがない場合、各クラスタテーブルの NDB ストレージエンジンによって生成された 「hidden」 プライマリキーがパーティショニングキーとして使用されます。

重要NDB Cluster 以外のMySQLストレージ エンジンを使用しているキーパーティショニングされたテーブルは、ALTER TABLE DROP PRIMARY KEY を実行することができません。なぜなら、実行した場合は以下のエラーテキストが現れるからです：ERROR 1466 (HY000): Field in list of fields for partition function not found in table。これは　KEY　によってパーティショニングされたMySQLクラスタテーブルにとっては問題になりません。その場合、「hidden」プライマリキーをテーブルの新しいパーティショニングキーとしてテーブルが再構築されます。章 14. MySQL クラスタ を参照してください。

リニアキーを使用してテーブルをパーティショニングすることもできます。ここに単純な例を記します。

CREATE TABLE tk (
    col1 INT NOT NULL,
    col2 CHAR(5),
    col3 DATE
) 
PARTITION BY LINEAR KEY (col1)
PARTITIONS 3;

LINEAR を使用するのは KEY パーティショニングに対しても HASH パーティショニングに対しても同様の効果をもたらします。この時パーティショニングはモジュロ算術よりも二乗アルゴリズムを使用してパーティショニング番号が派生されます。アルゴリズムとその意味合いについては、 項15.2.3.1. 「LINEAR HASH パーティショニング」 を参照してください。

---

KEY を使用してのパーティショニングは NDBCluster 記憶エンジンを使用することでサポートされていますが、MySQL 5.1 内のクラスタテーブルでは他の種類のユーザによって定義されるパーティショニングはサポートされません。 

更新：2009/08/21 06:39 カテゴリ： MySQL  > Cluster ▲トップ

14.3.6. 安全なシャットダウンと再起動

クラスタをシャットダウンするには、MGM ノードをホストしているマシンのシェルに以下のコマンドを入力します。

shell> ndb_mgm -e shutdown

ここの-e オプションがコマンドをシェルから ndb_mgm クライアントに渡すために使用されます。項3.3.1. 「コマンドラインにおけるオプションの使用」 参照。そのコマンドが ndb_mgm、ndb_mgmd、および他の ndbd プロセスを終了させます。SQL ノードは mysqladmin shutdown および他の方法でショットダウンできます。

クラスタを再起動するには、これらのコマンドを使用します。

クラスタのバックアップを取るには 項14.8.2. 「バックアップを作成するためのマネジメント クライアントの使用」 を参照してください。

クラスタをバックアップから復旧するには ndb_restore コマンドを使用する必要があります。これは 項14.8.3. 「クラスタのバックアップの復旧方法」 で説明しています。

更新：2009/08/21 06:22 カテゴリ： MySQL  > Cluster ▲トップ

 [MGM DEFAULT]
# PortNumber: 1186

[TCP DEFAULT]
portnumber: 1186

[NDB_MGMD]
Id: 1
HostName: 192.168.253.131
DataDir: /var/lib/mysql-cluster

[NDBD DEFAULT]
NoOfReplicas: 2
DataMemory: 80M
IndexMemory: 24M

# ServerPort = 63132
# MaxNoOfConcurrentOperations=10000
# TimeBetweenWatchDogCheck=30000
# MaxNoOfOrderedIndexes=512

[NDBD]
Id: 2
HostName: 192.168.253.135
DataDir: /var/lib/ndb/data

[NDBD]
Id: 3
HostName: 192.168.253.136
DataDir: /var/lib/ndb/data

[MYSQLD]
Id: 4
HostName: 192.168.253.131

[MYSQLD]

更新：2009/08/19 10:13 カテゴリ： MySQL  > Cluster ▲トップ