MySQLのクラスタリング（前編）

第3章●MySQLのクラスタリング（前編）
DBクラスタの基礎知識からMySQL Clusterの導入まで
第3章
MySQLのクラスタリング（前編）
DBクラスタの基礎知識からMySQL Clusterの導入まで
住商情報システム㈱
廣濱顕司 HIROHAMA Kenji
池田徹郎 IKEDA Tetsuro
MySQL Clusterの
生い立ち
はじめに
MySQLは世界で最も普及しているオープンソース
MySQL Clusterは，2004年5月に米国オーランドの
のDBMS（データベース管理システム）です．その
MySQLユーザ・カンファレンスで初めて公になりまし
MySQLではVer 4.1から「MySQL Cluster」という名
た．しかし製品自体には10年間の歴史があります．
称でクラスタリング機能が実装されました．MySQL
1996年にEricssonの研究者グループによってテレコ
はMySQL の開発者たちによって設立された会社
ム／IP環境向けの高可用性クラスタ・データベースと
MySQL ABによって管理されており，現在も開発が進
してNDB（Network Data Base） Clusterが開発され
められています．
たことが始まりです．
編注1
本誌Vol.38にてJBossのクラスタリング機能
が，
2000年にEricsson Business Innovation社によりベ
Vol.41にてTomcatのクラスタリング機能編注2 が紹介さ
ンチャ企業としてAlzato社が設立され，同社からNDB
れているように，アプリケーションサーバの分野でも
Clusterとしてリリースされました．その後，2003年9
すでにオープンソースのプロダクトによってクラスタ
月にMySQL ABによってAlzato社が買収され，MySQL
リング機能は実装されています．これにMySQL Cluster
Ver.4.1以降のストレージエンジンの1つとして統合さ
が加わり，私たちはオープンソースプロダクトだけで
れました．現在，MySQL ClusterはMySQL ABのホ
アプリケーションサーバとデータベースサーバの双方
ームページよりダウンロードが可能です．
をクラスタ化したシステムを構築できます．
小さなアプリケーションを素早く効率的に構築する
ことが求められる時代，JavaエンジニアもJava周辺だ
けでなくシステム全体のアーキテクチャを把握する必
要があります．またDBMSをクラスタ構成にした場
合，直接Javaアプリケーション側で配慮するポイント
がいくつかあります．
ヨーロッパではMySQL Clusterを利用した事例がい
くつも報告されています．
DBMSのクラスタシス
テム
一般的に，DBMSでクラスタシステムを構成する一
番の目的は，HA（High Availability，可用性）向上
今回の記事では，本章で一般的なDBMSのクラス
です．つまりDBMSのダウンタイムを少なくして，ア
タ構成とMySQL Clusterのアーキテクチャを，次章で
プリケーション全体を継続的に稼働させる場合に
JavaアプリケーションからMySQL Clusterを使う場合
DBMSのクラスタリングが検討されます（このような
の方法，そして動作検証などを紹介します．
クラスタシステムはHAクラスタとも呼ばれます）
．主
なDBMSベンダは標準，あるいはオプションでクラス
編注1）
『JAVA PRESS』Vol.38 p.177〜206 特別企画「JBossのクラスタリング」
編注2）
『JAVA PRESS』Vol.41 p.163〜180 特別企画「Tomcatのクラスタリング」
JAVA PRESS Vol.42 ●
165
O/RマッピングからDBクラスタまで
テム構築時に注意が必要です．
図1 共有ディスク型
アプリケーション
アプリケーション
アプリケーション
非共有ディスク型
DBMS
サーバ
インスタンス
DBMS
サーバ
インスタンス
DBMS
サーバ
インスタンス
短所:
1. 共有ディスクがSPoFとなり得る
2. 共有ディスクの排他制御が必要
MySQL Cluster，IBM DB2など
共有ディスクを必要とせず，DBMSサーバはロー
カルのディスクでデータを読み書きします（図2）．
長所:
1. データのバックアップが容易
2. ディスクの追加などが容易
それぞれのデータは別途同期されます．共有ディス
クなど高価なハードウェア（以下H/W）を必要と
しない反面，データの同期が必要なためインターコ
共有ディスク
ネクト（ノード間通信）上を大量のデータが流れる
可能性があり，注意が必要です．
図2 非共有ディスク型
アプリケーション
アプリケーション
データの同期方式は，いつでも同じ内容であるこ
アプリケーション
とが保証されている「同期型」と，一定の間隔で同
期する「非同期型」の2種類があります．
DBMS
サーバ
インスタンス
DBMS
サーバ
インスタンス
DBMS
サーバ
インスタンス
ディスク監視と同期ディスク監視と同期ディスク
短所:
1. 複数のディスクで同期をと
る必要がある
2. インターコネクト上に大量
データが流れる可能性がある
長所:
1. H/WにSPoFがない
2. 共有ストレージなど高価な
H/Wを必要としない
アクティブ・スタンバイ型
共有ディスク型でファイルなどを共有する場合は，
アクセス競合などを起こさないように，待機系から
はデータを参照できないように制御する，あるいは
DBMSを起動しないといった手法がとられます．フ
タ機能を提供しています．HAクラスタシステムを分
ェールオーバ時は，待機系にてDBMSの起動が必要で
類すると，以下の通りとなります．どれも一長一短で
時間はかかりますが，アクセス制御が簡単で済むとい
すので，その長所と短所をよく理解してシステムを構
う利点もあります．
築する必要があります．
アクティブ・アクティブ型
¡共有ディスク型と非共有ディスク型
¡アクティブ・スタンバイ型とアクティブ・アクティ
MySQL Cluster，Oracle RAC，Microsoft SQL Server，
IBM DB2など（ただし構成や制限は各DBMSによっ
ブ型
て異なります）
以降で，それぞれの特徴を簡単に見ていきます．
共有ディスク型
Oracle RAC，Microsoft SQL Serverなど
共有ストレージを必要とするタイプで，複数の
DBMSサーバがディスクを共有します（図1）
．共有デ
複数のサーバ上でDBMSが動作します．それぞれの
サーバが担当するテーブルなどを決めて競合が発生し
ないように構成する場合が多いです．フェールオーバ
は待機系のサーバに切り替えるだけなので短時間で済
みますが，フェールオーバ時の負荷も考慮に入れて設
計する必要があります．
ィスクの整合性を保つために，排他制御などが必要と
なります．
DBMSのトレンド
データの同期をとる必要がないという長所がある反
面，共有ディスクがSPoF（Single Point of Failure，
多くのDBMSではディスク上でデータを保管，管理
単一障害点）となり得るので電源，ストレージパス，
し，頻繁にアクセスするデータのみをメモリ上にキャッ
NIC，およびディスクなどの2重化が必要となりシス
シュとして管理しパフォーマンスを向上させています．
166 ● JAVA PRESS Vol.42
第3章●MySQLのクラスタリング（前編）
DBクラスタの基礎知識からMySQL Clusterの導入まで
また，最近はディスクを使わずに，すべてのデータ
をメモリ上で管理するインメモリデータベースがいく
つも登場しています．インデックスの作成やキャッシ
ュの割り当てなどのチューニングに頭を悩ませること
なく，簡単に高いパフォーマンスのシステムを構築で
きます．インメモリデータベースではTimesTenなど
が有名です．またMySQL Clusterもインメモリデータ
ベースに分類されます．
昨今，メモリは年々安くなっており，また64ビット
ジエンジン」という形式を採用しています．マルチス
トレージエンジン・アーキテクチャによって，
¡コネクションなどのハンドリングやSQL文の解析，
最適化など，アプリケーションへのインタフェース
部分（MySQLデータベース管理レベル）
¡実際にデータを管理する部分（ストレージエンジン
レベル）
という2つの部分から構成されています（図3）
．NDB
対応のOS，H/Wなどの出現によって大容量のメモリ
Clusterとの統合の過程で，ストレージエンジンとして
を安価に利用することが可能となりました．以前のよ
NDBが新しく追加されました．
うに頻繁にアクセスするデータのみメモリに載せるので
データベース管理者は，作成するテーブルごとに適
はなく，全データをメモリで管理することも夢ではなく
したストレージエンジンを選択します．高速性に優れ，
なってきています．今後，近いうちにインメモリデータ
検索用途に適した非トランザクション対応のMyISAM，
ベース製品がいくつも登場するのではないでしょうか．
トランザクションをフルサポートするInnoDB，メモ
MySQL Clusterの
アーキテクチャ
一言でいうとMySQL Clusterは，Alzato社が開発し
リ上で動作するHeap，などの主なストレージエンジン
に加えて，NDBが加わりました．NDBストレージエ
ンジンがNDB APIを実装しています（コラム「NDB
Clusterのアーキテクチャ」参照）
．
たNDB ClusterをMySQLサーバと統合した，非共有
MySQL Cluster
ディスク型でアクティブ・アクティブ型のインメモリ
データベースです．共有ディスクを必要としないため
MySQL Clusterは，3種類のノードで構成されてい
に高価なH/Wを必要とせず，アクティブ・アクティ
ます（図4）
．ノードという単語は文脈によって意味が
ブ型なのでフェールオーバに必要な時間は非常に短い
変わりますが，MySQL Cluster周りではプロセスの意
です．またメモリベースのデータベースであるので高
味で使用されています．以下で詳細に各ノードとその
速にデータへアクセスできます．MySQL Clusterの特
他の構成要素を見ていきます．
徴を以下に列挙します．
■ Managementノード
¡非共有ディスク型
システム全体の設定を管理します．Dataノードと
¡アクティブ・アクティブ型
SQLノードは，起動時にManagementノードより構成
¡インメモリデータベース
情報を取得します．各ノード起動後は，Management
MySQLにおける
MySQL Clusterの位置づけ
MySQL ABが2003年10月にAlzato社を買収して，
図3 MySQLのストレージエンジン構成
アプリケーション
Connector/J
MySQLとNDB Clusterの統合が始まりました．統合
は未だ完全ではありませんが，執筆時点での最新バー
MySQL
SQL文解析
最適化
MySQLデータベース管理レベル
実行
ジョン4.1.10での状況を以下に見ていきます．
NDB
Heap
て作られています．特徴的な構造として，「ストレー
InnoDB
プンソースのDBMSで，安定性と高速性を最重視し
MyISAM
ここでMySQLを簡単に説明します．MySQLはオー
ストレージエンジンレベル
NDB API
JAVA PRESS Vol.42 ●
167
O/RマッピングからDBクラスタまで
NDB Clusterのアーキテクチャ
Alzato 社が開発したNDB Cluster ではクラスタシス
テムはMGM ノード，Data ノード，API ノードの3 種類
のノードより構成されます（図a）
．
NDB Cluster のシステムを利用するためには，アプリ
ケーション開発者がアプリケーションをC++ で記述する必
要があり，SQL のインタフェースは実装していませんでし
た．高速に動作する反面，利用するためには敷居が高かっ
たことも事実です．このような構成になっていたのは，当
初はネットワーク機器向けのデータベースソフトとして開
発されたためと思われます．
NDB Cluster は図a のような構成になっています．全
Data ノードがハートビートによって常にお互いの生存確
認を行っています．また，現在のMySQL Cluster との
決定的な違いとして，クラスタシステムのクライアントで
あるAPI ノードは常に全Data ノードと接続しているので，
図4 MySQL Cluster
アプリケーション
図a NDB Cluster
APIノード
APIノード
APIノード
APIノード
C++
アプリケーション
NDB API
Dataノード
Dataノード
Dataノード
Dataノード
Management
クランアント
MGMノード
Management
API
フェールオーバに特別なしくみは不要です．Data ノード
障害時には，障害ノードの切り離しと再構成が発生します
が，これらは自動で行われます．
クライアントであるAPIノードからは，Dataノードのダ
ウンなどを意識することなくフェールオーバが行われます．
ョンとして選択できます．Dataノードの役割はほか
アプリケーション
アプリケーション
ブローカは別途考慮する
必要がある
ブローカ
に，分散トランザクションの管理，ノードリカバリ，
ディスクへのチェックポイント，オンラインバックア
ップと関連するタスクの処理などです．
またトランザクションコーディネータ（TC）という
SQLノード SQLノード SQLノード
（MySQL）（MySQL）（MySQL）
役割も担い，ハッシュテーブルを利用してDataノード
へ実際のデータを分散して保存，処理します（詳細は
TC
Dataノード
Dataノード
Dataノード
Dataノード
後述）
．
Management
クランアント
Arbitrator
Managementノード
Management
API
ノードは必須ではありません．
■ SQLノード（Serverノード）
MySQLのストレージエンジンの1つNDBエンジン
がNDB APIを介してDataノードへ接続します．デー
また，Managementノードよりシステムのバックア
タベース管理者は，ストレージエンジンとしてNDB
ップとリストが可能です．デフォルト設定では
を選択するだけでMySQLサーバのクライアントから
Arbitrator（調停者）の役割をManagementノードが
MySQL Clusterを利用することができます．
担い，スプリットブレイン発生時に処理を続行する側
を決定します．
■ Managementクライアント
またデータベース管理者はManagementクライアン
Managementノードへアクセスして各ノードの状態
トよりManagementノードへアクセスして，各ノード
確認，手動によるバックアップなどを行うコマンドラ
の状態などを確認できます．
インのユーティリティです．
■ Dataノード（Storageノード）
■ アプリケーション
実際にデータを管理するノードです．Ver. 4.1.10で
データベースを利用するアプリケーションです．
は，データはメモリ上でのみ管理されますが，開発中
JAVA，PHP，.NETなどのプログラミング言語で記述
のバージョンではディスク上へのデータ格納もオプシ
されます．
168 ● JAVA PRESS Vol.42
第3章●MySQLのクラスタリング（前編）
DBクラスタの基礎知識からMySQL Clusterの導入まで
■ ブローカ
のフラグメントに分割されて，各Dataノードで管理さ
本来，クラスタシステムでは，クライアントアプリ
れます．ノードグループは同じデータを持つDataノー
ケーションから透過的にサーバにアクセスして，（サ
ドの集合です．この構成ではサーバ1とサーバ2がまっ
ーバ故障時などの）必要時にはクライアントに意識さ
たく同じデータを持っているので1つのサーバ障害時
せずにフェールオーバして処理するのが理想です．
にも継続して処理が行えます．
ところが，MySQL Clusterでは従来のクライアント
共有ディスクを持たないのでデータの同期が必要で
部分がMySQLサーバとなっているために（コラム
すが，MySQL Clusterでは2層コミットメントで同期
「NDBクラスタのアーキテクチャ」参照），構成時に
を実現しています．2層コミットメントのメカニズム
注意が必要です．つまり，Dataノードで障害が発生
の下（図6参照）
，Dataノード1とDataノード2はいつ
してもフェールオーバは自動でされますが，MySQL
でも同一のデータを持っていることが保証されていま
サーバの障害時にはフェールオーバ機能は標準ではサ
す．また同じフラグメントのうち，MySQL Clusterが
ポートしていません．
内部でプライマリレプリカとセカンダリレプリカと区
これを回避するために「ブローカ」という概念が思
別します．
いつきます．
「ブローカ」をクライアントアプリケーシ
図5の構成ではF1のプライマリレプリカはDataノー
ョンとMySQLサーバとの間に追加して，アプリケー
ド1に，セカンダリレプリカはDataノード2にありま
ション側からは実際のMySQLサーバの状態を意識す
す．データはいつでも同じことが保証されているのに，
ることなく接続，処理を続けます．
プライマリ，セカンダリの区別があるのは次の理由か
らです．2層コミットメントではinsert，update，delete
¡サーバ側でのブローカ実装
図5 データの分散配置
MySQLサーバの機能として「ブローカ」
テーブル 1
ユーザID ユーザ名その他
を実装する予定は，現在のところありませ
ん．そのため，必要に応じてLVS（Linux
Virtual Server）やHigh-Availability.Com社
テーブルはハッシュ
テーブルに基づいて各
Dataノードへ分散配置
されます
Dataノードの関数
総ノード＝レプリカ数×ノードグループ
F1
プライマリレプリカ
F2
セカンダリレプリカ
F3
F4
のRSF-1などで仮想ホストや仮想IPアドレス
を実装します．
¡クライアント側でのブローカ実装
Connector/Jのフェールオーバ機能を，
MySQL Clusterと組み合わせて使うことがで
物理構成
サーバ1
論理構成
サーバ2
Dataノード 1
Dataノード 2
Dataノード 3
Dataノード 4
ノードグループ 1
ノードグループ 2
F1
F1
F2
F2
F3
F3
F4
F4
Data
Data
ノード 1 ノード 2
Data
Data
ノード 3 ノード 4
きます．詳細は次章で説明します．またそ
TCP/IP
の他のコネクタも現在対応中のようです．
MySQL Cluster：4 Dataノード構成（2 dual processorサーバ）レプリカ数＝2
データの分散管理
図6 同期レプリケーションと2層コミットメント
TC
TCの役割は，実際には各Dataノード
が交代(ラウンドロビン)で担当
MySQL Clusterでは，HA向上とロードバ
ランスを同時に満たすために複数のDataノー
Dataノード 1
Dataノード 3
Dataノード 2
Dataノード 4
ノードグループ 1
ノードグループ 2
ド間でデータを分散して管理します（図5）
．
2つのデュアルプロセッサ・サーバ上で，そ
れぞれDataノードを2つずつ，合計4つの
Dataノードを動作させる場合を例に考えま
す．レプリカ数（複製の数）は2です（図5
参照）
．データは図のようにF1，F2，F3，F4
2層コミットメント
準備フェーズ：状態確認と変更するデータの受け取り
コミットフェーズ：変更が実行される
JAVA PRESS Vol.42 ●
169
O/RマッピングからDBクラスタまで
する場合に全Dataノードをロックします．全Dataノ
ドロビンアルゴリズムを使ってトランザクションごと
ードが変更可能な状態であることを確認した上で，い
に代わります．
っせいに更新がかかり，これが同期レプリケーション
データのリカバリ
を可能にしています（図6）
．
データの読み取り時，すなわちselect文の発行時に
ロックされるのがプライマリレプリカです（committed
インメモリデータベースでデータの永続性は，どの
ように保証されるのかを以下に見ていきます．
readの場合にはセカンダリレプリカがロックされます）
．
また，トリガーやバックアップ，ノードリカバリも基
■ ノードリカバリ
Dataノード1がダウンした場合，まったく同じデー
本的にプライマリレプリカが使われます．
TC
（Transaction Coordinator）
データは，TCが管理するハッシュテーブルに基づ
タがDataノード2に入っていますので処理は続行され
ます（図7）
．また，Dataノード2のF1がプライマリレ
プリカとして再構成されます．Dataノード1を復帰後，
いて各Dataノードへ分散して格納されます．SQLノ
データのリカバリはDataノード2のデータがそのまま
ードからのリクエストは，まずTCが受け付けます．そ
Dataノード1へコピーされます．コピー中にDataノー
の後，ハッシュテーブルを基に適切なDataノードへ振
ド2に行われた変更は，その後で同期され，データの
り分けます（図6）
．大量のデータを取得する場合は複
同期が完了した段階で自動的に4ノードで再構成され
数サーバから平行してデータを取得しますので，高速
ます．
上記の構成でサーバ1がダウンした場合も同様です
な処理が可能です．
MySQL Clusterでは共有ディスクが不要なのでH/W
（図 8）．完全なコピーがサーバ2 にありますので，
のSPoFを持ちません．TCがS/WのSPoFになりそう
MySQL Clusterの処理は続行されます．新しいハード
にも見えますが，実際には各Dataノードが交代でTC
ウェアをセットアップ後，同様に自動でデータの同期
の役割を果たすので標準でTCは多重化されています．
と再構成が実行されます．
どのDataノードがTCの役割を担当するかは，ラウン
■ システムリカバリ
図7 ノード障害
MySQL Clusterはインメモリデータベースなので
プライマリレプリカ
セカンダリレプリカ
物理構成
サーバ1
論理構成
サーバ2
Dataノード 1
Dataノード 2
Dataノード 3
Dataノード 4
ノードグループ 1
F1
F1
F2
F2
F3
F3
F4
F4
Data
Data
ノード 1 ノード 2
TCP/IP
ノードグループ2
Data
Data
ノード 3 ノード 4
MySQL Cluster：4 Dataノード構成（2 dual processorサーバ）レプリカ数＝2
Dataノード 1
Dataノード 3
Dataノード 2
Dataノード 4
TCP/IP
れぞれのDataノードが自身で管理しているデータの
イメージをディスクに保存します．同時にメモリ上
のREDO情報（DBMSに対して行われたすべての
またGCP（Global Check Point）と呼ばれるタ
セカンダリレプリカ
イミングで，メモリ上のREDO情報をディスクに保
存します．GCPの間隔はデフォルトで2秒ですが必
ノードグループ 1
ノードグループ 2
F1
F2
F1
F3
F3
Data
Data
ノード 1 ノード 2
F2
F4
F4
Data
Data
ノード 3 ノード 4
MySQL Cluster：4 Dataノード構成（2 dual processorサーバ）レプリカ数＝2
170 ● JAVA PRESS Vol.42
れます．LCP（Local Check Point）という点でそ
プライマリレプリカ
論理構成
サーバ2
MySQL Clusterは一定間隔でデータとログをディ
スクに保存していますのでデータの永続性は保証さ
コミット済変更の記録）の不要部を削除します．
図8 サーバ障害（複数ノード障害）
物理構成
サーバ1
データはすべてメモリ上で管理されます．しかし，
要に応じて変更可能です．またGCPはグループコ
ミットとも呼ばれます．
MySQL Cluster全体がクラッシュしても，これら
の情報を基にしてデータが自動的に復元されます．
第3章●MySQLのクラスタリング（前編）
DBクラスタの基礎知識からMySQL Clusterの導入まで
■ ホットバックアップ
まず，mysqlグループを作成し，そのグループに所
ノードリカバリ，システムリカバリは不慮の事態に
陥ったときにMySQL Clusterが自動で行う機能です．
属するmysqlユーザを作成します（図11）
．
http://dev.mysql.com/downloads/mysql/4.1.html
通常のシステム運用時は管理者が定期的にバックアッ
より，mysqlのMaxバージョンをダウンロードして
プを取ります．
/usr/localにコピーします．/usr/localディレクトリ
MySQL Clusterでは，Managementクライアント
より手動によるホットバックアップ（データベースを
に移動し，tarで解凍し，解凍後のディレクトリへシ
ンボリックリンクを作成します（図12）
．
その後，MySQLの実行モジュールの格納場所にパ
停止しないで行うバックアップ）が可能です．
スを通しておきます（図13）
．
MySQLの導入
今回はこのスクリプトをmysqlユーザのログインシ
ェル（/home/mysql/.bashrc）の最下段に記述して
MySQL Clusterを起動させる前に，今回インスト
ールしたMySQL Clusterの構成を説明します．
図9 本稿および次章での検証環境
MySQL Clusterをインストールするといっても，Max
バージョンのMySQLをインストールする以外には，通
常のMySQL（MyISAMやInnoDBなど）をインスト
アプリケーション
マシンスペック
使用プロダクト
Connector/J
CPU:PentiumⅣ 1.7GHz
Memory:1GByte
OS:SUSE Linux9.2
JDK:J2SE 1.4.2̲7
MySQL:4.1.10
Connector/J 3.1.6
ールすることとなんら変わりません（Maxバージョン
はMaxDBとは異なりますのでご注意ください）
．今回
は，http://dev.mysql.com/downloads/mysql/4.1.html
SQLノード
（MySQL）
SQLノード
（MySQL）
mysqld
mysqld
mysql
より，4.1.10 Maxバージョンのバイナリtar圧縮配布
版をダウンロードしてインストールします．Maxバー
ジョンでないと，NDBが含まれていませんのでご注意
Dataノード
Dataノード
ndbd
ndbd
ください．本稿の執筆時現在，4.1.10がMaxバージョ
MySQL
クライアント
ndb̲mgm
Managementノード
ndb̲mgmd
ンの最新版ですので，以降はこれを基に説明していき
ます．
MySQL
クライアント
Management
API
図10 本稿および次章でのディレクトリ構成
なお，本稿および次章での検証はSQLノード2つ，
DBノード2つ，Managementノード1つという環境で
/usr/loca/mysql
bin
行います．今回は，読者の皆さんが手軽に検証環境
を再現できるよう，一筐体で構築します（図9）．ま
data
た，ディレクトリ構成は図10の通りです．
data1
インストール
インストールした環境の説明を兼ね，ここでは今回
行ったインストール手順を簡単に説明します．インス
トール手順は，MySQLのリファレンスマニュ
アル（http://dev.mysql.com/doc/mysql/ja/
installing-binary.htm）に掲載されている方法
data2
ndb
mysqldや，ndb̲mgmdなど，各実行
モジュールが配置される
scripts/mysqld̲install̲dbファイルを実行
すると直下にあるmysqlデータベースに
ユーザテーブルなどが生成される
SQLノード(ノードID No.4)用のデータ
ディレクトリ
SQLノード(ノードID No.5)用のデータ
ディレクトリ
Managementノード(ノードID No.1)，
Dataノード(ノードID No.2，No.3)用
のデータディレクトリ
図11 グループとユーザの作成
shell> groupadd mysql
shell> useradd -d /home/mysql -g mysql mysql
とまったく同じですので，すでにご存知の方は図12 解凍とシンボリックリンクの作成
次節「複数mysqldの起動準備」から読み続け
てください．
shell> cd /usr/local
shell> tar -zxvf mysql-max-4.1.10.pc-linux-gnu-i686.tar.gz
shell> ln -s mysql-max-4.1.10.pc-linux-gnu-i686 mysql
JAVA PRESS Vol.42 ●
171
O/RマッピングからDBクラスタまで
図13 パスの設定（SUSEの場合）
図15 /usr/local/mysqlのファイル一覧
shell> export PATH=$PATH:/usr/local/mysql/bin
drwxr-xr-x 17 root mysql
drwxr-xr-x 16 root root
drwxr-xr-x 2 root mysql
drwxr-x--- 4 mysql mysql
drwxr-x--- 4 mysql mysql
drwxr-x--- 4 mysql mysql
drwxr-xr-x 4 mysql mysql
drwxr-xr-x 2 root mysql
図14 初期化スクリプトの起動
shell>
shell>
shell>
shell>
shell>
cd /usr/local/mysql
scrips/mysql_install_db --user=mysql
chown -R root .
chown -R mysql data
chgrp -R mysql .
688
640
2336
96
376
376
360
80
2005-02-22
2005-02-22
2005-02-13
2005-02-22
2005-02-23
2005-02-23
2005-03-16
2005-02-13
23:58
23:45
23:49
23:46
00:07
00:07
01:38
23:49
図16 データディレクトリの複製
図17 データディレクトリの権限の変更
shell> cp -rf /usr/local/mysql/data /usr/local/mysql/data1
shell> cp -rf /usr/local/mysql/data /usr/local/mysql/data2
shell> chown -R mysql data1 data2
図18 /usr/local/mysql/data1/my.1.cnfファイル
[mysqld]
ndbcluster
log
log-bin
datadir=/usr/local/mysql/data1
pid-file=/usr/local/mysql/data1/pid
socket=/usr/local/mysql/data1/mysql.sock
port=3306
./
../
bin/
data/
data1/
data2/
ndb/
scripts/
（図17）
．
次に，プロセスごとの起動設定ファイルを作成しま
す．通常，MySQLの設定ファイルはmy.cnfという名
前にします．デフォルトの起動では，まず，/etcの下
にmy.cnfという名前のファイルを探しに行き，/etcに
my.cnfがなければ，データディレクトリ（今回の設定
図19 /usr/local/mysql/data2/my.2.cnfファイル
では，/usr/local/mysql/data）に同じくmy.cnfとい
[mysqld]
ndbcluster
log
log-bin
datadir=/usr/local/mysql/data2
pid-file=/usr/local/mysql/data2/pid
socket=/usr/local/mysql/data2/mysql.sock
port=3307
う名前のファイルを探しに行きます．そして，ファイ
います．こうしておけば，その都度パスを設定する必
要がなくなります．
今回，同一筐体にて，MySQLデーモンを2つ起動
ルが見つかれば，そこに記載されている設定値を読
み，プロセスの起動に反映します．また，プロセス起
動時に設定ファイルの場所を --defaults̲file=<ファイ
ル名> で指定することによって，任意の起動ファイ
ルを指示することも可能です．
今回は，2つの設定ファイルを新規作成し，各ノー
ドのデータディレクトリに格納します．実際の起動時
させますので．各デーモン用に個別のデータディレク
には，プロセスごとに使用するファイルは変更します．
トリを作成します．まず，mysqlフォルダに移動し，
それぞれ，/usr/local/mysql/data1/my.1.cnf（図
初期化スクリプトを起動させます（図14）
．これによ
18）
，/usr/local/mysql/data2/my.2.cnf（図19）と
り，mysql，testデータベースがそれぞれ作成されま
なります．なお，これらに記載している通常ログとバ
す．
イナリログを出力するパラメータ， log と log-bin
これで，MySQLがインストールされました．図15
は，今回の検証環境用の設定です．実際の運用では，
に，/usr/local/mysqlのファイル一覧を掲載しまし
必要性を考慮した上で追加してください．また，data1
た．パーミッションや，所有者がこの図の通りになっ
のmy.1.cnfとdata2のmy.2.cnfはポート番号が異なる
ているか，確認してください．
ということを認識しておいてください．
複数mysqldの起動準備
ここからは，今回必要な構成を構築するための作業
に入ります．まず，インストール後，作成されたデー
ここまでで，通常のmysqldを起動する準備が整い
ました．次はいよいよ，MySQL Clusterの起動準備に
移ります．
まず，NDB用の設定ファイルの格納場所（図20）
タディレクトリを各プロセス用のデータディレクトリ
とconfig.iniファイルを新規作成します．/usr/local/
に複製します（図16）
．
mysql/ndb/config.iniは，図21の通りです．
それぞれのデータディレクトリの権限を変更します
172 ● JAVA PRESS Vol.42
ここで注意していただきたいことなのですが，セク
第3章●MySQLのクラスタリング（前編）
DBクラスタの基礎知識からMySQL Clusterの導入まで
図20 NDB用の設定ファイル格納場所の作成
図22 ndbディレクトリの権限の変更
shell> mkdir /usr/local/mysql/ndb
shell> chown - R mysql ndb/
図21 /usr/local/mysql/ndb/config.iniファイル
図23 ユーザの切り替えとディレクトリの移動
[NDBD DEFAULT]
NoOfReplicas=2
DataDir=/usr/local/mysql/ndb
HostName=localhost
[MYSQLD DEFAULT]
[NDB_MGMD DEFAULT]
[NDB_MGMD]
HostName=localhost
[NDBD]
[NDBD]
[MYSQLD]
[MYSQLD]
shell> su -l mysql
shell> cd /usr/local/mysql/ndb
図24 Managementノードの起動
shell> ndb_mgmd
図25 DBノードの起動（1つ目）
shell> ndbd --initial
図26 DBノードの起動（2つ目）
shell> ndbd
図27 SQLノードの起動
図28 NDBマネージメントコンソール
shell>
shell>
shell> ndb_mgm
ndb_mgm> show
mysqld --defaults-file=/usr/local/mysql/data1/my.1.cnf &
mysqld --defaults-file=/usr/local/mysql/data2/my.2.cnf &
ション（[ ]でくくられている部分）は起動するプロ
なる設定でmysqldを起動させるために， --defaults-
セスと対応しています．そのため最小構成の起動で
file=設定ファイル名
は，それぞれ必ず1つは必要です．なお，大文字小文
これによって，指定したファイルの設定内容で各プロ
字の区別はありません．
セスが起動します（図27）
．
最後に，ndbディレクトリの権限を変更します（図
22）
．これで，起動する準備が整いました．
というオプションをつけます．
起動を確認するためにNDBマネージメントコンソー
ルを開きます（図28）
．なお，マネージメントコンソ
ールに変更されていることを確認してください．
起動方法
図29のステータスが表示されたら起動が完了です．
mysqlユーザにユーザを切り替えたのち，config.ini
ファイルが格納されている/usr/local/mysql/ndb/デ
ィレクトリへ移動します（図23）
．
最初にManagementノードを起動します．ここで注
もし，その通りに表示されていない場合，行ってきた
作業をよく確認してください．
動作確認方法
意しなければいけないことは，必ずManagementノー
MySQL Clusterが実際に起動されているか，確認
ドから起動，次にDataノード，最後にSQLノードの
してみましょう（図30）．この確認方法では，2つの
順で起動するということです（図24）
．
端末を用意し，一方をNode id 4用，もう片方を Node
次にDBノードを起動していきます（図25）
．
id 5用と使い分けたほうがよいでしょう．まず，Node
2つ目のDBノードを起動する場合は，--initialオプ
id 4のmysqldにmysqlクライアントから接続し，クエ
リを実行します．作業はすべて，mysqlユーザで行っ
ションは不要です（図26）
．
初期化パラメータ --initial
は初回に起動すると
き，config.iniファイルを書き換えた後，およびバック
アップ／リストア後に必要です．--initialパラメ
ータは以前に作成されてログファイルなどを初
期化します．
最後に，SQLノード（mysqld）を起動しま
す．mysqld̲multiや，mysqld̲safeを用いて起
動する方法もありますが，今回は簡略化のため
直接mysqldを起動します．プロセスごとに異
ていることに注意してください．
テーブルが正しく作成されているか，確認してみま
図29 起動完了の表示
[ndbd(NDB)]
2 node(s)
id=2
@127.0.0.1 (Version: 4.1.10, Nodegroup: 0, Master)
id=3
@127.0.0.1 (Version: 4.1.10, Nodegroup: 0)
[ndb_mgmd(MGM)] 1 node(s)
id=1
@127.0.0.1 (Version: 4.1.10)
[mysqld(API)]
2 node(s)
id=4
@127.0.0.1 (Version: 4.1.10)
id=5
@127.0.0.1 (Version: 4.1.10)
JAVA PRESS Vol.42 ●
173
O/RマッピングからDBクラスタまで
図30 起動の確認
クライアントから接続し，クエリを流してみます（図
shell> mysql --host=127.0.0.1 --port=3306
mysql> USE test;
mysql> CREATE TABLE t1 (col1 INT);
33）
．接続先のポート番号が変更されていることに注
図31 テーブルの確認
意してください．
テーブルが存在していないことを確認しました．
MyISAMで作成したので，データベースの情報が複製
mysql> SHOW CREATE TABLE t1;
| t1
| CREATE TABLE `t1` (
`col1` int(11) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1 |
されていないためです．
図32 値の確認
ライアントから，t1のエンジンをNDBに変更してみま
mysql> INSERT INTO t1 () values (1);
mysql> SELECT * FROM t1;
+------+
| col1 |
+------+
|
1 |
+------+
1 row in set (0.00 sec)
次に，Node id 4のmysqldに接続しているmysqlク
しょう（図34）
．
これで，NDBに変更されました．ストレージエン
ジンが正しく変更されたか，実際に確認してみましょ
う（図35）
．ENGINE=NDBCLUSTERとなっている
ことを確認します．
図33 接続先を変えてテーブルの確認
shell> mysql --host=127.0.0.1 --port=3307
mysql> SHOW TABLES;
Empty set (0.00 sec)
図34 ストレージエンジンの変更
もう一度，Node id 5に接続したmysqlクライアン
トから，先ほど流したクエリを実行します（図36）．
今度は正しくテーブルが存在しています．念のため検
索できるか試してみましょう（図37）
．値も正しく表
mysql> ALTER TABLE t1 ENGINE=ndbcluster;
Query OK, 1 row affected (1.21 sec)
Records: 1 Duplicates: 0 Warnings: 0
示されていますね．
図35 変更の確認
のテーブルがNDBエンジンに変更されることによっ
mysql> SHOW CREATE TABLE t1;
| t1
| CREATE TABLE `t1` (
`col1` int(11) default NULL
) ENGINE=ndbcluster DEFAULT CHARSET=latin1 |
て，もう片方のノードにも反映されることが確認でき
図36 テーブルの確認
mysql> SHOW TABLES;
+----------------+
| Tables_in_test |
+----------------+
| t1
|
+----------------+
1 row in set (0.03 sec)
ここまでで，片方のノードで作成したMyISAM型
ました．
以上でMySQL Clusterの設定は完了です．
シャットダウン方法
現時点では，SQLノード(mysqld）以外はマネージ
メントコンソールから <ノードID> stop
でそれぞ
れのノードがシャットダウン可能です．たとえば，
図37 値の確認
mysql> SELECT * FROM t1;
+------+
| col1 |
+------+
|
1 |
+------+
1 row in set (0.00 sec)
ndb_mdm> 2 stop
で，Node id 2 のDataノードがシャットダウンされま
す．
ただし，すべてのData ノードの停止はMySQL
しょう（図31）
．ENGINE=MyISAMとなっているこ
Clusterの停止を意味するのでstopコマンドでは全ノー
とに注意してください．MySQLはデフォルト設定で
ドを停止できません．SQLノード以外すべてをシャッ
は，MyISAMがデフォルトエンジンとして使用されて
トダウンさせたいときは，
います．この段階では，MyISAMが作成されているこ
とで正解です．次に値を実際に挿入してみましょう
（図32）
．値も確認できました．
さて，次に，もう1つのNode id 5のmysqldにmysql
174 ● JAVA PRESS Vol.42
ndb_mdm > SHUTDOWN
を使用してください．
SQLノードは，個別にシャットダウンさせる必要が
第3章●MySQLのクラスタリング（前編）
DBクラスタの基礎知識からMySQL Clusterの導入まで
図38 SQLノードのシャットダウン
shell>
shell>
mysqladmin -uroot --port=3306 -h 127.0.0.1 shutdown
mysqladmin -uroot --port=3307 -h 127.0.0.1 shutdown
ありますので，図38の手順で行います．
これで，すべてのMySQL Clusterのノードが停止し
ます．再度起動する場合は，
「起動方法」の手順をも
次章では，Connector/Jのクラスタリング機能と，
MySQL Clusterと合わせて利用する場合の考慮点など
を実際のJavaプログラムを通して見ていきます．J
う一度行ってください．
¡MySQL Cluster製品ページ（英語）
まとめ
http://www.mysql.com/products/cluster/
¡MySQLリファレンスマニュアル16章 MySQL Cluster
以上で，MySQL Clusterのしくみと起動方法をマ
（英語）
スターしました．ぜひ実際にダウンロードして動作を
http://dev.mysql.com/doc/mysql/en/ndbcluster.html
確認してください．
※日本語版のリファレンスマニュアルは古く，
先日実施したMySQL Clusterチームとのミーティン
グで開発者の一人 Martin Skold氏曰く， MySQL
Clusterはすでにさまざまな分野で利用されています．
MySQL Clusterの項目がありません．設定方法
や各種パラメータの詳細など参考になります．
¡MySQLメーリングリスト，MySQL Cluster（英語）
フランスの銀行では株式取引に，通信会社アルカテル
http://lists.mysql.com/cluster
社では位置情報管理に，エリクソンではテレコムアプ
※特にMySQL Cluster開発者の投稿は参考になり
リケーションにそれぞれ活用されています．飛行機チ
ケットやホテルなどの予約サイトswiss.comではJBoss
とMySQL Clusterの組み合わせを2台のサーバで運用
ます．
¡MySQL Forums，Cluster（英語）
http://forums.mysql.com/list.php?25
しています．今後も適用事例は増えていくでしょう．
設定や構成についてさらに調べる場合は，次のサイ
トが参考になります．
MySQL Clusterチームより
写真 MySQL Clusterチームのメンバ
写真はMySQL Cluster チームです．左よりMikael
Ronstrom，Vinay Joosery，Johan Andersson，
Tomas Ulin，Jonas Orelandです．MySQL Cluster
製品マネージャであるVinay Joosery氏（vinay@mysql.
com）のメッセージを以下に紹介します．
「すでに多くの顧客が，MySQL を大規模システム利用し
ています．数千の同時トランザクションが発生し，高い可
用性とスケーラビリティが要求されるシステムです．既存
のMySQL のストレージエンジンに代わってMySQL
Cluster を選択すれば，最も高い要求を満たすと同時に，
TCO は圧倒的に下がります．ぜひこの記事を参考にして
MySQL Cluster を使ってみてください．」
JAVA PRESS Vol.42 ●
175

Download Report