このセクションでは、アップグレードとダウングレードの実行に関する NDB Cluster 8.0 のさまざまなリリース間の NDB Cluster ソフトウェアとテーブルファイルの互換性、および互換性マトリクスとノートについて説明します。 アップグレードまたはダウングレードを試みる前に、NDB Cluster のインストールおよび構成に精通している必要があります。 セクション23.3「NDB Cluster の構成」を参照してください。
SQL DDL ステートメントを含むスキーマ操作は、データノードの再起動中、およびクラスタのオンラインアップグレードまたはダウングレード中には実行できません。 オンラインアップグレードの実行に使用されるローリング再起動手順に関するその他の情報は、セクション23.5.5「NDB Cluster のローリング再起動の実行」 を参照してください。
このセクションでは、MySQL バージョン間の NDBCLUSTER に関する互換性のみを考慮しますが、考慮すべき問題はほかにもある場合があります。 NDB Cluster ソフトウェアのアップグレードまたはダウングレードを試みる前に、ほかの MySQL ソフトウェアのアップグレードまたはダウングレードと同様に、移行元および移行先の MySQL バージョンについて、MySQL マニュアルの関連する部分を確認することを強くお勧めします。 セクション2.11「MySQL のアップグレード」を参照してください。
ここに示すテーブルは、NDB 8.0 の異なるリリース間での NDB Cluster のアップグレードおよびダウングレードの互換性に関する情報を示しています。 NDB Cluster 8.0 リリースシリーズへのアップグレード、NDB Cluster 8.0 リリースシリーズからのダウングレード、または NDB Cluster 8.0 リリースシリーズ内でのダウングレードに関する追加のノートは、次のテーブルのあとにあります。
アップグレードとダウングレード、NDB Cluster 8.0
バージョンのサポート. NDB Cluster 8.0 (8.0.19 以降) の GA リリースへのアップグレードでは、次のバージョンの NDB Cluster がサポートされています:
NDB Cluster 7.6: NDB 7.6.4 以降
NDB Cluster 7.5: NDB 7.5.4 以降
NDB Cluster 7.4: NDB 7.4.6 以降
NDB 7.4 より前のリリースシリーズからアップグレードするには、最初にリストされているいずれかのバージョンにアップグレードしてから、そのバージョンから最新の NDB 8.0 リリースにアップグレードする必要があります。 このような場合は、最初の手順として最新の NDB 7.6 リリースにアップグレードすることをお勧めします。
既知の問題. NDB 8.0 リリース間でアップグレードする場合、次の問題が発生することがわかっています:
NDB 8.0.14 から以前のリリースへのオンラインダウングレードはサポートされていません。 NDB 8.0.14 で作成されたテーブルは、以前のリリースとの下位互換性がありません。 これは、MySQL データディクショナリを完全にサポートするために、
NDBテーブルによって実装される追加のメタデータプロパティの使用方法が変更されたためです。詳細は、NDB テーブルの追加メタデータの変更を参照してください。 第14章「MySQL データディクショナリ」も参照してください。
以前のリリースシリーズ (Distributed Privileges Using Shared Grant Tables を参照) で実装された MySQL サーバー間で共有される分散特権は、NDB Cluster 8.0 ではサポートされていません。 NDB 8.0.16 で提供される mysqld は、起動時に、あとで
NDBストレージエンジンを使用する付与テーブルの存在をチェックします。見つかった場合は、InnoDBを使用してこれらのローカルコピー (「「シャドウテーブル」」) を作成します。 これは NDB Cluster に接続されている各 MySQL サーバーに当てはまります。 NDB Cluster SQL ノードとして機能するすべての MySQL サーバーでこれが実行されたあと、NDB Cluster 配布に付属の ndb_drop_table ユーティリティーを使用して、NDB付与テーブルを安全に削除できます。次に例を示します:ndb_drop_table -d mysql user db columns_priv tables_priv proxies_priv procs_priv
NDB付与テーブルは安全に保持できますが、アクセス制御には使用されず、事実上無視されます。NDB 8.0 で使用される MySQL 特権システムの詳細は、セクション23.5.12「NDB_STORED_USER での分散 MySQL 権限」 および セクション6.2.3「付与テーブル」 を参照してください。
NDB 8.0.18 では、バイナリ構成ファイル形式が拡張され、以前のバージョンよりも多くのノードをサポートするようになりました。 新しい形式は、8.0.17 および古いノードからはアクセスできませんが、新しい管理サーバーは古いノードを検出し、適切な形式を使用してそれらと通信できます。
8.0.17 以前から NDB 8.0.18 以降へのアップグレードは、この点で問題になるべきではありません。 NDB 8.0.18 以降から 8.0.17 以前へのダウングレードの場合、古い管理サーバーは新しいバイナリ構成ファイル形式を読み取ることができないため、手動の介入が必要になります。 このようなダウングレードを実行する場合は、古い
NDBソフトウェアバージョンを使用して管理を開始する前に、キャッシュされたバイナリ構成ファイルを削除し、管理サーバーでプレーンテキスト構成ファイルを読み取ることができるようにする必要があります。 または、--initialオプションを使用して古い管理サーバーを起動することもできます (再度、config.iniを使用可能にする必要があります)。 クラスタで複数の管理サーバーを使用する場合は、管理サーバーバイナリごとに次の 2 つのいずれかを実行する必要があります。また、ノード数の増加のサポートに関連して、NDB 8.0.18 でデータノード LCP
Sysfileに実装された互換性のない変更のため、NDB 8.0.18 (以降) から以前のリリースへのオンラインダウングレードを実行して、--initialオプションを使用してすべてのデータノードを再起動する必要があります。NDB 7.6.4 より前のリリースを NDB 8.0 リリースにアップグレードする場合も、
--initialを使用してデータノードを再起動する必要があります。48 を超えるデータノードを実行しているクラスタ、または 48 を超えるノード ID を使用しているデータノードを NDB 8.0.17 以前の NDB 8.0.18 に直接ダウングレードすることはサポートされていません。 このような場合は、データノードの数を減らし、古い最大値を超えないように、48 以下のノード ID を使用するようにすべてのデータノードの構成を変更する必要があります。
NDB 8.0 から NDB 7.5 または NDB 7.4 にダウングレードする場合、まだ存在しないときは、クラスタ構成ファイルで
IndexMemoryの明示的な値を設定する必要があります。 これは、NDB 8.0 が (NDB 7.6 で削除された) このパラメータを使用せず、デフォルトで 0 に設定するのに対し、NDB 7.5 および NDB 7.4 では必須であり、IndexMemoryがゼロ以外の値に設定されていない場合、どちらのクラスタも「管理サーバーから無効な構成を受信しました ...」での起動を拒否するためです。NDB 8.0 から NDB 7.6 へのダウングレードには、
IndexMemoryの設定は必要ありません。NDB 8.0.22 では、
config.iniファイル内の管理ノードおよびデータノードに対する IPv6 アドレス指定のサポートが追加されました。 アップグレードの一環として IPv6 アドレスの使用を開始するには、次のステップを実行します:通常の方法で、8.0.22 以降のバージョンの NDB Cluster ソフトウェアへのクラスタのアップグレードを実行します。
config.iniファイルで使用されているアドレスを IPv6 アドレスに変更します。クラスタのシステム再起動を実行します。