Skip navigation links
14.7.2 マネジメント クライアントのコマンド »
Section Navigation      [Toggle]

14.7.1. MySQL Cluster 起動フェーズ

この項ではクラスタが起動したときのステップを説明します。

以下に示すようにいくつかの異なる起動タイプおよびモードがあります。

  • 最初の起動:クラスタはすべてのデータ ノードの未使用のファイルシステムで起動します。これはクラスタがまさに一番最初の起動時に発生する、あるいは --initial オプションで再起動したときに発生します。

    注:ディスク データ ファイルはノードを --initial で再起動したときには削除されません。

  • システムの再起動:クラスタが起動しデータ ノードに保存されたデータを読み込みます。これはクラスタが使用された後にシャットダウンされ場合、クラスタが離れたところからオペレーションを再開する再に発生します。

  • ノードの再起動:これはクラスタそのものが稼動しているときのクラスタ ノードのオンラインの再起動です。

  • 最初のノードの再起動:これはノード再初期化され未使用のファイルシステム起動されたときを除いて、ノードの再起動と同じです。

起動に先立ち、すべてのデータ ノード (ndbd プロセス) は初期化する必要があります。初期化には以下のステップが含まれます。

  1. ノード ID の取得。

  2. 設定データの取り出し。

  3. インターノード通信のポートの割り当て。

  4. 設定ファイルから取得した設定に基づいたメモリの割り当て。

データ ノードあるいは SQL ノードが最初にマネジメント ノードに接続すると、クラスタ ノード ID を予約します。他のノードが同じノード ID を割り当てていないか確認するために、この ID はノードがクラスタおよびノードが接続された少なくとも 1 つの ndbd レポートに接続されるまで維持されます。このノード ID の維持は問題のノードおよび ndb_mgmd 間の接続によって保護されます。

通常、ノードに問題が発生した場合、ノードの接続がマネジメント サーバーから切断され、その接続に使用されているソケットが閉じて、予約されたノード ID の予約が開放されます。しかし、ノードの接続が突然切断された場合— 例えば、クラスタのホストの 1 つのハードウェアの問題、あるいはネットワークの問題で切断されると、— オペレーティング システムによるソケットの通常の閉鎖が行われなくなります。この場合、そのノード ID は予約されたままで、TCP のタイムアウトが 10 分あるいはそれ以降には起こるまで開放されません。

この問題を対処するために PURGE STALE SESSIONS を使用できます。このステートメントを実行するとすべての予約したノード ID をチェックします。そして、実際に接続されていてノードによって使用されていないノード ID の予約が外されます。

MySQL 5.1.11 以降では、ノード ID の割り当てのタイムアウトの処理が導入されています。これによりおよそ 20 秒後に ID 利用を自動的にチェックするため、PURGE STALE SESSIONS は通常のクラスタの起動においては必要なくなります。

各ノードが初期化された後、クラスタの起動プロセスが開始されます。クラスタがこのプロセスで行うステージを以下に示します。

  • ステージ 0

    クラスタのファイルシステムをクリアします。このステージはクラスタが--initial オプションで起動されたとき のみ 発生します。

  • ステージ 1

    このステージはクラスタの接続を設定し、インターノード通信を確立し、クラスタのハートビートを始動します。

    注:残りのノードがフェーズ 2 でハングしている時にフェーズ 1 で １ つ以上のノードがハングした場合は、ネットワークの問題が考えられます。そのような問題で考えられる原因の 1 つは 1 つ以上のホストが複数のネットワークのインターフェースを持っている場合です。この条件の別の共通の問題点はクラスタ ノードの通信に必要な TCP/IP ポートのブロックです。後者のケースでは、ファイアウォールの設定の仕方に問題がある場合がよくあります。

  • ステージ 2

    アービトレータ ノードが選択されます。これがシステムの再起動の場合、クラスタは最新の保存できるグルーバル チェックポイントを決定します。

  • ステージ 3

    このステージでは多くのクラスタの変数を初期化します。

  • ステージ 4

    最初の起動あるいは最初のノードに起動に対し、やり直し（redo） ログファイルが作成されます。これらのファイル数は NoOfFragmentLogFiles と同じです。

    システムの再起動:

    • スキーマを読んでください。

    • ローカルのチェックポイントからデータ読み込みログを元に戻し （ undo) ます。

    • 最新の保存できるグルーバル チェックポイントになるまでやり直し （redo) 情報を適用します。

    ノードの再起動には、やり直し （redo) ログの最後を探します。

  • ステージ 5

    これが最初の起動の場合、SYSTAB_0 および NDB$EVENTS 内部システム テーブルを作成します。

    ノードの再起動あるいは最初のノードの再起動：

    1. このノードはトランザクションの取扱い操作に含まれています。

    2. ノード スキーマはそのマスタに比較されそれと同期します。

    3. INSERT フォームでこのノード グループの他のデータ ノードから受信した同期データ

    4. すべてのケースにおいて、アービトレーターによって決められたローカル チェックポイントの完了を待ちます。

  • ステージ 6

    内部変数を更新します。

  • ステージ 7

    内部変数を更新します。

  • ステージ 8

    システムの再起動で、すべてのインデックスを再構築します。

  • ステージ 9

    内部変数を更新します。

  • ステージ 10

    この段階でノードの再起動あるいは最初のノードに再起動で、API がノードに接続してイベントを受け取ります。

  • ステージ 11

    この段階でノードの再起動あるいは最初の再起動で、イベントの配布はクラスタを結合するノードに渡されます。新たに結合されたノードはそのプライマリのデータをサブスクラーバーに届ける責任を負います。

最初の起動およびシステムの再起動のこのプロセスが完了すると、トランザクションの取扱いが有効になります。ノードの再起動あるいは最初のノードの再起動で、起動プロセスの完了はノードがトランザクションのコーオーデネーターとしての役割を始めたことを意味します。