Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 27.1Mb
PDF (A4) - 27.1Mb
EPUB - 7.5Mb
HTML Download (TGZ) - 7.2Mb
HTML Download (Zip) - 7.2Mb


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 プロセス) を順番に停止し、再構成し、再起動します。

特定のローリングアップグレードの実装の詳細は、行われる変更によって異なります。次に、プロセスを詳しく説明します。

MySQL Cluster のローリング再起動 (タイプ別)

上記の図で、停止および起動のステップは、シェルコマンド (ほとんどの 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 テーブル」を参照してください。


User Comments
  Posted by David Lotts on December 20, 2007
I am not sure if the following is documented, so I am putting in here. We used Server version: 5.0.45 MySQL Community Server (GPL)

It appears that ndbd rolling restarts wait for transactions to commit, but eventually time out and close the uncommited connection.

I think this is good behavior, it cleans up stalled transactions that would probably fail anyway, and then starts the node.

This came out of a lot of interesting scenarios spanning rolling restarts. We only start and stop ndbd. We have 2 ndb notes containing all the data, node 6 and 7.
I used two terminals, indicated below by prompts ndb_mgm> and mysql>. Read above how "restart -n" is like stop, but it can be started later from the ndb_mgm. Here is how I did the experiment:

ndb_mgm> 7 start
ndb_mgm> 6 restart -n
### This effectively stops node 6
ndb_mgm> show
### Observe node 6 is down, 7 is up

mysql> start transaction;
mysql> insert ...;

ndb_mgm> 6 start
ndb_mgm> show
### Node 6 six will stay in a "Starting" state for several minutes.
### if you commit the transaction, 6 will immediately start.
### if you wait until node 6 starts, 5 or 10 minutes, the following happens in the mysql client terminal:

mysql> select * from ...;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 165066
Current database: *** NONE ***

### Observe that the insert transaction was rolled back.
### That's it.

Speculative conclusion: rolling restarts wait for commits, but eventually time out and close the uncommitted connection.

  Posted by Tristan Sloughter on October 11, 2011
This fails to mention what you must do if you make a change to the number of replicas. You update can be applied 'online'.
Sign Up Login You must be logged in to post a comment.