ローリングリスタート！
MySQL 5.1の新機能総まとめ
今回は、まずMySQL 5.1の最新機能についてまとめて紹介しましょう。
「パーティショニング」は、巨大なテーブルを分割することで、参照・更新の性能を向上するテクニックです。特にデータウェアハウスなど、巨大なテーブルが必要な場面で役立つでしょう。パーティションの分け方には4つの種類があり、用途に応じて使い分けることができます。それぞれ、Rangeパーティショニング、Listパーティショニング、Hashパーティショニング、Keyパーティショニングです。今後、扱うべきデータがますます大きくなることが予想されます。ぜひパーティショニングを活用しましょう。
「行ベースレプリケーション（RBR）」では、これまでのステートメントベースレプリケーション（SBR）に加えて利用できる機能です。SBRでは複製するのが不可能だったUUID()などの関数も複製ができるようになりました。RBRはSBRよりも性能面で劣るので、SBRでは対処できないステートメントの場合だけ自動的にRBRに切り替わるMixedモードが利用できます。指定がない場合、Mixedモードがデフォルトです。
「イベントスケジューラ」は定期的なジョブ、またはワンタイムのジョブを実行するための機能です。週末にOPTIMIZE TABLEを実行する場合や、月次のレポートを作成する場合などの用途で利用してください。イベントスケジューラはcronなどとは違い、プラットホーム非依存です。mysqldumpユーティリティーを使うことでバックアップも可能です。
またMySQL 5.1では、一般クエリログとスロークエリログをテーブルとして保存・参照できるようになりました。テーブルへログを格納しておくことで、SQL文を使ってログの解析ができるようになったため、解析が効率的に行えます。
図1に今後のバージョンで追加される予定の機能をリストアップします。ただし予定は変更される可能性がありますのでご了承ください。
MySQL Cluster 6.2
連載の2回目以降はMySQL Cluster 6.2のセットアップについて説明しました。MySQL Clusterでは管理ノード、データノード、SQLノードの3種類のノードがあります。
今回はconfig.iniのパラメータ（DataMemory、IndexMemoryなど）を変更したときにその内容を反映するための手順である「ローリングリスタート」について説明します。ローリングリスタートとは簡単にいうと、各ノードを順に再起動していくことです。
config.iniを変更したら、まず管理ノードを再起動します。再起動するには、ndb_mgmコンソールにおいて「ノードID RESTART」を実行します。以下は管理ノードのIDが1の場合の手順です。
ndb_mgm> 1 RESTART
ノードが再起動するため、ndb_mgmはいったん接続が切れてしまいますが、しばらくすると自動的に接続を再開します。管理ノードが正常に起動したことを確認するために、SHOWコマンドでステータスを確認してください。次に、データノードを順に再起動します。もし、/etc/my.cnfにおいてconnect-stringの設定がしてあれば、管理ノードと同様にRESTARTコマンドが使用できます。1つ目のデータノードのノードIDが41の場合、ndb_mgmコンソールにおいて以下のように実行します。
ndb_mgm> 41 RESTART
データノードの再起動にはしばらく時間がかかります。STATUSコマンドを実行して、startedとなるまで待ちましょう。起動が完了するとコンソールに通知メッセージが表示されます。
ndb_mgm> 41 STATUS
同様の手順をすべてのデータノードについて繰り返します。
REDOログの設定を変更した場合など、ファイルシステムを初期化する必要がある場合には、イニシャルリスタートという手順が必要になります。イニシャルリスタートが必要かどうかについては、変更するパラメータによります。イニシャルリスタートが必要になるパラメータについては、マニュアル（http://dev.mysql.com/doc/refman/5.1/ja/mysql-cluster-config-params-overview.html）を参照してください。イニシャルリスタートをする場合には、以下のように-iオプションを使用します。
ndb_mgm> 41 RESTART -i
起動が完了したことをndb_mgmコンソールより確認します。
SQLノードはconfig.iniを変更してもほとんどの場合再起動する必要はありません。再起動の必要があるのは管理ノードに変更を加えた場合、例えば管理ノードを多重化したときなどです。その場合、connect-stringを適宜変更してから、通常の手順で再起動を行いましょう（複数の管理ノードがある場合の説明については割愛します）。
shell> mysqladmin -uroot -p shutdown
shell> mysqld_safe &
クラスタへの接続が確立できているかどうかの確認は、SHOW ENGINE NDB STATUSコマンドで行います。
shell> mysql -uroot -p
mysql> SHOW ENGINE NDB STATUS¥G
最終的なステータス確認は、管理ノードからSHOWコマンドを実行します。次は、データノードとSQLノードの共存について説明します。
データノードとSQLノードの共存
本連載ではお手軽にMySQL Clusterを試してもらうために、Solarisゾーンを用いてセットアップを行いましたが、現実的にはそのように同じマシン上で複数のノードを動かすことはあまりありません。データノード同士でメモリを取り合うことになるので、同じマシンで複数のデータノードを動かすことはお勧めできません。
性能を重視しない場合、データノードとSQLノードを同じマシン上で動かすことはまれにあります。そのような場合の注意点は、データノードとSQLノードでリソースを取り合わないようにすることです。
特に、SQLノードは負荷に応じてメモリ使用量が増減するため、高負荷時にはCPUをすべて消費してしまいます。Solarisの場合にはリソース管理をしっかり行うことで、そのようなリソースの取り合いを防ぐことが可能です。次の点に注意してリソースを設定しましょう。
・データノードには1つまたは2つの専用CPUコアを割り当てる。
・データノードの設定においてLockPagesInMainMemory=1を使用する。
・SQLノードが利用できるメモリ量の上限を設定する。上限は少し余裕を持たせておく。
このように設定すると、図2のように物理的なマシンが4台でデータノード4つ、SQLノード4つというシステムを構成することができます。管理ノードは別のマシンに設定する必要があります。
Solarisにおいて、上記のようなリソース管理を行う方法については、Solaris Containerの解説ページ（http://jp.sun.com/products/software/solaris/10/containersLowRes.html）で詳しく説明されているので参照してください。
MySQL Clusterの制限事項
ここではMySQL Clusterを利用する上で特に注意しなければならい制限事項について説明します。
MySQL Clusterには2種類のインデックスがあります。ハッシュインデックスとオーダードインデックスです。オーダードインデックスは1つのテーブルにおいて複数作成することができますが、ハッシュインデックスはテーブルにつき1つだけしか作成できません。
つまり、ハッシュインデックスとして構成されるのは主キーのみです。一方で、UNIQUEキー制約を利用する場合にはハッシュインデックスが必要です。そのため、MySQL ClusterではUNIQUEキーを定義した場合、内部的にサポートテーブルという別のテーブルが作成されることになります。サポートテーブルの分だけテーブルに対する参照が増えるため、UNIQUEキー制約を利用キーは性能がよくありません。
データノードとSQLノードにおいて、異なる性能や種類のマシンを使うことが可能ですが、その際いくつか制限事項があります。
まずエンディアンの異なるシステムは混在できません。例えばx86はリトルエンディアンで、SPARCはビッグエンディアンですが、この2種類のアーキテクチャを同一のMySQL Clusterにおいて混在させることはできません。
また、データノードはすべて同じ容量／性能でなければなりません。データ量や負荷はハッシュにより均等に分散されるため、もし性能の異なるシステムを利用した場合、もっとも性能の低いマシンがボトルネックになります。
トランザクションについても「第4回：データノード設定時のポイント！（http://www.thinkit.co.jp/article/95/4/）」で説明した制限事項（MySQL Clusterで利用できる分離レベルはREAD COMMITTEDのみで、トランザクションの途中でエラーが発生すると、内部的にトランザクションがロールバックしてしまう）があります。
なお、最大の行サイズは8KB（MySQLのハードリミットは64KB）までなので、カラム数の多いテーブルを用いる場合には注意しましょう。BLOBやTEXTを用いた場合、データはほかの領域へ格納されるためのこの制限の限りではありませんが、先頭の255バイトは同じ8KBの領域に格納されるため、考慮する必要があります。
MySQL Clusterではデータノードの数を動的に変更することはできません。データノードを追加するときには、データをバックアップしてからリストアする必要があります。データ容量や処理能力を向上させたい場合には、稼働するハードウエアを増強して、メモリ容量や処理能力を向上させるほうが簡単です。
MySQL Clusterが扱えるデータノードの数は、最大で48、管理ノード、SQLノードを含めた合計は255です。そこまで大規模なクラスタを使う機会はそれほどないため、この制限はそれほど問題にはならないでしょう。
MySQL Clusterのノード同士が通信する際、その内容は暗号化されません。また、管理ノードやデータノードへアクセスする際に認証はありません。MySQL Clusterを構築する際には、物理的に独立したネットワークを使いましょう。各ノードではOSレベルでセキュリティーを確保しましょう。
バージョンアップとデータ移行
MySQL Clusterは、同じメジャーバージョンのもの（例えば6.2.x）においては、ローリングリスタートを使うことによってクラスタを停止することなくソフトウェアをアップグレードすることが可能です。
これにより、メンテナンスによるダウンタイムを大幅に短縮することが可能です。このようなアップグレード方法はローリングアップグレードと呼ばれています。手順は1ページ目で説明したものとほぼ同じです。異なる点は、各ノードを停止している間にバイナリを更新するということだけです。
ただし、いくつかのバージョンではシステムテーブルの互換性などが原因で、クラスタ全体をシャットダウンしなければならないケースもあります。ローリングアップグレードが可能かどうかについては、バージョンの互換性のリストがマニュアル（http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-upgrade-downgrade-compatibility.html）に載っているので参考にしてください。
ローリングアップグレードが可能でない場合には、データをすべてバックアップし、いったんファイルを初期化してからリストアするという手順が必要になります。この場合はかなりのメンテナンス時間が必要です。データのバックアップには、MySQL Clusterのオンラインバックアップまたはmysqldumpコマンドのいずれかを用いて行うことが可能ですが、実行時間が短くて済むのはオンラインバックアップです。
オンラインバックアップとリストアの手順
ここでは、オンラインバックアップとリストアの手順について説明します。
バックアップは任意のタイミングで取得することが可能です。データ移行時などにはアプリケーションとSQLノードを停止し、更新がない状態にしてからバックアップをとるといいでしょう。バックアップをとるには、ndb_mgmクライアントにおいて以下のコマンドを実行します。
ndb_mgm> START BACKUP
すると各データノードにおいてバックアップが作成されます。バックアップを開始する度に、バックアップにはそれぞれ整数のIDが与えられます。このIDはバックアップを格納するディレクトリ名や、バックアップファイル名に使用されます。例えば、バックアップIDが123で、FileSystemPathが/var/lib/mysql-clusterで、BackupDataDirの指定がない場合、/var/lib/mysql-cluster/BACKUP/BACKUP-123というディレクトリにバックアップが作成されます。バックアップが完了したかどうかは、以下のコマンドで確認することができます。
ndb_mgm> ALL REPORT BackupStatus
ここで取得したバックアップを用いてリストアを行うには、データノードをすべて空の状態にする必要があります。データノードをすべて空の状態にするには、以下のいずれかの手順を実施するといいでしょう。
・クラスタをシャットダウン（ndb_mgmよりSHUTDOWNコマンドを実行）し、すべてのテーブルスペースとログファイルを消去してから、--initialオプションをつけてndbdを起動する。
・クラスタをシャットダウンし、DataDirまたはFileSystemPath配下のファイル、テーブルスペースとログファイルを消去してから、ndbdを起動する。
リストアを行うには、ndb_restoreコマンドを使用します。ndb_restoreコマンドはSQLノードの一種として動作するため、ndb_resotreコマンドのための[mysqld]セクションをconfig.iniに追加します。空の[mysqld]セクションを指定すると、任意のホストからクラスタへ接続することが可能となります。データノードと同じホストでndb_restoreコマンドを実行する場合には、空の[mysqld]セクションを使用するといいでしょう。
データノードが4つあり、各ノードIDが41～44で、バックアップIDが123であるとします。各データノードが作成したバックアップファイルをそれぞれリストアします。まず、ノード41でリストアを行う場合、ndb_restoreコマンドのオプションは以下のようになります。
shell> ndb_restore -c 192.168.1.40 -b 123 -n 41 -m -r /var/lib/mysql-cluster/BACKUP/BACKUP-123
-bはバックアップIDで、-nはバックアップファイルを取得したデータノードのノードIDです。このコマンドを、各データノード上で繰り返します。最初だけ-mオプションが必要ですが、ほかのノードにおいて、例えばノード42では次のように実行します。
shell> ndb_restore -c 192.168.1.40 -b 123 -n 42 -r /var/lib/mysql-cluster/BACKUP/BACKUP-123
残りのデータノードにおいても-mなしでリストアを行いましょう。
実際の運用においては、バックアップファイルを専用のバックアップ用ホストに集約するといいでしょう。
なお、サン・マイクロシステムズでは、MySQLサーバー製品群のサポートサービスを有償で行っています。価格やサポートの内容についてはMySQL Enterprise（http://www-jp.mysql.com/products/enterprise/features.html）、MySQL Clusterサポート（http://www-jp.mysql.com/products/database/cluster/support.html）を確認してください。
