MySQL Clusterを試す！第4回

MySQL Cluster 最大のボトルネック

　MySQL Clusterを構成する上で最も気をつけなければいけないボトルネックは、実はネットワークです。ノード間で転送するデータ量が多いため、ネットワークに十分な帯域がないとパフォーマンスが劣化する原因になります。そのため、ギガビットイーサ以上のインターフェースを使用するのはもちろん、スループットが高いスイッチを利用しましょう。また、セキュリティーの観点からも性能の観点からも、MySQL Clusterはほかのネットワークにはつながっていない専用のネットワークを構成しましょう。

　MySQL Clusterには複数のネットワークインターフェースを使ったり、ネットワークカードの故障時にフェイルオーバーするための機能はありませんので、ネットワークの多重化を行う場合にはOSの機能を利用する必要があります。SolarisではIPMP（IPマルチパス）機能を使うといいでしょう。ネットワークスイッチも多重化しておきましょう。

　データノード間で専用のインターコネクト用ネットワークを用いる場合には、config.iniにおいて[tcp]セクションを利用します。データノードの組み合わせごとに、ノード間通信で使用するIPアドレスを指定する必要があります。[tcp]セクションの記述方法についてはマニュアルを参照してください。

アプリケーション側での対応

　MySQL Clusterを使うにあたり、アプリケーション側で気をつけるべき点について説明します。

　NDBストレージエンジンがサポートする分離レベルはREAD COMMITTEDのみです（ファントムを防ぐことはできません。）。READ COMMITTEDであることを考慮してロジックを実装する必要があります。

　InnoDBストレージエンジンとは違い、NDBストレージエンジンではステートメントがエラーになるとトランザクションが内部的にロールバックします。次にSQL文を実行するためには、いったん明示的にROLLBACKコマンドを実行しなければなりません。ROLLBACKコマンドを実行しない場合、以降のSQL文はすべてエラー（1296）になります。そのため、トランザクションを最初からやり直す必要が生じます。

　また、トランザクション中にデータノードにおいて障害が発生すると、処理中のトランザクションはいったんロールバックします。InnoDBストレージエンジンやほかのRDBMSでも言えることですが、リトライ処理をしっかりと実装しておきましょう。

　MySQL Clusterではタイムアウト値が厳しく設定されているため、高負荷時などにはロックの取得に時間がかかりタイムアウトが発生する場合があります。タイムアウトの発生を最小限に抑えるためには、トランザクションをできるだけ小さい単位で行うようにしましょう。また、どうしても処理が間に合わない場合にはタイムアウト値（TransactionDeadlockDetectionTimeout）を大きくしましょう。

　MySQL Clusterはリアルタイム性が必要なOLTPに特化したストレージエンジンです。バッチ処理はあまり得意ではありません。用途に合わせてほかのストレージエンジンも併用するといいでしょう。