18.5.5 MySQL Cluster のローリング再起動の実行

このセクションでは、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 操作によって以前にテーブルに割り当てられたメモリーを解放するため。

ローリング再起動を実行するプロセスは、次のように一般化できます。

1. すべてのクラスタ管理ノード (ndb_mgmd プロセス) を停止し、再構成し、再起動します。(複数の管理サーバーでのローリング再起動を参照してください。)

2. 各クラスタデータノード (ndbd プロセス) を順番に停止し、再構成し、再起動します。

3. 各クラスタ 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 にその構成ファイルを強制的に再読み取りさせるには、次のステップを実行します。

1. MySQL Cluster のすべての ndb_mgmd プロセスを停止します。

2. すべての config.ini ファイルを更新します。

3. 必要に応じて、--reload、--initial、またはその両方のオプションを付けて単一の ndb_mgmd を起動します。

4. 最初の ndb_mgmd を --initial オプションを付けて起動した場合は、残りの ndb_mgmd プロセスもすべて --initial を使用して起動する必要があります。

   最初の ndb_mgmd を起動するときに使用されたその他のオプションに関係なく、最初の ndb_mgmd プロセスのあとに、--reload を使用して残りのプロセスを再起動しないようにしてください。

5. 通常どおりに、データノードおよび API ノードのローリング再起動を完了します。

ローリング再起動を実行してクラスタの構成を更新する際に、ndbinfo.nodes テーブルの config_generation カラムを使用して、新しい構成で正常に再起動されたデータノードを追跡できます。セクション18.5.10.18「ndbinfo nodes テーブル」を参照してください。