MySQL Clusterを使ってみた

このエントリーをはてなブックマークに追加

2013/04/07(日)

環境
■管理ノード/データノード/SQLノード×1
・CentOS 6.4
・Intel(R) Xeon CPU 2.90GHz
・メモリ2GB
■データノード/SQLノード×1
・CentOS 6.4
・Intel(R) Xeon CPU 2.90GHz
・メモリ2GB

MySQL Clusterの検証をする機会があったのでメモ。

 

通常のMySQLサーバを運用する場合、Masterサーバ×1+Slaveサーバ×nな構成とし、Master→Slaveへレプリケーションを行いつつ、更新系のクエリはMasterに投げ、参照はSlaveサーバのいずれかへ行うことで負荷分散を行っていると思います。

 

しかしこの構成の場合、ソーシャルゲームのような更新系のクエリが多数投げられるシステムではMasterサーバの負荷が問題になる場合があります。

 

そこで今回使ったMySQL Clusterを使うとマルチマスター構成を実現することが可能となります。
どちらのサーバにINSERT/UPDATEを投げてもデータの整合性が損なわれる事なくHA構成なシステムを組めるわけです。

今回のシステム構成

今回以下の図のような2台構成でテストしました。
mysql_cluster

本来高可用性の要件を満たすにはホストが3台必要とのことですが(MySQL Cluster構築・運用バイブル)、サーバを用意する都合上この構成となりました。

インストール以前に

RPMパッケージが用意されているのでこれを使ってインストールすることにしました。
ダウンロードはdev.mysql.comのダウンロードページからどうぞ。
 

が、ここでとても悩みました。
 
RPMパッケージのラインナップが7.1とちょっと変わっているような気が…
前述の「MySQL Cluster構築・運用バイブル」に各ノードに必要なRPMパッケージが細かく書いてあったんですがこれは7.1系ベースで書かれているようでダウンロードページの名称と一致しませんでした。
結局1h以上考えてしまいました。

管理ノードのセットアップ


 

データノード・SQLノードのセットアップ

今回は管理ノード兼データノード兼SQLノードが1台あるので、使用する全てのマシンで実行しました。

起動


 

エラーが出た場合の対処

データをimportしようとすると以下のようなエラーが出ました。

使ってみての感想

起動・再起動手順がちょっと煩雑かも…

管理ノード起動→データノード起動→SQLノード起動というような儀式を経る必要がある。
停止の時は逆に
SQLノード停止→データノード停止→管理ノード停止

通常のMySQLよりパラメータの設定がシビア

普段使っている通常のMySQLサーバだとmy.cnfの設定がいい加減でも動かないということはないと思います。
ですがMySQL Clusterでは事前にデータから設定値を見積もっておかないとレプリケーションに失敗したりするリスクがあると思いました。

テーブル設計がいい加減なシステムでは導入できなそう

DB内でindexの数が多かったりtext型のカラムを多用していたりするとNoOfFragmentLogFilesを増やすかTimeBetweenLocalCheckpointsの値を減らせってすぐ言われる。

CREATE TABLEする時のENGINE指定がndbclusterとなる

一括置換できるレベルですが地味にハマりました。
InnoDBなどを使っているMySQLサーバからDDLを作成してもそのままでは使えません。
 
importを実行したノードではimportできるんですが、他のノードに同期されない!エラーも特に出ません。
ENGINE=InnoDBやENGINE=MyISAMとなっている部分をENGINE=ndbclusterと変換してやる必要があります。
 
ENGINE=ndbclusterのテーブルのみ同期して、InnoDBやMyISAMのテーブルは同期しないけど一応使えるよっていう設計思想っぽい…
 
関連してMySQLの権限テーブルがMyISAMのためデフォルトでは同期されず、個々のSQLノードで実行する必要があります。
上の手順に書いてあるようにストアドプロシージャを実行してndbclusterエンジンを使うようにすれば権限テーブルも同期されるようになります。

JOINが遅いらしい

分散型システムということでJOINが遅いという情報を事前に聞いていて気になっていましたが、手元でMySQL5.5と比較した限りでは感じませんでした。
MySQL Cluster7.2からさらに高速化しているとのことですが今回使った7.1でも通常のMySQLより高速な場合もありました。

最後に

Webアプリで気軽に使うっていう感じではなさそう。
少なくともインフラ専任がいないプロジェクトで使うと運用で死ぬ気がします。
 
MySQLの垂直分割(テーブルを物理的に別のサーバに分ける)や水平分割(Sharding:最近あんまり使わないか?)、さらにはioDriveとか使ってどうにもならない場合には検討する価値があるかも。
 
おしまい。
 

関連記事

コメント一覧

コメントはまだありません

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

スパム防止のため下の計算結果を入力して下さい *

トラックバック一覧

トラックバックURL:

ページの先頭へ