このページは機械翻訳したものです。

23.5.4 NDB Cluster 起動フェーズのサマリー

このセクションでは、NDB Cluster データノードの起動時に必要な手順の簡単な概要を示します。 『NDB Internals Guide』のNDB Cluster Start Phasesでは、さらに完全な情報を見つけることができます。

これらのフェーズは、管理クライアントで node_id STATUS コマンドからの出力にレポートされるものと同じです (セクション23.5.1「NDB Cluster 管理クライアントのコマンド」を参照してください)。 これらの起動フェーズは、ndbinfo.nodes テーブルの start_phase カラムにもレポートされます。

起動のタイプ.  次のリストに示すように、さまざまな起動のタイプおよびモードがあります。

• 初期起動.  すべてのデータノード上のクリーンなファイルシステムでクラスタが起動します。 これは、まったくはじめてクラスタが起動されるとき、または --initial オプションを使用してすべてのデータノードが再起動されるときに発生します。

  注記

  --initial を使用してノードを再起動すると、ディスクデータファイルが削除されません。

• システムの再起動.  クラスタが起動し、データノードに格納されたデータを読み取ります。 これは、クラスタが使用されたあとにシャットダウンされたとき、およびクラスタが操作を中止した時点から再開することが望ましいときに発生します。

• ノードの再起動.  これは、クラスタ自体が実行しているときのクラスタノードのオンライン再起動です。

• ノードの初期再起動.  これは、クリーンなファイルシステムでノードが再初期化および起動される点を除いて、ノードの再起動と同じです。

設定と初期化 (フェーズ -1).  起動する前に、各データノード (ndbd プロセス) が初期化されている必要があります。 初期化は次のステップで構成されます。

1. ノード ID を取得します

2. 構成データをフェッチします

3. ノード間通信で使用されるポートを割り当てます

4. 構成ファイルから取得された設定に従って、メモリーを割り当てます

データノードまたは SQL ノードがはじめて管理ノードに接続すると、クラスタノード ID を予約します。 ほかのノードによって同じノード ID が割り当てられないように、この ID は、ノードからクラスタへの接続が完了し、このノードが接続されたことが少なくとも 1 つの ndbd でレポートされるまで保持されます。 このようなノード ID の保持は、該当するノードと ndb_mgmd 間の接続で保護されます。

各データノードが初期化されたら、クラスタの起動プロセスに進むことができます。 このプロセス中にクラスタが進む段階を次に示します。

• フェーズ 0.  NDBFS および NDBCNTR ブロックが起動します。 --initial オプションを付けて起動されたデータノード上で、データノードファイルシステムがクリアされます。

• フェーズ 1.  この段階では、残りのすべての NDB カーネルブロックが起動されます。 NDB Cluster 接続が設定され、ブロック間通信が確立され、ハートビートが開始されます。 ノードの再起動の場合は、API ノードの接続もチェックされます。

  注記

  フェーズ 1 で 1 つ以上のノードがハングアップし、フェーズ 2 で残りの 1 つまたは複数のノードがハングアップするときは、多くの場合にネットワークの問題を示しています。 このような問題が発生する原因の 1 つとして、複数のネットワークインタフェースを持つ 1 つ以上のクラスタホストが考えられます。 このような状況が発生する問題のもう 1 つの一般的な原因は、クラスタノード間の通信に必要な TCP/IP ポートのブロックです。 後者では、これは多くの場合に、ファイアウォールが誤って構成されているためです。

• フェーズ 2.  NDBCNTR カーネルブロックは、既存のすべてのノードの状態をチェックします。 マスターノードが選択され、クラスタスキーマファイルが初期化されます。

• フェーズ 3.  DBLQH および DBTC カーネルブロックは、それらの間の通信を設定します。 起動タイプが特定されます。これが再起動の場合、DBDIH ブロックは再起動を実行するための権限を取得します。

• フェーズ 4.  初期起動またはノードの初期再起動の場合、Redo ログファイルが作成されます。 これらのファイルの数は、NoOfFragmentLogFiles に等しいです。

  システムの再起動の場合:

  • 1 つまたは複数のスキーマを読み取ります。

  • ローカルチェックポイントからデータを読み取ります。

  • 最新のリストア可能なグローバルチェックポイントに達するまで、すべての Redo 情報を適用します。

  ノードの再起動の場合、Redo ログの末尾を検索します。

• フェーズ 5.  このフェーズ中に、データノード起動のデータベース関連部分のほとんどが実行されます。 初期起動またはシステムの再起動の場合、ローカルチェックポイントに続いて、グローバルチェックポイントが実行されます。 このフェーズ中に、メモリー使用率の定期的なチェックが開始され、必要なノードのテイクオーバーが実行されます。

• フェーズ 6.  このフェーズでは、ノードグループが定義および設定されます。

• フェーズ 7.  アービトレータノードが選択され、動作が開始されます。 次のバックアップ ID、およびバックアップディスクの書き込み速度が設定されます。 この起動フェーズに到達したノードは、Started とマークされます。 この時点で、API ノード (SQL ノードを含む) はクラスタに接続できます。

• フェーズ 8.  これがシステムの再起動の場合、すべてのインデックスが (DBDIH によって) 再構築されます。

• フェーズ 9.  ノード内部の起動変数がリセットされます。

• フェーズ 100 (廃止).  以前は、ノードの再起動またはノードの初期再起動のこの時点で、API ノードはノードに接続し、イベントの受信を開始できました。 現在は、このフェーズが空になっています。

• フェーズ 101.  ノードの再起動またはノードの初期再起動のこの時点で、クラスタに参加するノードにイベント配信が渡されます。 新たに参加したノードは、そのプライマリデータをサブスクライバに配信する責任を引き受けます。 このフェーズは、SUMA ハンドオーバーフェーズとも呼ばれます。

初期起動またはシステムの再起動の場合、このプロセスが完了すると、トランザクションの処理が有効になります。 ノードの再起動またはノードの初期再起動の場合、起動プロセスが完了したことは、現在ノードがトランザクションコーディネータとして動作している可能性があることを意味します。