ApsaraDB RDS:データベースバージョンのアップグレード

アップグレード方法の選択

方法 1：コンソールで直接データベースバージョンをアップグレードすると方法 2：DTS を使用してデータベースバージョンをアップグレードするは、どちらも MySQL 5.5 から 5.6、5.6 から 5.7、5.7 から 8.0 へのアップグレードパスをサポートしています。データベースをアップグレードする前に、以下の情報に基づいて適切なアップグレード方法を選択してください：

• ご利用のインスタンスが以下の 4 つのカテゴリのいずれかに属し、その構成が対応する要件を満たしている場合は、方法 1：コンソールで直接データベースバージョンをアップグレードするを使用してください。

  説明

  • サーバーレスインスタンスは、コンソールからの直接アップグレードをサポートしていません。方法 2：DTS を使用してデータベースバージョンをアップグレードするを使用する必要があります。

  • MySQL 8.0 から MySQL 8.4 へのアップグレードは、コンソール経由ではサポートされていません。このアップグレードパスには方法 2：DTS を使用してデータベースバージョンをアップグレードするを使用してください。

  Cluster Edition (ESSD およびパフォーマンス専有型ディスク)

  • グループレプリケーションの制限：MySQL グループレプリケーション (MGR) を使用する Cluster Edition インスタンスはアップグレードできません。

  • データベースプロキシの制限 (該当する場合)：データベースプロキシのマイナーバージョンは 1.13.41 以降である必要があります。

  • インスタンスステータスの制限：インスタンスステータスは 実行中 であり、プライマリノードとセカンダリノードが正常で、レプリケーションの遅延がない必要があります。

  • エンジン制限：データベースとそのすべてのテーブルは InnoDB ストレージエンジンを使用する必要があります。

  • インスタンスは廃止されたインスタンスタイプを使用していない必要があります。

  High-availability Edition (ESSD およびパフォーマンス専有型ディスク)

  • データベースプロキシの制限 (該当する場合)：データベースプロキシのマイナーバージョンは 1.13.41 以降である必要があります。

  • インスタンスステータスの制限：インスタンスステータスは 実行中 であり、プライマリノードとセカンダリノードが正常で、レプリケーションの遅延がない必要があります。

  • エンジン制限：データベースとそのすべてのテーブルは InnoDB ストレージエンジンを使用する必要があります。

  • インスタンスは廃止されたインスタンスタイプを使用していない必要があります。

  High-availability Edition (パフォーマンス専有型ローカルディスク)

  • 暗号化の制限：TDE (透過的データ暗号化) 機能が無効になっている必要があります。TDE を有効にすると、無効にすることはできません。ご利用のインスタンスで TDE が有効になっている場合は、方法 2：DTS を使用してデータベースバージョンをアップグレードするを使用する必要があります。

  • データベースプロキシの制限 (該当する場合)：データベースプロキシのマイナーバージョンは 1.13.41 以降である必要があります。

  • インスタンスステータスの制限：インスタンスステータスは 実行中 であり、プライマリノードとセカンダリノードが正常で、レプリケーションの遅延がない必要があります。

  • テーブル数の制限：テーブル数は 100 万を超えることはできません。

  • エンジン制限：データベースとそのすべてのテーブルは InnoDB ストレージエンジンを使用する必要があります。

  • インスタンスタイプの制限：アップグレード後のデータベースバージョンは、プライマリインスタンスと読み取り専用インスタンスの元のインスタンスタイプをサポートしている必要があります。インスタンスは廃止されたインスタンスタイプを使用していない必要があります。詳細については、「プライマリ ApsaraDB RDS for MySQL インスタンスタイプ」をご参照ください。

  Basic Edition (ESSD およびパフォーマンス専有型ディスク)

  • インスタンスステータスの制限：インスタンスステータスは 実行中 である必要があります。

  • エンジン制限：データベースとそのすべてのテーブルは InnoDB ストレージエンジンを使用する必要があります。

  • インスタンスは廃止されたインスタンスタイプを使用していない必要があります。

• ご利用のインスタンスが上記の 4 つのカテゴリのいずれにも属さない場合、または TDE が有効になっている場合は、方法 2：DTS を使用してデータベースバージョンをアップグレードするを使用してください。

• ご利用のインスタンスが上記の 4 つのカテゴリのいずれかに属しているが、その構成が要件を満たしていない場合は、次の表に示すように構成を変更できます。その後、方法 1：コンソールで直接データベースバージョンをアップグレードするまたは方法 2：DTS を使用してデータベースバージョンをアップグレードするのいずれかを使用できます。

  問題	解決策
  インスタンスステータスが [実行中] ではありません。例：再起動中。	現在のタスクが完了するのを待ってから、データベースバージョンをアップグレードしてください。
  パフォーマンス専有型ローカルディスクを備えた High-availability Edition インスタンスのテーブル数が 100 万を超えています。	アップグレード前に冗長なテーブルを削除してください。
  一部のデータベースまたはテーブルが InnoDB ストレージエンジンを使用していません。	ALTER TABLE <table_name> engine=InnoDB; コマンドを実行して、InnoDB ストレージエンジンに切り替えてください。
  インスタンスが廃止されたインスタンスタイプを使用しています。	データベースバージョンをアップグレードする前に、インスタンスタイプをアップグレードしてください。詳細については、「構成の変更」をご参照ください。
  データベースプロキシのマイナーバージョンが要件を満たしていません。	データベースプロキシのマイナーバージョンを 1.13.41 以降にアップグレードしてください。詳細については、「データベースプロキシのマイナーエンジンバージョンのアップグレード」をご参照ください。
  インスタンスのストレージタイプが標準 SSD です。	まず、標準 SSD を ESSD (エンタープライズ SSD) にアップグレードし、その後データベースバージョンをアップグレードしてください。

他のデータベースエンジンのメジャーバージョンをアップグレードするには、次のトピックをご参照ください：

• ApsaraDB RDS for PostgreSQL インスタンスのメジャーデータベースバージョンのアップグレード

• ApsaraDB RDS for SQL Server インスタンスのメジャーデータベースバージョンのアップグレード

方法 1：コンソールで直接データベースバージョンをアップグレードする

方法 2：DTS を使用したデータベースバージョンのアップグレード

コンソールからの直接アップグレードをサポートしていないインスタンスの場合、新しいデータベースバージョンの新しいインスタンスを作成できます。その後、DTS データ移行タスクを使用して、元のインスタンスから新しいインスタンスにデータを移行します。これにより、間接的にデータベースバージョンがアップグレードされます。このプロセスには、次の手順が含まれます：

1. 新しいインスタンスの作成

2. 新しいインスタンスへのデータ移行

3. 元のインスタンスのリリース

例：TDE が有効になっている MySQL 5.7 インスタンスがあり、コンソールから直接アップグレードできません。この場合、MySQL 8.0 を実行する新しいインスタンスを作成し、元のインスタンスから新しいインスタンスにデータを移行し、最後に元のインスタンスをリリースします。これにより、間接的にデータベースバージョンがアップグレードされます。

付録 1：MySQL 5.7 から MySQL 8.0 へのアップグレードのメリット

• セキュリティを向上させ、アカウント管理の柔軟性を高めます。

• リソースグループの作成と管理をサポートします。

• InnoDB ストレージエンジンの機能を強化します。

• 新しい文字セット、データ型、構文、新しいバックアップロック、および optimizer_switch フラグのサポートを追加します。

• JSON および XML 機能を強化します。

• オプティマイザーの機能を強化します。

• レプリケーション性能を向上させます。

• 複数値インデックスの作成と派生条件プッシュダウン最適化をサポートします。

• MySQL 権限付与テーブルの読み取りをサポートします。

• リソース割り当て制御をサポートします。

付録 2：MySQL 5.6 から MySQL 5.7 へのアップグレードのメリット

• パスワード管理、アカウントロック、暗号化接続などの機能を追加して、データベースのセキュリティを向上させます。

• RENAME INDEX を使用したインデックスの名前変更など、オンライン DDL 操作をサポートします。

• InnoDB エンジンのスケーラビリティと一時テーブルのパフォーマンスを向上させ、データロードを高速化します。

• JSON をサポートします。

• パーティションテーブルのインデックス条件プッシュダウン (ICP) と新しい InnoDB 空間インデックスをサポートします。

• ほとんどのパーサ、オプティマイザー、コストモデルを最適化し、データベースの保守性、スケーラビリティ、パフォーマンスを向上させます。

• 中国国家標準で指定されている GB18030 文字セットを含む、サポートされる文字セットの範囲を拡大します。

• 中国語、日本語、韓国語をサポートする ngram フルテキストパーサプラグインを提供します。

• ソースダンプスレッドを最適化して、ロック競合を減らし、ソーススループットを向上させます。

• レプリケーションの遅延を大幅に削減します。

• sys システムデータベースを追加し、複数のメトリックを提供し、ストレージ使用量を削減し、データベースの使いやすさを大幅に向上させます。

付録 3：MySQL 8.0 と MySQL 5.7 の機能の違い

付録 4：MySQL 5.7 と MySQL 5.6 の機能の違い

付録 5：MySQL 5.5 と MySQL 5.6 の機能の違い

よくある質問

• Q：アップグレード中にインスタンスのスイッチオーバーが発生するのはなぜですか？他に深刻なリスクはありますか？

  A：サービスの安定性を確保するため、パフォーマンス専有型ローカルディスクを持つインスタンスは、まずセカンダリノードをアップグレードし、その後スイッチオーバーを実行してアップグレードされます。ESSD を持つインスタンスは、新しいノードを作成し、その後スイッチオーバーを実行してアップグレードされます。他に深刻なリスクはありません。プライマリ/セカンダリフェールオーバーの影響に関する詳細については、「プライマリ/セカンダリフェールオーバーの影響」をご参照ください。

• Q：プライマリノードとセカンダリノードは同時にアップグレードされますか？

  A：パフォーマンス専有型ローカルディスクをアップグレードする場合、まずセカンダリインスタンスがアップグレードされ、次にプライマリインスタンスがアップグレードされます。

• Q：標準 SSD を使用する MySQL 5.7 の Basic Edition インスタンスをアップグレードするにはどうすればよいですか？

  A：このタイプのインスタンスは直接アップグレードできません。標準 SSD を使用する MySQL 5.7 の Basic Edition インスタンスをアップグレードするには、まずストレージタイプを標準 SSD から ESSD に変更し、その後データベースバージョンをアップグレードする必要があります。

• Q：データベースバージョンをアップグレードした後、パラメータテンプレートは保持されますか？

  A：状況によります。アップグレード前にインスタンスがシステムパラメータテンプレートを使用している場合、自動的に新しいバージョンの対応するシステムパラメータテンプレートに切り替わります。たとえば、MySQL_InnoDB_5.7_High-availability_Performance パラメータテンプレートを使用しているインスタンスは、MySQL 5.7 から 8.0 へのアップグレード後、MySQL_InnoDB_8.0_High-availability_Performance パラメータテンプレートに切り替わります。ただし、インスタンスがカスタムパラメータテンプレートを使用している場合、アップグレード後にパラメータテンプレートは保持されません。

• Q：データベースバージョンのアップグレード中にインスタンスを変更できますか？

  A：いいえ、できません。アップグレードが完了した後にのみ、インスタンスで他の操作を実行できます。

• Q：データベースバージョンは自動アップグレードをサポートしていますか？

  A：いいえ、サポートしていません。メジャーバージョンの自動アップグレードはサポートされていません。

• Q：データベースバージョンをダウングレードできますか？

  A：いいえ、コンソールから直接バージョンをダウングレードすることはできません。インスタンスにビジネスデータが含まれているかどうかに基づいて、次のいずれかの方法を選択してください：

  • ビジネスデータあり：古いバージョンを実行するインスタンスを購入し、DTS を使用して高バージョンインスタンスから新しい低バージョンインスタンスにデータを移行し、移行完了後に高バージョンインスタンスをリリースします。これにより、間接的にデータベースバージョンがダウングレードされます。詳細については、「RDS インスタンス間のデータ移行」をご参照ください。

  • ビジネスデータなし：元のインスタンスの登録を解除し、必要な古いバージョンを実行する新しいインスタンスを購入します。サブスクリプションインスタンスの場合は、返金プロセスに従って登録を解除します。従量課金インスタンスの場合は、直接リリースします。

• Q：RDS for MySQL インスタンスを 5.6 から 5.7 または 5.7 から 8.0 にアップグレードすると、アップグレードが失敗し、「現在のインスタンスにはフルテキストインデックスがあり、そのマイナーバージョンは 20221130 より前です。フルテキストインデックスを削除して再構築する前に、マイナーバージョンをアップグレードしてください」または「現在のインスタンスにはシステム表領域に構築されたフルテキストインデックスが含まれています。アップグレードを進める前に、対応するフルテキストインデックスを削除して再構築してください」というメッセージが表示されます。原因と解決策は何ですか？

  A：原因と解決策は次のとおりです：

  • 原因

    MySQL の過去の問題により、MySQL 5.6 の初期バージョンでフルテキストインデックスを作成すると、システム表領域に構築されます。バージョン 5.7 または 8.0 にアップグレードすると、システム表領域内のフルテキストインデックスが表領域の破損を引き起こす可能性があります。したがって、データ破損やアクセス不能を防ぐために、アップグレード前にこの問題を解決する必要があります。

    説明

    この問題は、RDS for MySQL 5.6 バージョン 20221130 で修正されました。フルテキストインデックスは現在、別の表領域に構築されます。

  • 解決策

    重要

    RDS for MySQL 5.6 の初期バージョンのフルテキストインデックスは、システム表領域に作成されます。したがって、RDS for MySQL 5.7 にアップグレードする前に、アップグレード元のバージョンが RDS for MySQL 5.6 20221130 以降であることを確認してください。古いバージョンを使用している場合は、まず RDS for MySQL 5.6 の最新バージョンにアップグレードしてください。

    1. プロンプトのテーブル名に基づいて、システム表領域に構築されたフルテキストインデックスを削除します。

       # フルテキストインデックスを削除します。
       ALTER TABLE $table_name DROP INDEX $fts_name;

    2. フルテキストインデックスを再作成します。

       # フルテキストインデックスを再作成します。
       ALTER TABLE $table_name ADD FULLTEXT INDEX $fts_name;

    3. インデックスを作成した後、次の SQL ステートメントを実行して、現在のインスタンスのフルテキストインデックスを確認できます。このステートメントは、システム表領域に構築されたフルテキストインデックスを返します。クエリが空の結果を返す場合、RDS for MySQL 5.6 から RDS for MySQL 5.7 へのアップグレードはこの問題で失敗しません。

       # システム表領域に構築されたフルテキストインデックスをクエリします。
       SELECT NAME FROM information_schema.INNODB_SYS_TABLES WHERE TABLE_ID IN ( SELECT CONV(SUBSTRING_INDEX(SUBSTRING_INDEX(NAME, '_', -4),'_', 1),16,10) FROM INNODB_SYS_TABLES WHERE NAME LIKE '%fts_00000000%' AND SPACE = 0);

• Q：RDS for MySQL インスタンスを 5.7 から 8.0 にアップグレードすると、エラー 267 - Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8mb4_0900_ai_ci,IMPLICIT) for operation '=' が報告されます。どのように対処すればよいですか？

  A：MySQL の文字セットと照合順序を確認してください。utf8mb4_general_ci を使用している場合は、次の SQL ステートメントを実行して utf8mb4_0900_ai_ci に変更してください。

  # データベースの文字セットと照合順序を変更します。
  ALTER DATABASE database_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci;
  # テーブルの文字セットと照合順序を変更します。
  ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE = utf8mb4_0900_ai_ci;
  # フィールドの文字セットと照合順序を変更します。
  ALTER TABLE table_name CHANGE column_name column_name type CHARACTER SET utf8mb4 COLLATE = utf8mb4_0900_ai_ci;

  MySQL 5.7 で utf8mb4_general_ci 照合順序を使用してテーブルを作成し、その後 MySQL 8.0 にアップグレードすると、システムは utf8mb4_0900_ai_ci をデフォルトの照合順序として使用します。utf8mb4_general_ci を使用するカラムと utf8mb4_0900_ai_ci を使用するカラムを比較するクエリを実行すると、MySQL は 2 つの異なる照合順序を処理できず、エラーが発生します。

• Q：メジャーバージョンアップグレードの一時的な接続時間は、読み取り専用インスタンスの有無にかかわらず、常に 15 秒ですか？

  A：はい、そうです。オフピーク時にアップグレードを実行することを推奨します。

関連 API 操作