Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 27.1Mb
PDF (A4) - 27.2Mb
HTML Download (TGZ) - 7.2Mb
HTML Download (Zip) - 7.2Mb


MySQL 5.6 リファレンスマニュアル  /  ...  /  MySQL Cluster のハードウェア、ソフトウェア、およびネットワーク要件

18.1.3 MySQL Cluster のハードウェア、ソフトウェア、およびネットワーク要件

MySQL Cluster の長所の 1 つは、汎用のハードウェアで実行できるため、すべてのライブデータをメモリーに格納するために大量の RAM を必要とする以外は、ハードウェアに関して特別な要件がないことです。(ディスクデータテーブルを使用してこの要件を削減することもできます。詳細は、セクション18.5.12「MySQL Cluster ディスクデータテーブル」を参照してください。)当然ながら、複数の高速な CPU を使用すればパフォーマンスは向上します。ほかの MySQL Cluster プロセスのメモリー要件は、比較的少量です。

MySQL Cluster のソフトウェア要件も小規模です。ホストのオペレーティングシステムに、MySQL Cluster をサポートするための特別なモジュール、サービス、アプリケーション、または構成は必要ありません。サポートされるオペレーティングシステムについては、標準のインストールで十分のはずです。MySQL のソフトウェア要件は単純です。必要なものは MySQL Cluster の本番リリースだけです。MySQL Cluster を使用できるようにするだけなら、必ずしも MySQL をユーザー自身でコンパイルする必要はありません。ここでは、ユーザーが MySQL Cluster ソフトウェアダウンロードページ (http://dev.mysql.com/downloads/cluster/) から入手できる各自のプラットフォームに適したバイナリを使用していると仮定します。

ノード間の通信については、MySQL Cluster は標準的なトポロジの TCP/IP ネットワークをサポートします。各ホストには、標準の 100M ビット/秒 Ethernet カードが最低限必要です。さらに、クラスタ全体のネットワーク接続を提供するためにスイッチ、ハブ、またはルーターが必要です。次の理由で、クラスタの構成要素でないマシンと共有しない独立したサブネットで MySQL Cluster を実行することをお勧めします。

  • セキュリティー  MySQL Cluster ノード間の通信では、暗号化や保護がまったく行われません。MySQL Cluster 内の伝送を保護する唯一の手段は、MySQL Cluster を保護されたネットワークで実行することです。MySQL Cluster を Web アプリケーションのために使用する場合は、クラスタをネットワークの非武装地帯 (DMZ) などに配置せず、ファイアウォールの背後に間違いなく配置するようにしてください。

    詳細は、セクション18.5.11.1「MySQL Cluster のセキュリティーとネットワーク上の問題」を参照してください。

  • 効率  MySQL Cluster をプライベートネットワークや保護されたネットワークにセットアップすると、クラスタはクラスタホスト間の帯域幅を独占的に使用できます。MySQL Cluster 用に別個のスイッチを使用すると、MySQL Cluster データを不正アクセスから保護できるだけでなく、ネットワーク上のほかのコンピュータ間の伝送によって発生する障害から MySQL Cluster ノードを確実に保護できます。信頼性を高めるため、デュアルスイッチとデュアルカードを使用して、単一障害点になったネットワークを除去できます。多くのデバイスドライバがこのような通信リンクのフェイルオーバーをサポートしています。

ネットワーク通信と待機時間  MySQL Cluster では、データノードと API ノード (SQL ノードを含む) 間、およびデータノードと別のデータノード間でクエリーや更新を実行するために通信を行う必要があります。これらのプロセス間通信の待機時間は、ユーザークエリーの観測されるパフォーマンスと待機時間に直接影響を与える可能性があります。さらに、ノードのサイレント障害が発生した場合でも一貫性とサービスを維持するため、MySQL Cluster では長時間にわたるノードからの通信の喪失をノード障害として扱うハートビートとタイムアウトのメカニズムが使用されます。これは、冗長性の低下につながる可能性があります。ノードグループ内の最後のノードに障害が発生すると、MySQL Cluster はデータの一貫性を維持するためにシャットダウンすることを思い出してください。したがって、強制的なシャットダウンのリスクを増やさないようにするため、ノード間通信の中断はできるかぎり回避すべきです。

データノードまたは API ノードに障害が発生すると、障害が発生したノードに関係するコミットされていないすべてのトランザクションが中止されます。データノードをリカバリするには、データノードのサービスを再開する前に、障害が発生したノードのデータを残存するデータノードのデータと同期し、ディスクベースの redo ログとチェックポイントログを再構築する必要があります。このリカバリには時間がかかる場合があり、その間、クラスタは冗長性が低下した状態で動作します。

ハートビートは、すべてのノードでハートビート信号が遅延なく生成されるかどうかに依存しています。ノードに過大な負荷がかかったり、マシンの CPU がほかのプログラムと共有されるために不十分だったり、スワッピングによる遅延が発生したりすると、これは不可能になります。ハートビート生成の遅延が十分に大きくなると、ほかのノードは応答が遅いノードを障害発生ノードとして扱います。

このように遅いノードを障害発生ノードとして扱うことは、ノードの遅い動作がクラスタの残りの部分にどの程度影響するかによって、望ましい場合とそうでない場合があります。MySQL Cluster の HeartbeatIntervalDbDbHeartbeatIntervalDbApi などのタイムアウト値を設定するときは、高コストの可能性がある誤判定を回避しながら、迅速な検出、フェイルオーバー、サービス再開が実現されるように配慮する必要があります。

データノード間の通信待機時間が LAN 環境での予想値 (およそ 100 マイクロ秒) より大きくなると予想される場合は、タイムアウトのパラメータを増やして、許容する待機時間が構成したタイムアウトの範囲に十分に収まるようにする必要があります。このようにタイムアウトを増やすと、最大の障害検出時間および (その結果としての) サービスリカバリ時間にも類似の効果があります。

LAN 環境は、通常、安定した小さい待機時間で構成できるため、高速フェイルオーバーによる冗長性を提供できます。個々のリンク障害は、TCP レベルで認識できる最小限の制御された (MySQL Cluster が正常に動作する) 待機時間でリカバリできます。WAN 環境では、待機時間に幅があり、冗長性についてもフェイルオーバーに時間がかかる可能性があります。個々のリンク障害では、エンドツーエンドの接続をリストアする前に、ルート変更を伝播する必要があります。これは、TCP レベルでは個々のチャネルの大きな待機時間として現れます。これらのシナリオで最悪の場合に観測される TCP 待機時間は、IP 層で障害を回避するために行われる再ルーティングの最大時間に関連しています。

SCI のサポート  MySQL Cluster に高速なスケーラブルコヒーラントインタフェース (SCI) を使用することもできますが、これは必要条件ではありません。このプロトコルおよび MySQL Cluster での使用方法の詳細は、セクション18.3.5「MySQL Cluster での高速インターコネクトの使用」を参照してください。


User Comments
Sign Up Login You must be logged in to post a comment.