すべてのプロダクト
Search
ドキュメントセンター

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

最終更新日:Apr 02, 2026

ApsaraDB RDS for MySQL は、データベースのメジャーバージョンをアップグレードするために、コンソールでの直接アップグレードと、Data Transmission Service (DTS) を使用した移行ベースのアップグレードの 2 つの方法をサポートしています。どちらの方法も、MySQL のすべての主要なバージョンパス (5.5 から 5.6、5.6 から 5.7、5.7 から 8.0) をサポートしています。

コンソールからメジャーバージョンをダウングレードすることはサポートされていません。ダウングレードするには、以前のバージョンを実行しているインスタンスを購入し、DTS を使用してデータを移行してから、新しいバージョンのインスタンスをリリースする必要があります。詳細については、「ApsaraDB RDS for MySQL インスタンス間のデータ移行」および「インスタンスのリリースまたは登録解除」をご参照ください。

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

方法 利用シーン
方法 1:コンソールでのアップグレード インスタンスがサポートされている 4 つのエディションのいずれかに属し (下記の表を参照)、すべての構成要件を満たしている場合。
方法 2:DTS 移行 インスタンスが Serverless インスタンスであるか、TDE (透過的データ暗号化) が有効になっているか、またはインスタンスが方法 1 の要件を満たしていない場合。

方法 1 でサポートされるエディションと要件

次の表に、コンソールでの直接アップグレードをサポートする 4 つのインスタンスエディションと、それぞれの特定の要件を示します。

Cluster Edition (ESSD および高性能ディスク)

  • MySQL グループレプリケーション (MGR) は使用できません。

  • データベースプロキシが構成されている場合、そのマイナーバージョンは 1.13.41 以降である必要があります。

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

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

  • 廃止されたインスタンスタイプ を使用していてはなりません。

High-availability Edition (ESSD および高性能ディスク)

  • データベースプロキシが構成されている場合、そのマイナーバージョンは 1.13.41 以降である必要があります。

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

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

  • 廃止されたインスタンスタイプ を使用していてはなりません。

High-availability Edition (高性能ローカルディスク)

  • TDE (透過的データ暗号化) は無効にする必要があります。TDE は一度有効にすると無効にできません。TDE が有効な場合は、方法 2 を使用してください。

  • データベースプロキシが構成されている場合、そのマイナーバージョンは 1.13.41 以降である必要があります。

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

  • テーブルの総数は 100 万を超えてはなりません。

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

  • ターゲットバージョンは、プライマリインスタンスと読み取り専用インスタンスの現在のインスタンスタイプをサポートしている必要があります。詳細については、「プライマリ ApsaraDB RDS for MySQL インスタンスタイプ」をご参照ください。

Basic Edition (ESSD および高性能ディスク)

  • インスタンスは [実行中] 状態である必要があります。

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

  • 廃止されたインスタンスタイプ を使用していてはなりません。

Serverless インスタンスはコンソールでの直接アップグレードをサポートしていません。方法 2 を使用してください。

アップグレード前の構成問題の修正

インスタンスが方法 1 の対象であるものの、まだすべての要件を満たしていない場合は、まず次の問題を解決してください。

問題 解決策
インスタンスが [実行中] 状態ではない (例:[再起動中])。 現在のタスクが完了するのを待ってからアップグレードしてください。
高性能ローカルディスクを持つ High-availability Edition インスタンスのテーブル数が 100 万を超えている。 アップグレード前に冗長なテーブルを削除してください。
一部のデータベースまたはテーブルが InnoDB 以外のストレージエンジンを使用している。 ALTER TABLE <table_name> ENGINE=InnoDB; を実行してテーブルを変換してください。
インスタンスが 廃止されたインスタンスタイプ を使用している。 アップグレード前にインスタンスタイプを変更してください。詳細については、「インスタンス構成の変更」をご参照ください。
データベースプロキシのマイナーバージョンが 1.13.41 未満である。 データベースプロキシのマイナーエンジンバージョンをアップグレードしてください。詳細については、「データベースプロキシのマイナーエンジンバージョンのアップグレード」をご参照ください。
インスタンスのストレージタイプが標準 SSD である。 標準 SSD から ESSD にアップグレード し、その後データベースバージョンをアップグレードしてください。

方法 1:コンソールでのアップグレード

アップグレードの仕組み

アップグレードプロセスはディスクタイプによって異なります:

  • 高性能ローカルディスクインスタンス:システムはまずセカンダリノードをアップグレードし、次にプライマリ/セカンダリ スイッチオーバーを実行し、最後に元のプライマリノードをアップグレードします。約 15 秒のサービス中断が予想されます。

  • ESSD インスタンス:システムは新しいノードをプロビジョニングしてアップグレードし、その後接続を切り替えます。約 15 秒のサービス中断が予想されます。

追加の制約:

  • バージョンをまたいだスキップは不可:アップグレードは一度に 1 つのメジャーバージョンずつ進みます。たとえば、MySQL 5.6 から 8.0 にアップグレードするには、まず 5.7 にアップグレードし、次に 8.0 にアップグレードします。

  • ターゲットマイナーバージョン:インスタンスは、ターゲットメジャーバージョンで利用可能な最新のマイナーバージョンにアップグレードされます。

  • ダウングレード不可:コンソールからのダウングレードはサポートされていません。

  • バックアップの動作:アップグレード後、アップグレード前のバックアップセットを使用してインスタンスを新しいバージョンに復元することはできません。アップグレード後に作成されたバックアップセットのみを使用してください。

  • ロールバック (ESSD のみ):古いバージョンにロールバックするには、アップグレード前に作成されたクラウドディスクバックアップから復元します。これは、高性能ローカルディスクを持つインスタンスではサポートされていません。

アプリケーションへの影響を減らすために、オフピーク時間にアップグレードを実行してください。

前提条件

開始する前に:

  • アップグレードパスの機能の違いを確認してください (「付録:バージョンアップグレードリファレンス」を参照)。

  • ユーザー定義関数が 予約キーワード を使用していないことを確認してください。

  • 過去 7 日間に成功した完全データバックアップが存在することを確認してください。存在しない場合は、今すぐ作成してください。

  • 10 GB 以上の空きディスク領域があることを確認してください。

  • アプリケーションに自動再接続メカニズムがあることを確認するか、オフピーク時間にアップグレードをスケジュールしてください。スイッチオーバーの影響に関する詳細については、「インスタンススイッチオーバーの影響」をご参照ください。

  • カスタマイズされたインスタンスパラメータの変更記録をバックアップしてください。アップグレード後、古いバージョンの一部のパラメータは利用できなくなる可能性があります。

  • ローカルログの保持期間と最大ストレージ使用率を増やしてください。詳細については、「ローカルログポリシーの変更」をご参照ください。

5.6 から 5.7 への追加チェック

フルテキストインデックスのチェック:マイナーバージョンが 20221130 より前の RDS for MySQL 5.6 インスタンスでは、フルテキストインデックスはシステム表領域に保存されます。5.7 にアップグレードすると、表領域が破損する可能性があります。インスタンスが以前のマイナーバージョンを実行している場合は、まず最新の 5.6 マイナーバージョンにアップグレードしてから、メジャーバージョンのアップグレードに進んでください。「よくある質問」のフルテキストインデックスのトラブルシューティング手順も参照してください。

5.7 から 8.0 への追加チェック

MySQL 8.0 にアップグレードする前に、これらのチェックを実行してください:

  • 機能の互換性:ストアドプロシージャ、トリガー、ビュー、および関数が MySQL 8.0 で削除された機能 を使用していないことを確認してください。アップグレードする前に、互換性のない問題を解決してください。

  • システムテーブルの依存関係:アプリケーションが MySQL 5.7 のシステムテーブル (sysmysqlinformation_schemaperformance_schema) をクエリしているかどうかを確認してください。これらのテーブルの一部は 8.0 で削除、名前変更、またはスキーマ変更されています。

  • データ型の互換性:MySQL 8.0 は、特定の古いデータ型のサポートを廃止します。REPAIR TABLE を実行するか、論理エクスポートとインポートを実行して、互換性のない型を解決してください。詳細については、「アップグレードのためのインストールの準備」をご参照ください。

  • コメントの値:マイナーバージョン 20221231 以降では、loose_upgrade_clear_invalid_comment パラメータ (デフォルト:ON) が導入されています。有効にすると、テーブル、フィールド、およびインデックスのコメント内の文字化けがアップグレード中に自動的にクリアされます。続行する前に、comment の値に文字化けしたコンテンツがないか確認してください。

  • ストアドプロシージャ:アップグレード前に、ストアドプロシージャまたは関数内の文字化けを修正してください。

  • 古い時間データ型:いずれかのテーブルが MySQL 5.5 以前の時間データ型を使用している場合は、アップグレード前に再構築してください。以下を実行して、影響を受けるテーブルを特定します:

    -- 古い時間データ型を表示します。
    SET SESSION show_old_temporals = ON;
    
    -- 古い時間データ型を含むテーブルをクエリします。
    SELECT TABLE_NAME, COLUMN_NAME, COLUMN_TYPE
    FROM information_schema.columns
    WHERE COLUMN_TYPE IN (
      'time /* 5.5 binary format */ ',
      'timestamp /* 5.5 binary format */',
      'datetime /* 5.5 binary format */ '
    );

    テーブルを再構築するには:

    ALTER TABLE <table_name> FORCE;

アップグレード前のテスト

本番インスタンスをアップグレードする前に:

  • 構文テスト:ターゲットバージョンを実行する新しい RDS インスタンスを作成し、アプリケーションをテストして構文や機能の非互換性を検出します。

  • アップグレードシミュレーション:元のインスタンスをクローンし、クローンでアップグレードを実行します。本番インスタンスをアップグレードする前に、すべての機能が期待どおりに動作することを確認します。

アップグレード手順

アップグレードフローはシナリオによって異なります。次の表を使用して、適切な手順を見つけてください:

アップグレードフロー 適用シナリオ
事前チェック後、アップグレード

High-availability Edition (高性能ローカルディスク):5.6 から 5.7 または 5.7 から 8.0

High-availability Edition (ESSD または高性能ディスク) および Cluster Edition (ESSD または高性能ディスク):5.7 から 8.0

直接アップグレード

High-availability Edition (高性能ローカルディスク):5.5 から 5.6

Basic Edition (ESSD または高性能ディスク):5.7 から 8.0

事前チェック後、アップグレード

  1. インスタンス ページに移動します。上部のナビゲーションバーで、インスタンスが配置されているリージョンを選択します。インスタンス ID をクリックします。

  2. 左側のナビゲーションウィンドウで、[メジャーバージョンアップグレード] をクリックして [アップグレードチェック] ページを開きます。

  3. [アップグレードバージョンの選択] ドロップダウンリストから、ターゲットバージョンを選択します。[アップグレードチェックレポートの作成] をクリックします。レポートの解釈に関する詳細については、「メジャーバージョンアップグレードチェックレポートの説明」をご参照ください。

    image

  4. チェックがリスクなしで完了したら、[インスタンスのアップグレード] タブに切り替えます。

  5. [アップグレードバージョンの選択] ドロップダウンリストから、ターゲットバージョンを選択します。[インスタンスのアップグレード] をクリックします。

    image

  6. [メジャーエンジンバージョンアップグレード] ダイアログボックスで、ターゲットバージョンを確認し、[切り替え時間] を選択して、[アップグレード] をクリックします。

    image

直接アップグレード

  1. インスタンス ページに移動します。上部のナビゲーションバーで、インスタンスが配置されているリージョンを選択します。インスタンス ID をクリックします。

  2. [基本情報] > [設定情報] セクションで、[メジャーエンジンバージョンのアップグレード] をクリックします。

    このオプションが利用できない場合は、インスタンスがアップグレード要件を満たしていることを確認してください。

  3. ダイアログボックスで、切り替え時間を選択し、[はい] をクリックします。

    • [すぐに切り替え]:すぐにアップグレードを開始します。

    • [メンテナンスウィンドウ内で切り替え]:次の メンテナンスウィンドウ 中にアップグレードを開始します。[メンテナンスウィンドウ] の横にある [設定項目] をクリックしてウィンドウを調整します。

    アップグレード中、インスタンスステータスは [バージョン移行中] と表示されます。

方法 2:DTS 移行を使用したアップグレード

Serverless インスタンスや TDE が有効なインスタンスなど、直接アップグレードできないインスタンスの場合は、ターゲットバージョンを実行する新しいインスタンスをプロビジョニングし、Data Transmission Service (DTS) を使用して元のインスタンスからデータを移行します。

  1. ターゲットバージョンを実行する 新しい ApsaraDB RDS for MySQL インスタンスを作成 します。

  2. DTS データ移行タスクを使用して、新しいインスタンスにデータを移行 します。

  3. 移行が成功したことを確認した後、元のインスタンスをリリース します。

重要

メジャーバージョン間で移行した後は、互換性テストを実行し、元のインスタンスをリリースする前に新しいインスタンスを監視してください。

例: TDE が有効な MySQL 5.7 インスタンスは直接アップグレードできません。新しい MySQL 8.0 インスタンスを作成し、DTS を使用してデータを移行し、移行を検証してから、5.7 インスタンスをリリースします。

よくある質問

アップグレード中になぜインスタンスのスイッチオーバーが発生するのですか?

リスクを最小限に抑えるため、アップグレードは段階的なアプローチに従います。高性能ローカルディスクを持つインスタンスの場合、まずセカンダリノードがアップグレードされ、次にスイッチオーバーが発生します。ESSD インスタンスの場合、新しいノードがプロビジョニングされてアップグレードされ、その後接続が切り替えられます。どちらの場合も、中断は約 15 秒です。スイッチオーバーの影響に関する詳細については、「プライマリ/セカンダリフェイルオーバーの影響」をご参照ください。

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

いいえ。高性能ローカルディスクを持つインスタンスの場合、まずセカンダリノードがアップグレードされ、スイッチオーバー後にプライマリノードがアップグレードされます。

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

まず ストレージタイプを標準 SSD から ESSD にアップグレード し、その後データベースバージョンをアップグレードします。

アップグレード後、パラメータテンプレートは保持されますか?

テンプレートの種類によって異なります。システムパラメータテンプレートは、新しいバージョンに対応するテンプレートに自動的に切り替わります。たとえば、5.7 から 8.0 へのアップグレード後、MySQL_InnoDB_5.7_High-availability_PerformanceMySQL_InnoDB_8.0_High-availability_Performance になります。カスタムパラメータテンプレートは保持されません。

アップグレード中にインスタンスで他の操作を実行できますか?

いいえ。他の操作はアップグレードが完了した後にのみ利用可能です。

メジャーバージョンのアップグレードは自動的に実行されますか?

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

バージョンをダウングレードできますか?

コンソールからの直接ダウングレードはサポートされていません。以前のバージョンを実行している インスタンスを購入 し、DTS を使用して新しいバージョンのインスタンスからデータを移行し、移行を検証した後に新しいバージョンのインスタンスをリリースしてください。詳細については、「RDS インスタンス間のデータ移行」をご参照ください。

読み取り専用インスタンスが存在する場合でも、接続中断は常に 15 秒ですか?

はい。読み取り専用インスタンスがアタッチされているかどうかに関係なく、15 秒の中断が適用されます。オフピーク時間にアップグレードを実行してください。

5.6 から 5.7 (または 5.7 から 8.0) へのアップグレードがフルテキストインデックスエラーで失敗します。どうすれば修正できますか?

これは、古い RDS for MySQL 5.6 インスタンス (マイナーバージョンが 20221130 より前) のフルテキストインデックスがシステム表領域に保存されているために発生します。この構成からアップグレードすると、表領域が破損する可能性があります。

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

解決するには:

  1. エラーメッセージで特定されたフルテキストインデックスを削除します:

    ALTER TABLE $table_name DROP INDEX $fts_name;
  2. フルテキストインデックスを再作成します:

    ALTER TABLE $table_name ADD FULLTEXT INDEX $fts_name;
  3. システム表領域にフルテキストインデックスが残っていないことを確認します:

    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
    );

    空の結果は、この問題なしでアップグレードを続行できることを意味します。

重要

5.7 にアップグレードする前に、インスタンスが RDS for MySQL 5.6 バージョン 20221130 以降を実行していることを確認してください。そうでない場合は、まずマイナーバージョンをアップグレードしてください。

5.7 から 8.0 にアップグレードした後、エラー 267「Illegal mix of collations」が表示されます。どうすれば修正できますか?

これは、MySQL 8.0 が utf8mb4 のデフォルトの照合順序を utf8mb4_general_ci (5.7 で使用) から 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 から 8.0 へのアップグレードのメリット

  • アカウント管理の柔軟性が向上し、セキュリティが強化されました。

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

  • InnoDB ストレージエンジンの機能が強化されました。

  • 新しい文字セット、データ型、構文、バックアップロック、および optimizer_switch フラグ。

  • JSON および XML 機能が強化されました。

  • オプティマイザーとレプリケーションのパフォーマンスが向上しました。

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

  • MySQL 権限付与テーブルの読み取りとリソース割り当て制御をサポートします。

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

  • パスワード管理、アカウントロック、暗号化接続などのセキュリティ機能が向上しました。

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

  • InnoDB のスケーラビリティが向上し、一時テーブルのパフォーマンスが高速化しました。

  • ネイティブ JSON をサポートします。

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

  • パーサ、オプティマイザー、コストモデルが改善されました。

  • GB18030 国家標準を含む、文字セットのサポートが拡張されました。

  • 中国語、日本語、韓国語向けの ngram フルテキストパーサープラグイン。

  • ソースダンプスレッドが最適化され、スループットが向上し、レプリケーションの遅延が減少しました。

  • 監視メトリクス用の sys システムデータベース。

MySQL 5.7 と 8.0 の機能の違い

次の表は、選択された違いをリストしています。完全なリストについては、「MySQL リリースノート」をご参照ください。
機能 MySQL 5.7 MySQL 8.0
GRANT ... IDENTIFIED BY PASSWORD 構文 サポートされています サポートされていません
PASSWORD() 関数 サポートされています サポートされていません
FLUSH QUERY CACHE および RESET QUERY CACHE 構文 サポートされています サポートされていません
SQL_MODE パラメーター: DB2MAXDBMSSQLMYSQL323MYSQL40ORACLEPOSTGRESQLNO_FIELD_OPTIONSNO_KEY_OPTIONSNO_TABLE_OPTIONS サポートされています サポートされていません
GROUP BY サポートされています サポートされていません
EXTENDED または PARTITIONS 構文内のキーワード サポートされています サポートされていません
暗号化関数: ENCODE()DECODE()ENCRYPT() サポートされています サポートされていません
空間分析関数 サポートされています サポートされていません
WKB 文字列引数を受け入れるがジオメトリ引数を受け入れない関数 サポートされています サポートされていません
\NNULL サポートされています サポートされていません
PROCEDURE ANALYSE() 関数 サポートされています サポートされていません
NDB ストレージエンジンを使用するパーティションテーブル サポートされています サポートされていません
InnoDB を使用した一時テーブルの圧縮 サポートされています サポートされていません
JSON_APPEND() 関数 サポートされています サポートされていません
共有表領域内のテーブルパーティション サポートされています サポートされていません
ALTER TABLE ... UPGRADE PARTITIONING 構文 サポートされています サポートされていません

MySQL 5.6 と 5.7 の機能の違い

次の表は、選択された違いをリストしています。完全なリストについては、「MySQL リリースノート」をご参照ください。
特徴 MySQL 5.6 MySQL 5.7
CREATE...AS SELECT GTID モードで サポート 非サポート
GTID モードでのトランザクション内の一時テーブル サポート 非サポート
パーティションテーブルでのパーティションキーの指定 サポート 非サポート
ENGINE_NO_CACHE 構文 サポート 非サポート
不可視インデックス サポート 非サポート
UPDATE non_affected_rows INSERT 構文 サポート 非サポート
プロキシ関連コマンド SET コマンドを使用 CALL PROCEDURE
TokuDB、Sphinx、RocksDB、および Memory エンジン サポート 非サポート
str_ord() 関数 サポート 非サポート
raiseerror() 関数 サポート 非サポート
OPTIMIZE TABLE table ASYNC サポート 非サポート
INFORMATION.TABLE_UTILIZATION テーブル サポート 非サポート
INFORMATION_SCHEMA.INNODB_LOCK_WAITSrequesting_thd_id および blocking_thd_id サポート 非サポート
INFORMATION_SCHEMA.INNODB_RSEG テーブル サポート 非サポート
INFORMATION_SCHEMA.INNODB_IO_STATUS テーブル サポート 非サポート
列の圧縮 サポート 非サポート
クエリプランキャッシュ サポート 非サポート
LIMIT + UNION 構文 括弧は不要 括弧が必要
SHOW FULL PROCESSLIST memory および query_memory 列が削除
max_statement_time / max_execution_time 両方サポート max_statement_time は削除され、max_execution_time のみ保持
RDS_SQL_MAX_AFFECTED 構文 サポート 削除されました。代わりに rds_sql_max_affected_rows を使用してください
同時実行制御パラメータ innodb_adaptive_tickets_algo, innodb_min_concurrency_tickets, rds_threads_running_ctl_mode, rds_threads_running_high_watermark, rds_filter_key_cmp_in_order, rds_reset_all_filter, rds_sql_delete_filter, rds_sql_select_filter, rds_sql_update_filter, rds_strict_concurrency, rds_thread_extra_concurrency, rds_strict_trx_idle_timeout, rds_sql_buf_read_bandwidth, rds_sql_buf_read_threshold_bytes, rds_sql_buf_write_bandwidth, rds_sql_buf_write_threshold_bytes, rds_sql_max_iops 削除
接続数変数 extra_max_connections, rds_root_connections, rds_sysinfo_connections, rds_sysinfo_user_list 削除
GTID 有効および非 GTID レプリケーション サポート 非サポート
sql_slave_skip_counter と GTIDs サポート 非サポート
CREATE...SELECT レプリケーションにおける サポート 非サポート
SHOW SLAVE LAG サポート 非サポート
SHOW SLAVE STATUS タイムアウト サポート 非サポート
SHOW SLAVE STATUS 出力 完全な情報 情報が減少
sql_thread 実行タイムアウト サポート 非サポート
sql_thread ステートメントのスキップ サポート 非サポート
バイナリログ転送速度の調整 サポート 非サポート
rds_rpl_receive_buffer_difftime サポート 非サポート
rds_rpl_receive_buffer_size サポート 非サポート
ログ関連の調整 MySQL 5.7 のエラーログは、SHUTDOWN の IP アドレス、ユーザー、I/O またはネットワーク遅延を記録しなくなりました。重複キーのテーブル名を表示することはサポートされなくなりました。
旧時刻データ型 (5.6.4 より前の TIMEDATETIMETIMESTAMP) マイクロ秒のサポートなし マイクロ秒の精度をサポート。古いフォーマットのテーブルはアップグレード中に再構築され、プロセスが遅くなる可能性があります

MySQL 5.5 と 5.6 の機能の違い

次の表は、選択された違いをリストしています。完全なリストについては、「MySQL 5.6 リファレンスマニュアル」をご参照ください。
特徴 MySQL 5.5 MySQL 5.6
フルテキストインデックス 非サポート サポート
InnoDB オンライン DDL 非サポート 部分的にサポート
REDO ログサイズ制限 4 GB 512 GB
ダーティページのフラッシュ シングルスレッド 専用フラッシング スレッド
パージ シングルスレッド マルチスレッド
EXCHANGE PARTITION 非サポート サポート
DML での明示的なパーティション選択 非サポート サポート
INFORMATION_SCHEMA より多くのバッファープール情報、テーブル、インデックス、フィールドのより多くのメタデータ
PERFORMANCE_SCHEMA より多くの監視情報と表示フォーマット
レプリケーション GTID ベースのレプリケーション、マルチスレッドのセカンダリアプライ、FLUSH MASTER/FLUSH SLAVERESET MASTER/RESET SLAVE に名前が変更されました。SLAVE START/SLAVE STOPSTART SLAVE/STOP SLAVE に名前が変更されました。
重要

5.5 から 5.6 にアップグレードした後、インスタンスは自動的に GTID ベースのレプリケーションに切り替わります。

オプティマイザー マルチレンジリード、インデックス条件プッシュダウン (ICP)、Optimizer_trace サポート
大きなファイルの非同期パージ 非サポート サポート
スレッドプール 非サポート サポート
パフォーマンスエージェント 非サポート サポート
高速 DDL 非サポート サポート
シーケンスエンジン 非サポート サポート

API リファレンス

API オペレーション 説明
RDS MySQL データベースのメジャーバージョンのアップグレード RDS インスタンスのデータベースのメジャーバージョンをアップグレードします。

次のステップ