PDF (Ltr)- 26.8 mb
PDF (A4)- 26.8 mb
HTML下载(TGZ)- 7.2 mb
HTML下载(邮政编码)- 7.2 mb
このセクションでは，MySQL集群管理器ンストルのロリング再起動を実行する方法にいて説明します。このように呼ばれている理由は,クラスタ自体は操作可能のままになるように,各ノードを順番に停止および起動(または再起動)することが伴うためです。これは多くの場合に，ロリングアップグレドまたはロリングダウングレドの一部として実行されます。ここでは，クラスタの高可用性が必須であり，クラスタ全体の停止時間は許可されません。一般に，ここで提供しているアップグレドにいての情報は，ダウングレ。
ロリング再起動が望ましい理由は，いく。次のいくかの段落で，これらにいて説明します。
構成の変更クラスタへのSQLノードの追加や,構成パラメータの新しい値への設定などのクラスタ構成の変更を行うため。
MySQL集群ソフトウェアのアップグレドまたはダウングレドクラスタを新しいバージョンのMySQL集群ソフトウェアにアップグレード(または,古いバージョンにダウングレード)するため。通常，これは「ロリングアップグレド」(古いバジョンのMySQL集群に戻す場合は，「ロリングダウングレド」と呼ばれます。
ノドホスト上での変更1つ以上のMySQL集群ノードプロセスが実行されているハードウェアまたはオペレーティングシステムで変更を行うため。
システムのリセット(クラスタのリセット)望ましくない状態に達したために，クラスタをリセットするため。このような場合は,多くの場合に1つ以上のデータノードのデータおよびメタデータを再ロードすることが望ましいと考えられます。これは，次の3の方法のいずれかで実行できます。
——初始オプションを付けて各デタノドプロセス(ndbd，場合によってはndbmtdを起動します。これにより,強制的にデータノードのファイルシステムがクリアされ,その他のデータノードからMySQL集群のデータおよびメタデータがすべて再ロードされます。再起動を実行する前に，ndb_mgmクラ邮箱アントの
备份コマンドを使用してバックアップを作成します。アップグレド後に，ndb_restoreを使用して，1または複数のノドをリストアします。詳細は，セクション18.5.3 " MySQL集群のオンラereplicationンバックアップ"およびセクション18.4.20 "ndb_restoreMySQL集群バックアップのリストア"を参照してください。
アップグレド前に，, mysqldumpを使用してバックアップを作成します。その後，
数据加载INFILEを使用してダンプをリストアします。
リソスのリカバリほかのMySQL集群テブルで再利用するために，連続した插入および删除操作によって以前にテブルに割り当てられたメモリを解放するため。
ロリング再起動を実行するプロセスは，次のように一般化できます。
すべてのクラスタ管理ノド(ndb_mgmdプロセス)を停止し，再構成し，再起動します。（複数の管理サバでのロリング再起動を参照してください。)
各クラスタデタノド(ndbdプロセス)を順番に停止し，再構成し，再起動します。
各クラスタSQLノノド(mysqldプロセス)を順番に停止し，再構成し，再起動します。
特定のロリングアップグレドの実装の詳細は，行われる変更によって異なります。次に，プロセスを詳しく説明します。
上記の図で，停止および起動のステップは，シェルコマンド(ほとんどのUnixシステムでの杀了など)または管理クラe @ e @アントの停止コマンドを使用して，プロセスを完全に停止してから，必要に応じてndbdまたはndb_mgmd実行可能ファルを呼び出して，システムシェルから再起動する必要があることを示しています。Windowsでは，网开始および净停止コマンド,またはWindows服务经理を使用して,Windowsサービスとしてインストールされているノードを起動および停止することもできます(セクション18.2.3.4“WindowsサービスとしてのMySQL集群プロセスのインストール”を参照してください)。
再起動は,ndb_mgm管理クラ邮箱アントの重新启动コマンドを使用してプロセスを再起動できることを示しています(セクション18.5.2“MySQL集群管理クラereplicationアントのコマンド”を参照してください)。
MySQL集群では,ノードをアップグレードする際に柔軟性のある順序がサポートされています。MySQL集群をアップグレードする場合,管理ノード,データノード,またはその両方をアップグレードする前に,APIノード(SQLノードを含む)をアップグレードできます。言い換えると、APIノードおよびSQLノードを任意の順序でアップグレードすることが許可されています。これには，次のような条件が課せられます。
この機能は、オンラ。さまざまなMySQL集群リリースのノードバイナリを混在させることは,本番環境設定で継続的に長期間使用することを意図されておらず,サポートもされていません。
デタノドをアップグレドする前に，すべての管理ノドする必要があります。このことは,クラスタのAPIノードおよびSQLノードをアップグレードする順序に関係なく当てはまります。
すべての管理ノドおよびデタノドがアップグレドされるまで，「新しい」バジョンに固有の機能は使用しないでください。
このことは,NDBエンジンバージョンの変更に加えて,適用される可能性のある任意のMySQLサーバーバージョンの変更にも適用されます。したがって，アップグレ，ドを計画する際には，これを考慮に入れることを忘れないでください。（一般に、このことは MySQL Cluster のオンラインアップグレードに当てはまります。)
Bug #48528およびBug #49163も参照してください。
複数の管理サバでのロリング再起動複数の管理ノドを持MySQL集群のロリング再起動を実行すると，ndb_mgmdによって,その他の管理ノードが実行されているかどうかがチェックされ,実行されている場合は,そのノードの構成データの使用が試みられることに注意してください。これが発生することを回避し，ndb_mgmdにその構成ファルを強制的に再読み取りさせるには，次のステップを実行します。
MySQL集群のすべてのndb_mgmdプロセスを停止します。
すべての
config.iniファ邮箱ルを更新します。必要に応じて，
——重新加载、——初始，またはその両方のオプションを付けて単一のndb_mgmdを起動します。最初のndb_mgmdを
——初始オプションを付けて起動した場合は，残りのndb_mgmdプロセスもすべて——初始を使用して起動する必要があります。最初のndb_mgmdを起動するときに使用されたその他のオプションに関係なく，最初のndb_mgmdプロセスのあとに，
——重新加载を使用して残りのプロセスを再起動しないようにしてください。通常どおりに，デタノドおよびAPIノリング再起動を完了します。
ロリング再起動を実行してクラスタの構成を更新する際に，ndbinfo.nodesテブルのconfig_generationカラムを使用して，新しい構成で正常に再起動されたデタノドを追跡できます。セクション18.5.10.18 " ndbinfo nodesテブル"を参照してください。