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

ApsaraDB RDS:メジャーエンジンバージョンのアップグレード

最終更新日:Apr 03, 2025

RDS エディションごとに異なる SQL Server バージョンで提供される機能は異なります。パフォーマンスの向上と機能の拡張を実現するために、ビジネス要件に基づいて ApsaraDB RDS for SQL Server インスタンスのメジャーエンジンバージョンと RDS エディションをアップグレードできます。たとえば、RDS インスタンスのメジャーエンジンバージョンを SQL Server 2019 SE から SQL Server 2022 SE にアップグレードし、RDS エディションを RDS Basic Edition から RDS High-availability Edition にアップグレードできます。

背景情報

ApsaraDB RDS for SQL Server には、それぞれ異なる機能と性能を提供する 3 つのエディションがあります。各 RDS エディションの異なる SQL Server バージョンで提供される機能はさまざまです。

  • RDS Basic Edition では、RDS インスタンスにはホットスタンバイとしてセカンダリ RDS インスタンスがありません。RDS インスタンスが予期せず存在する場合、または RDS インスタンスの仕様の変更やメジャーエンジンバージョンのアップグレードなどの操作を実行すると、データベースサービスが長期間利用できなくなります。

  • RDS High-availability Edition では、プライマリ RDS インスタンスとセカンダリ RDS インスタンスで構成される HA アーキテクチャが採用されています。プライマリ RDS インスタンスのデータは、セミ同期または非同期モードでセカンダリ RDS インスタンスに同期されます。プライマリ RDS インスタンスに障害が発生した場合、ワークロードは自動的にセカンダリ RDS インスタンスにスイッチオーバーされます。

  • RDS Cluster Edition は、ネイティブ SQL Server の Always On アーキテクチャを使用し、コンピューティングとストレージの分離をサポートしています。RDS Cluster Edition では、1 つ以上の読み取り専用 RDS インスタンスを作成して読み書き分離を実装できます。この方法で、RDS を使用して大量の読み取りリクエストを処理できます。

注意事項

  • アップグレード後、RDS インスタンスのメジャーエンジンバージョン、RDS エディション、またはインスタンスタイプを元の構成にロールバックすることはできません。次の表に、アップグレードルールを示します。

    アップグレードルール

    項目

    アップグレードルール

    メジャーエンジンバージョン

    • SQL Server SE バージョンから SQL Server EE バージョンへのアップグレード

    • SQL Server SE バージョンから SQL Server EE (Always On) バージョンへのアップグレード

    • SQL Server Web バージョンから SQL Server SE バージョンへのアップグレード

    • SQL Server Web バージョンから SQL Server EE バージョンへのアップグレード

    • SQL Server Web バージョンから SQL Server EE (Always On) バージョンへのアップグレード

    説明

    RDS インスタンスで SQL Server Web バージョンを実行している場合は、SQL Server Web バージョンを SQL Server SE バージョンにアップグレードしてから、SQL Server EE バージョンまたは SQL Server EE (Always On) バージョンにアップグレードする必要があります。

    RDS エディション

    • RDS Basic Edition から RDS High-availability Edition へのアップグレード

    • RDS Basic Edition から RDS Cluster Edition へのアップグレード

    • RDS High-availability Edition から RDS Cluster Edition へのアップグレード

    インスタンスタイプ

    • 共有インスタンスタイプから汎用インスタンスタイプへのアップグレード

    • 共有インスタンスタイプから専用インスタンスタイプへのアップグレード

    • 汎用インスタンスタイプから専用インスタンスタイプへのアップグレード

    説明
    • RDS インスタンスが RDS High-availability Edition を実行し、共有インスタンスタイプを使用している場合、RDS Cluster Edition の専用インスタンスタイプに直接アップグレードすることはできません。

    • RDS インスタンスは、同じ仕様またはより高い仕様を提供するインスタンスタイプにのみアップグレードできます。より高い仕様を提供するインスタンスタイプへのアップグレードルールについては、前のセクションを参照してください。

    • 共有インスタンスタイプから別の共有インスタンスタイプに RDS インスタンスを直接アップグレードすることはできません。

    警告

    アップグレードを実行する前に、必要な仕様の従量課金制またはサーバーレス RDS インスタンスを購入することをお勧めします。この方法で、新しい RDS インスタンスを使用してワークロードとの互換性をテストできます。詳細については、「ApsaraDB RDS for SQL Server インスタンスの作成」をご参照ください。

  • メジャーエンジンバージョンのアップグレード中は、RDS インスタンスのメタデータを変更しないことをお勧めします。変更すると、アップグレード後にデータの不整合の問題が発生する可能性があります。たとえば、データベースの作成、データベースの削除、データベースの復元モードの変更などは行わないことをお勧めします。

制限事項

次の RDS インスタンスのメジャーエンジンバージョンはアップグレードできません。

影響

  • RDS インスタンスでアップグレードタスクを開始した場合、アップグレードタスクをキャンセルすることはできません。アップグレードが完了した後、RDS インスタンスを以前のメジャーエンジンバージョンにロールバックすることはできません。

  • インスタンス名、ポート、タグ、データベースアカウントなど、RDS インスタンスの設定は、アップグレード後も変更されません。

  • アップグレードの完了に必要な時間は、RDS インスタンスのデータ量によって異なります。詳細については、「FAQ」をご参照ください。

  • ほとんどの場合、アップグレードにはワークロードのスイッチオーバーが必要であり、RDS インスタンスが約 20 分間利用できなくなる可能性があります。アプリケーションが RDS インスタンスに自動的に再接続するように構成されていることを確認してください。詳細については、「FAQ」をご参照ください。

  • アップグレードにより、RDS インスタンスの仮想 IP アドレス (VIP) が変更されます。アプリケーションをインスタンスに接続するには、IP アドレスではなく RDS インスタンスのエンドポイントを使用することをお勧めします。

  • アップグレード後、データベースクライアントからキャッシュされた DNS レコードをすぐに削除することをお勧めします。データベースクライアントが Java 仮想マシン (JVM) で実行されている場合は、JVM 構成の Time To Live (TTL) を 60 秒以下に設定することをお勧めします。こうすることで、RDS インスタンスの使用中のエンドポイントにバインドされている VIP が変更された場合、アプリケーションは関連する DNS レコードをクエリして新しい VIP を取得できます。その後、アプリケーションは新しい VIP に接続できます。

    説明

    TTL 設定方法については、以下をご参照ください。

    • すべての JVM ベースのアプリケーションの場合、$JAVA_HOME/jre/lib/security/java.security ファイルの networkaddress.cache.ttl パラメーターを 60 に設定します。

    • ローカルアプリケーションの場合、ローカルアプリケーションの初期化コードで networkaddress.cache.ttl java.security.Security.setProperty("networkaddress.cache.ttl" , "60"); 設定を行います。この設定は、ネットワーク接続を確立するために InetAddress.getByName() 関数を初めて呼び出す前に完了する必要があります。

  • RDS インスタンスで Data Transmission Service (DTS) タスクが実行中の場合、アップグレードの完了後に DTS タスクを再構成して開始する必要があります。詳細については、「DTS とは」をご参照ください。

課金ルール

アップグレードの料金については、「インスタンス仕様の変更」をご参照ください。

手順

  1. インスタンス ページに移動します。上部のナビゲーションバーで、RDS インスタンスが存在するリージョンを選択します。次に、RDS インスタンスを見つけて、インスタンスの ID をクリックします。

  2. 基本情報 ページの 設定情報 セクションで、バージョンのアップグレード をクリックします。表示されるダイアログボックスで、[OK] をクリックします。

    説明

    [バージョンのアップグレード] が表示されない場合は、RDS インスタンスがアップグレード要件を満たしているかどうかを確認する必要があります。

    image.png

  3. エンジンバージョンのアップグレード ページで、次のパラメーターを構成します。その他のパラメーター設定の詳細については、「手順」をご参照ください。

    説明

    一部の RDS インスタンスのメジャーエンジンバージョンをアップグレードする場合、一部のメジャーエンジンバージョンと RDS エディションが使用できない場合があります。詳細については、このトピックの「注意事項」セクションと「制限事項」セクションを参照してください。

    パラメーター

    説明

    ターゲットバージョン

    アップグレード先のメジャーエンジンバージョンを選択します。エディション パラメーターと インスタンスタイプ パラメーターのオプションは、このパラメーターの値によって異なります。詳細については、「アップグレードルール」をご参照ください。

    エディション

    アップグレード先の RDS エディションを選択します。

    • Basic Edition: データベースシステムはプライマリ RDS インスタンスのみで構成されます。コンピューティングはストレージから分離されています。

    • 高可用性エディション: データベースシステムは、プライマリ RDS インスタンスとセカンダリ RDS インスタンスで構成されます。これらのインスタンスは高可用性モードで動作し、あらゆる面でバランスの取れたパフォーマンスを実現します。

    • Cluster Edition: データベースシステムは、プライマリ RDS インスタンスと複数のセカンダリ RDS インスタンスで構成されます。これらのインスタンスは高可用性モードで動作します。セカンダリ RDS インスタンスにはアクセスできます。

    説明

    RDS エディションの詳細については、「概要」をご参照ください。

    インスタンスタイプ

    各インスタンスタイプは、指定された数のコア、メモリ容量、最大接続数、および最大 IOPS をサポートしています。

    切り替え時間

    • データ移行直後の切り替え: 移行が完了すると、ワークロードはすぐにスイッチオーバーされます。

    • メンテナンス期間内に切り替え: 移行が完了すると、指定されたメンテナンスウィンドウ中にワークロードがスイッチオーバーされます。

  4. 利用規約を読み、選択して、[今すぐ支払う] をクリックします。

  5. 表示されるメッセージで、[同意して注文する] をクリックします。

    元の RDS インスタンスのステータスが [アップグレード中/ダウングレード中] > [ネットワーク間でアップグレード中] に変わります。元の RDS インスタンスのステータスが [実行中] に変わると、アップグレードは完了です。アップグレードの完了に必要な時間は、データ量によって異なります。

FAQ

RDS インスタンスのメジャーエンジンバージョンのアップグレード中に、RDS インスタンスのインスタンスタイプなどの構成を変更できますか?

いいえ、RDS インスタンスのメジャーエンジンバージョンのアップグレード中に、RDS インスタンスの仕様などの構成を変更することはできません。構成は、メジャーエンジンバージョンがアップグレードされた後にのみ変更できます。

RDS インスタンスのメジャーエンジンバージョンは自動的にアップグレードされますか?

いいえ、RDS インスタンスのメジャーエンジンバージョンは自動的にアップグレードされません。

メジャーエンジンバージョンのアップグレードにはどのくらいの時間がかかりますか?

推定時間

次の表に、インスタンスのメジャーエンジンバージョンのアップグレードに必要な推定時間を示します。データのバックアップと復元の速度は、非圧縮データのサイズに基づいて推定されます。

説明

SQL Server Web を実行する RDS インスタンスでは、バックアップ圧縮はサポートされていません。これにより、データのバックアップと復元の速度が 1 時間あたり 100 GB 未満に低下する可能性があります。

操作

必須

推定時間

説明

RDS インスタンスの作成と構成

はい

10 ~ 15 分

必要な時間は、必要なメジャーエンジンバージョンを実行する新しい RDS インスタンスの RDS エディションとインスタンスタイプによって異なります。

フルデータのバックアップ

オプション

200 GB/時

  • RDS インスタンスで 36 時間以内に完全バックアップが実行されていない場合、増分トランザクションログバックアップと完全バックアップからのデータ復旧に必要な時間を調整するために、アップグレードプロセス中に完全バックアップが実行されます。

    メジャーエンジンバージョンのアップグレード前に完全バックアップを実行するか、システムが完全バックアップを完了してから 36 時間以内に復旧タスクを開始することをお勧めします。 これにより、アップグレードに必要な合計時間が短縮されます。 詳細については、「ApsaraDB RDS for SQL Server インスタンスをバックアップする」をご参照ください。

  • バックアップ速度は、リージョンと期間によって異なる場合があります。

  • バックアップと復旧のパフォーマンスに関するより正確な情報を取得するには、前回のアップグレードのデータ量と時間をご参照ください。

宛先 RDS インスタンスへの完全バックアップの復元

はい

1 時間あたり 200 GB

なし。

ソース RDS インスタンスでの増分トランザクションログのバックアップ

はい

1 時間あたり 200 GB

増分ログバックアップの前後には、バックアップの準備、クローズ、リソース割り当てなどの操作を実行するためにさらに 2 分かかる場合があります。

宛先 RDS インスタンスへの増分トランザクションログバックアップファイルの適用

はい

1 時間あたり 200 GB

増分ログバックアップの前後には、バックアップ整合性検証などの操作を実行するためにさらに 2 分かかる場合があります。

データベースの復元

はい

2 分以内

  • リソース消費: 増分トランザクションログの適用は、リソースを大量に消費する操作です。2 CPU コア、4 GB メモリなどの小規模な仕様の RDS インスタンスで大量のトランザクションログが生成された場合、データ復旧速度が低下します。

  • 高速データベース復旧オプション: 高速データベース復旧オプションは、SQL Server 2019 以降を実行する RDS インスタンスでサポートされています。これにより、データベースの復旧時間が短縮されます。Microsoft 公式ドキュメントに基づいて、このオプションを有効にするかどうかを評価できます。

新しい RDS インスタンスへのワークロードの切り替えとネットワーク接続の移行

はい

10 分

なし。

テストインスタンス: RDS インスタンスには 4 CPU コアと 8 GB のメモリがあり、RDS インスタンスのデータ量は 600 GB です。

  • RDS インスタンスの作成と構成に必要な時間: 約 12 分。

  • 完全データのバックアップに必要な時間: 約 3 時間。必要な時間は、次の計算式を使用して計算されます。必要な時間 = 600 GB / 1 時間あたり 200 GB = 3 時間。

  • 宛先 RDS インスタンスへの完全バックアップの復元に必要な時間: 約 3 時間。必要な時間は、次の計算式を使用して計算されます。必要な時間 = 600 GB / 1 時間あたり 200 GB = 3 時間。

  • ソース RDS インスタンスでの増分トランザクションログのバックアップに必要な時間: 約 5 分。必要な時間は、次の計算式を使用して計算されます。必要な時間 = 10 GB / 1 時間あたり 200 GB + 2 分の損失時間 = 5 分。

  • 宛先 RDS インスタンスへの増分トランザクションログバックアップファイルの適用に必要な時間: 約 5 分。必要な時間は、次の計算式を使用して計算されます。必要な時間 = 10 GB / 1 時間あたり 200 GB + 2 分の損失時間 = 5 分。

  • データベースの復元に必要な時間: 2 分以内

  • 新しい RDS インスタンスへのワークロードの切り替えとネットワーク接続の移行に必要な時間: 約 10 分。

この例では、36 時間以内に RDS インスタンスで完全バックアップが実行されていない場合、合計所要時間は約 6 時間 34 分と推定されます。36 時間以内に RDS インスタンスで完全バックアップが実行された場合、所要時間は約 3 時間 34 分と推定されます。

アップグレードの推奨事項

  • メンテナンスウィンドウ: ワークロードへの影響を最小限に抑えるために、オフピーク時にメジャーエンジンバージョンをアップグレードすることをお勧めします。

  • 長時間トランザクション: アップグレード中は、インデックスの作成や再構築、データのアーカイブなど、長時間トランザクションを実行しないことをお勧めします。これは、データベースの復元に必要な時間が長引くのを防ぐのに役立ちます。

タイムゾーンをまたいで RDS インスタンスのメジャーエンジンバージョンをアップグレードする場合、切り替え時間をどのように構成すればよいですか?

  • シナリオ: UAE (ドバイ) リージョンに居住し、シンガポールリージョンにある RDS インスタンスにインド標準時 (IST、UTC+5:30) を使用しています。タイムゾーンは湾岸標準時 (GST、UTC+4) です。この場合、サービス中断を回避するために、RDS インスタンスのメジャーエンジンバージョンをアップグレードする際の切り替え時間を決定することが重要です。

  • 目的: 2024 年 5 月 11 日 02:00 UTC+5:30 にアップグレードを実行する予定です。

  • 解決策: タイムゾーンを変換します。RDS インスタンスのタイムゾーンは UTC+5:30 です。タイムゾーンは UTC+4 で、これはブラウザのタイムゾーンでもあります。RDS インスタンスが存在するリージョンを考慮する必要はありません。この例では、2024 年 5 月 11 日 02:00 UTC+5:30 を 2024 年 5 月 11 日 00:30 UTC+4 に変換できます。ApsaraDB RDS コンソールにログインし、2024 年 5 月 11 日 00:30 に RDS インスタンスの切り替え時間を構成する必要があります。

  • タイムゾーンの変換方法については、次のリストを参照してください。

    1. IST 時刻 2024 年 5 月 11 日 02:00 を協定世界時 (UTC) 時刻に変換します。IST は UTC より 5 時間 30 分進んでいます。したがって、結果は 2024 年 5 月 10 日 20:30 UTC です。

    2. UTC 時刻 2024 年 5 月 10 日 20:30 を GST 時刻に変換します。UTC は GST より 4 時間遅れています。したがって、結果は 2024 年 5 月 11 日 00:30 GST です。

参考資料

API を使用してメジャーエンジンバージョンをアップグレードすることもできます。詳細については、「ModifyDBInstanceSpec」をご参照ください。