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

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

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

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

  説明

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

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

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

  • データベースプロキシの制限 (該当する場合)： 5.7 から 8.0 へのアップグレードの場合、データベースプロキシのマイナーバージョンは 1.13.41 以降である必要があります。8.0 から 8.4 へのアップグレードの場合、データベースプロキシのマイナーバージョンは 2.25.11 以降である必要があります。

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

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

  • インスタンスは提供終了のインスタンスタイプを使用していない必要があります。

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

  • データベースプロキシの制限 (該当する場合)： 5.7 から 8.0 へのアップグレードの場合、データベースプロキシのマイナーバージョンは 1.13.41 以降である必要があります。8.0 から 8.4 へのアップグレードの場合、データベースプロキシのマイナーバージョンは 2.25.11 以降である必要があります。

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

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

  • インスタンスは提供終了のインスタンスタイプを使用していない必要があります。

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

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

  • データベースプロキシの制限 (該当する場合)： 5.7 から 8.0 へのアップグレードの場合、データベースプロキシのマイナーバージョンは 1.13.41 以降である必要があります。8.0 から 8.4 へのアップグレードの場合、データベースプロキシのマイナーバージョンは 2.25.11 以降である必要があります。

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

  • テーブル数の制限： テーブル数は 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 8.0 から MySQL 8.4 へのアップグレードのメリット

• 長期的な安定性の向上。MySQL 8.4 は LTS (長期サポート) リリースであり、本番環境での長期使用に適しています。以降の 8.4.x リリースは、安定性、セキュリティ修正、および互換性の維持に重点を置いています。

• 認証の強化。WebAuthn/FIDO2 認証をサポートします。Enterprise Edition は、セキュリティキー、生体認証、その他の認証方式を使用できます。Windows では、SASL LDAP/GSSAPI/Kerberos 認証がサポートされています。

• GTID 機能の強化。タグ付き GTID をサポートします。UUID:TAG:NUMBER 形式を使用して、異なるビジネスドメイン、管理操作、またはデータ操作を区別でき、TRANSACTION_GTID_TAG 権限はアクセスの制御を提供します。

• レプリケーションの可用性の向上。マルチスレッドアプライヤーは SQL_AFTER_GTIDS をサポートしているため、レプリカが指定された GTID セットに追いついたときにパラレルレプリケーションを続行できます。

• リレーログの回復性の向上。リレーログの末尾にある不完全なトランザクションと関連する残存ファイルをクリーンアップする機能をサポートし、異常シャットダウン後のリレーログの不整合による回復リスクを低減します。

• グループレプリケーション操作の強化。8.4 LTS シリーズ内では、クロスバージョンのグループメンバーとインプレースダウングレードがサポートされ、プライマリ切り替え中の DDL および DCL 操作の待機がより完全になり、シングルプライマリモードでの認証情報の事前クリーンアップがサポートされ、メモリと切り替えのリスクが低減されます。

• 統計の改善。ヒストグラムは自動または手動の更新制御をサポートし、オプティマイザーの統計メンテナンスの制御性を向上させます。

• 実行計画診断の強化。EXPLAIN FORMAT=JSON はフォーマットバージョンの選択をサポートし、EXPLAIN FORMAT=JSON INTO は出力をユーザー変数に書き込み、EXPLAIN FOR SCHEMA と FOR DATABASE がサポートされ、スキーマをまたいだ SQL の診断が容易になります。

• TLS 証明書検証の強化。より厳格な TLS 証明書検証をサポートし、暗号化された接続のセキュリティを向上させます。

• クローンの改善。同じメジャーまたはマイナーシリーズ内では、クローン操作は正確なポイントリリースの一致を必要としなくなり、8.4.x バージョン間のインスタンスの初期化、回復、スケーリングが容易になります。

• 監査とファイアウォールの強化。Enterprise Firewall は、定期的なキャッシュの再読み込みとカスタムの内部オブジェクトスキーマをサポートし、運用の柔軟性を高めます。

• キー管理移行の改善。キーリングコンポーネントからキーリングプラグインへの移行をサポートし、暗号化移行と互換性シナリオの柔軟性を向上させます。

• アップグレードの可観測性の向上。データディレクトリは、インストールとアップグレードの履歴を監査とトラブルシューティングのために記録する JSON 形式の mysql_upgrade_history を維持します。

• SQL とオプティマイザーの進化の強化。TABLESAMPLE、QUALIFY、PARALLEL などのキーワードを追加し、将来の SQL とオプティマイザーの拡張の基盤を提供します。

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

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

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

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

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

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

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

• 同期性能を向上させます。

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

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

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

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

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

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

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

• JSON をサポートします。

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

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

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

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

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

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

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

付録 4：MySQL 8.4 と MySQL 8.0 の機能差分

付録 5：MySQL 8.0 と MySQL 5.7 の機能差分

付録 6：MySQL 5.7 と MySQL 5.6 の機能差分

付録 7：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