このセクションでは、MySQL Cluster インストールのローリング再起動を実行する方法について説明します。このように呼ばれている理由は、クラスタ自体は操作可能のままになるように、各ノードを順番に停止および起動 (または再起動) することが伴うためです。これは多くの場合に、ローリングアップグレードまたはローリングダウングレードの一部として実行されます。ここでは、クラスタの高可用性が必須であり、クラスタ全体の停止時間は許可されません。一般に、ここで提供しているアップグレードについての情報は、ダウングレードにも適用されます。
ローリング再起動が望ましい理由は、いくつかあります。次のいくつかの段落で、これらについて説明します。
構成の変更 クラスタへの SQL ノードの追加や、構成パラメータの新しい値への設定などのクラスタ構成の変更を行うため。
MySQL Cluster ソフトウェアのアップグレードまたはダウングレード クラスタを新しいバージョンの MySQL Cluster ソフトウェアにアップグレード (または、古いバージョンにダウングレード) するため。通常、これは「ローリングアップグレード」 (古いバージョンの MySQL Cluster に戻す場合は、「ローリングダウングレード」) と呼ばれます。
ノードホスト上での変更 1 つ以上の MySQL Cluster ノードプロセスが実行されているハードウェアまたはオペレーティングシステムで変更を行うため。
システムのリセット (クラスタのリセット) 望ましくない状態に達したために、クラスタをリセットするため。このような場合は、多くの場合に 1 つ以上のデータノードのデータおよびメタデータを再ロードすることが望ましいと考えられます。これは、次の 3 つの方法のいずれかで実行できます。
--initial
オプションを付けて各データノードプロセス (ndbd、場合によっては ndbmtd) を起動します。これにより、強制的にデータノードのファイルシステムがクリアされ、その他のデータノードから MySQL Cluster のデータおよびメタデータがすべて再ロードされます。-
再起動を実行する前に、ndb_mgm クライアントの
BACKUP
コマンドを使用してバックアップを作成します。アップグレード後に、ndb_restore を使用して、1 つまたは複数のノードをリストアします。詳細は、セクション18.5.3「MySQL Cluster のオンラインバックアップ」およびセクション18.4.20「ndb_restore — MySQL Cluster バックアップのリストア」を参照してください。
アップグレード前に、mysqldump を使用してバックアップを作成します。その後、
LOAD DATA INFILE
を使用してダンプをリストアします。
リソースのリカバリ
ほかの MySQL Cluster テーブルで再利用するために、連続した INSERT
および DELETE
操作によって以前にテーブルに割り当てられたメモリーを解放するため。
ローリング再起動を実行するプロセスは、次のように一般化できます。
すべてのクラスタ管理ノード (ndb_mgmd プロセス) を停止し、再構成し、再起動します。(複数の管理サーバーでのローリング再起動を参照してください。)
各クラスタデータノード (ndbd プロセス) を順番に停止し、再構成し、再起動します。
各クラスタ SQL ノード (mysqld プロセス) を順番に停止し、再構成し、再起動します。
特定のローリングアップグレードの実装の詳細は、行われる変更によって異なります。次に、プロセスを詳しく説明します。

上記の図で、停止および起動のステップは、シェルコマンド (ほとんどの Unix システムでの kill など) または管理クライアントの STOP
コマンドを使用して、プロセスを完全に停止してから、必要に応じて ndbd または ndb_mgmd 実行可能ファイルを呼び出して、システムシェルから再起動する必要があることを示しています。Windows では、NET START
および NET STOP
コマンド、または Windows Service Manager を使用して、Windows サービスとしてインストールされているノードを起動および停止することもできます (セクション18.2.3.4「Windows サービスとしての MySQL Cluster プロセスのインストール」を参照してください)。
再起動は、ndb_mgm 管理クライアントの RESTART
コマンドを使用してプロセスを再起動できることを示しています (セクション18.5.2「MySQL Cluster 管理クライアントのコマンド」を参照してください)。
MySQL Cluster では、ノードをアップグレードする際に柔軟性のある順序がサポートされています。MySQL Cluster をアップグレードする場合、管理ノード、データノード、またはその両方をアップグレードする前に、API ノード (SQL ノードを含む) をアップグレードできます。言い換えると、API ノードおよび SQL ノードを任意の順序でアップグレードすることが許可されています。これには、次のような条件が課せられます。
この機能は、オンラインアップグレードの一部として使用することのみを目的としています。さまざまな MySQL Cluster リリースのノードバイナリを混在させることは、本番環境設定で継続的に長期間使用することを意図されておらず、サポートもされていません。
データノードをアップグレードする前に、すべての管理ノードをアップグレードする必要があります。このことは、クラスタの API ノードおよび SQL ノードをアップグレードする順序に関係なく当てはまります。
-
すべての管理ノードおよびデータノードがアップグレードされるまで、「新しい」バージョンに固有の機能は使用しないでください。
このことは、NDB エンジンバージョンの変更に加えて、適用される可能性のある任意の MySQL サーバーバージョンの変更にも適用されます。したがって、アップグレードを計画する際には、これを考慮に入れることを忘れないでください。(一般に、このことは MySQL Cluster のオンラインアップグレードに当てはまります。)
Bug #48528 および Bug #49163 も参照してください。
複数の管理サーバーでのローリング再起動 複数の管理ノードを持つ MySQL Cluster のローリング再起動を実行すると、ndb_mgmd によって、その他の管理ノードが実行されているかどうかがチェックされ、実行されている場合は、そのノードの構成データの使用が試みられることに注意してください。これが発生することを回避し、ndb_mgmd にその構成ファイルを強制的に再読み取りさせるには、次のステップを実行します。
MySQL 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
カラムを使用して、新しい構成で正常に再起動されたデータノードを追跡できます。セクション18.5.10.18「ndbinfo nodes テーブル」を参照してください。