このセクションでは、NDB Cluster インストールのローリング再起動を実行する方法について説明します。これは、クラスタ自体が動作したままになるように、各ノードを順番に停止して起動 (または再起動) するためです。 これは多くの場合に、ローリングアップグレードまたはローリングダウングレードの一部として実行されます。ここでは、クラスタの高可用性が必須であり、クラスタ全体の停止時間は許可されません。 一般に、ここで提供しているアップグレードについての情報は、ダウングレードにも適用されます。
ローリング再起動が望ましい理由は、いくつかあります。 次のいくつかの段落で、これらについて説明します。
構成の変更. クラスタへの SQL ノードの追加や、構成パラメータの新しい値への設定などのクラスタ構成の変更を行うため。
NDB Cluster ソフトウェアアップグレードまたはダウングレード. NDB Cluster ソフトウェアの新しいバージョンにクラスタをアップグレードする (または古いバージョンにダウングレードする)。 これは通常、古いバージョンの NDB Cluster に戻す場合、「「ローリングアップグレード」」 (または「「ローリングダウングレード」」) と呼ばれます。
ノードホスト上での変更. 1 つまたは複数の NDB Cluster ノードプロセスが実行されているハードウェアまたはオペレーティングシステムに変更を加えるため。
システムのリセット (クラスタのリセット). 望ましくない状態に達したために、クラスタをリセットするため。 このような場合は、多くの場合に 1 つ以上のデータノードのデータおよびメタデータを再ロードすることが望ましいと考えられます。 これは、次の 3 つの方法のいずれかで実行できます。
-
--initialオプションを使用して各データノードプロセス (ndbd または場合によっては ndbmtd) を起動します。これにより、データノードはそのファイルシステムを強制的にクリアし、ほかのデータノードからすべての NDB Cluster データおよびメタデータをリロードします。NDB 8.0.21 以降では、これらのオブジェクトに関連付けられたすべてのディスクデータオブジェクトおよびファイルも強制的に削除されます。
-
再起動を実行する前に、ndb_mgm クライアントの
START BACKUPコマンドを使用してバックアップを作成します。 アップグレード後に、ndb_restore を使用して、1 つまたは複数のノードをリストアします。詳細は、セクション23.5.8「NDB Cluster のオンラインバックアップ」およびセクション23.4.23「ndb_restore — NDB Cluster バックアップの復元」を参照してください。
mysqldump を使用して、アップグレード前にバックアップを作成します。その後、
LOAD DATAを使用してダンプをリストアします。
リソースのリカバリ.
他の「NDB Cluster」テーブルで再利用するために、INSERT および DELETE の連続した操作によって以前にテーブルに割り当てられたメモリーを解放します。
ローリング再起動を実行するプロセスは、次のように一般化できます。
すべてのクラスタ管理ノード (ndb_mgmd プロセス) を停止し、再構成し、再起動します。 (複数の管理サーバーでのローリング再起動を参照してください。)
-
各クラスタデータノード (ndbd プロセス) を順番に停止し、再構成し、再起動します。
一部のノード構成パラメータは、前のステップに従って ndb_mgm クライアントの各データノードに対して
RESTARTを発行することで更新できます。 その他のパラメータでは、管理クライアントのSTOPコマンドを使用してデータノードを完全に停止してから、必要に応じて ndbd または ndbmtd 実行可能ファイルを呼び出してシステムシェルから再度起動する必要があります。 (ほとんどの Unix システムでは、kill などのシェルコマンドを使用してデータノードのプロセスを停止することもできますが、STOPコマンドが推奨され、通常はより簡単です。)注記Windows では、SC STOP および SC START コマンド、
NET STOPおよびNET STARTコマンド、または Windows サービスマネージャーを使用して、Windows サービスとしてインストールされているノードを停止および起動することもできます (セクション23.2.2.4「NDB Cluster プロセスを Windows サービスとしてインストール」 を参照)。必要な再起動のタイプは、各ノード構成パラメータのドキュメントに示されています。 セクション23.3.3「NDB Cluster 構成ファイル」を参照してください。
各クラスタ SQL ノード (mysqld プロセス) を順番に停止し、再構成し、再起動します。
NDB Cluster は、ノードをアップグレードするためにある程度柔軟な順序をサポートしています。 NDB Cluster をアップグレードするときは、管理ノード、データノード、またはその両方をアップグレードする前に、API ノード (SQL ノードを含む) をアップグレードできます。 言い換えると、API ノードおよび SQL ノードを任意の順序でアップグレードすることが許可されています。 これには、次のような条件が課せられます。
この機能は、オンラインアップグレードの一部として使用することのみを目的としています。 異なる NDB Cluster リリースからのノードバイナリの混在は、本番設定での継続的な長期的な使用を目的としておらず、サポートされていません。
データノードをアップグレードする前に、すべての管理ノードをアップグレードする必要があります。 このことは、クラスタの API ノードおよび SQL ノードをアップグレードする順序に関係なく当てはまります。
-
すべての管理ノードおよびデータノードがアップグレードされるまで、「新しい」バージョンに固有の機能は使用しないでください。
このことは、NDB エンジンバージョンの変更に加えて、適用される可能性のある任意の MySQL サーバーバージョンの変更にも適用されます。したがって、アップグレードを計画する際には、これを考慮に入れることを忘れないでください。 (これは、NDB Cluster のオンラインアップグレード全般に当てはまります。)
どの API ノードでも、ノードの再起動時にスキーマ操作 (データ定義ステートメントなど) を実行できません。 この制限の一部であるため、オンラインでのアップグレードまたはダウングレード中にスキーマ操作もサポートされません。
複数の管理サーバーでのローリング再起動. 複数の管理ノードを持つ NDB Cluster のローリング再起動を実行する場合、ndb_mgmd はほかの管理ノードが実行されているかどうかを確認し、実行されている場合はそのノード構成データを使用しようとすることに注意してください。 これが発生することを回避し、ndb_mgmd にその構成ファイルを強制的に再読み取りさせるには、次のステップを実行します。
すべての NDB Cluster ndb_mgmd プロセスを停止します。
すべての
config.iniファイルを更新します。必要に応じて、
--reload、--initial、またはその両方のオプションを付けて単一の ndb_mgmd を起動します。-
最初の ndb_mgmd を
--initialオプションを付けて起動した場合は、残りの ndb_mgmd プロセスもすべて--initialを使用して起動する必要があります。最初の ndb_mgmd を起動するときに使用されたその他のオプションに関係なく、最初の ndb_mgmd プロセスのあとに、
--reloadを使用して残りのプロセスを再起動しないようにしてください。 通常どおりに、データノードおよび API ノードのローリング再起動を完了します。
ローリング再起動を実行してクラスタの構成を更新する際に、ndbinfo.nodes テーブルの config_generation カラムを使用して、新しい構成で正常に再起動されたデータノードを追跡できます。 セクション23.5.14.38「ndbinfo nodes テーブル」を参照してください。