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

RDS エディション

ApsaraDB RDS for SQL Server には、可用性アーキテクチャが異なる 3 つのエディションがあります。

• RDS Basic Edition：ホットスタンバイのない単一のプライマリインスタンスです。仕様変更やバージョンアップグレードにより、長時間のダウンタイムが発生します。

• RDS High-availability Edition：準同期または非同期レプリケーションによるプライマリインスタンスとセカンダリインスタンスで構成されます。プライマリに障害が発生した場合、自動フェールオーバーが行われます。

• RDS Cluster Edition：コンピュートとストレージが分離された Always On アーキテクチャです。読み取り専用インスタンスを 1 つ以上サポートし、読み書き分離を実現します。

利用できる機能は、SQL Server のバージョンと RDS エディションの両方によって異なります。詳細な比較については、「SQL Server のバージョンと RDS エディション別の機能」をご参照ください。

制限事項

以下のインスタンスタイプはアップグレードできません：

• Active Directory (AD) ドメインに参加しているインスタンス。詳細については、「RDS SQL Server インスタンスを自己管理ドメインに参加させる」をご参照ください。

• サーバーレスインスタンス。詳細については、「概要」をご参照ください。

• クラシックネットワーク上のインスタンス。詳細については、「ネットワークタイプの変更」をご参照ください。

• 読み取り専用インスタンス。

• 読み取り専用インスタンスを持ち、RDS Cluster Edition で実行されているプライマリインスタンス。詳細については、「読み取り専用の ApsaraDB RDS for SQL Server インスタンスの作成」をご参照ください。

アップグレードの影響

何が変更され、何が変更されないかを理解し、アップグレードウィンドウを計画してください。

変更される点：

• インスタンスの仮想 IP アドレス (VIP) が変更されます。VIP の変更を透過的に処理するために、アプリケーションの接続文字列には IP アドレスではなくインスタンスエンドポイントを使用してください。

• ワークロードの切り替え中に約 20 分のダウンタイムが発生します。アプリケーションが自動的に再接続するように設定されていることを確認してください。

• アップグレード後、データベースクライアントのキャッシュされた DNS レコードをフラッシュしてください。JVM ベースのアプリケーションの場合、$JAVA_HOME/jre/lib/security/java.security で networkaddress.cache.ttl を 60 秒以下に設定するか、最初の InetAddress.getByName() 呼び出しの前にアプリケーションの初期化コードで以下のように設定します：

  java.security.Security.setProperty("networkaddress.cache.ttl", "60");

• アクティブな Data Transmission Service (DTS) タスクはアップグレード中に停止します。アップグレード後に再設定して再起動してください。詳細については、「Data Transmission Service とは」をご参照ください。

変更されない点：

• インスタンス名、接続ポート、タグ、データベースアカウントは変更されません。

その他の注意点：

• 一度開始したアップグレードはキャンセルできません。

• アップグレードにかかる時間はデータ量によって異なります。詳細については、「推定所要時間」をご参照ください。

前提条件

開始する前に、以下が揃っていることを確認してください：

• ApsaraDB RDS for SQL Server インスタンス

• (推奨) アップグレード前にアプリケーションの互換性をテストするための、ターゲット仕様を持つ従量課金またはサーバーレスの RDS インスタンス

インスタンスのアップグレード

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

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

   [バージョンのアップグレード] が表示されない場合は、インスタンスが「制限事項」に記載されているアップグレード要件を満たしているか確認してください。

   

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

   インスタンスの現在の構成によっては、一部のメジャーエンジンバージョンと RDS エディションが利用できない場合があります。「アップグレードルール」および「制限事項」をご参照ください。

   パラメーター	説明
   アップグレード先	ターゲットのメジャーエンジンバージョンです。[エディション] と [インスタンスタイプ] で利用可能なオプションは、この選択によって決まります。「アップグレードルール」をご参照ください。
   エディション	ターゲットの RDS エディション。 Basic Edition: 単一のプライマリインスタンス構成です。コンピューティングとストレージは分離されています。 High-availability Edition: プライマリインスタンスとセカンダリインスタンスによる高可用性構成です。 Cluster Edition: プライマリインスタンスとセカンダリインスタンスによる高可用性構成です。セカンダリインスタンスは読み取り可能です。 完全な比較については、「概要」をご参照ください。
   インスタンスタイプ	各インスタンスタイプは、CPU コア数、メモリ容量、最大接続数、最大 IOPS を指定します。
   切り替え時間	[データ移行後すぐに切り替え]：データ移行が完了するとすぐにワークロードが切り替わります。[メンテナンスウィンドウ内で切り替え]：次回のスケジュールされたメンテナンスウィンドウ中にワークロードが切り替わります。

4. 利用規約を読み、同意した後、[注文を確定] をクリックします。

インスタンスステータスは Upgrading Version に変わります。[実行中] に戻ると、アップグレードが完了します。

推定所要時間

アップグレードの総所要時間は、データ量と、過去 36 時間以内に完全バックアップが取得されたかどうかによって異なります。

SQL Server Web インスタンスはバックアップ圧縮をサポートしていません。バックアップと復元の速度は、1 時間あたり 100 GB 未満になる場合があります。

バックアップ速度は、リージョンや時間帯によって異なる場合があります。バックアップと復元のパフォーマンスに関するより正確な情報を得るには、前回のアップグレードのデータ量と時間をご参照ください。

例：4 CPU コア、8 GB メモリ、600 GB のデータを持つインスタンスの場合：

• 過去 36 時間以内に完全バックアップが取得されていない場合：合計約 6 時間 34 分

• 過去 36 時間以内に完全バックアップが取得されている場合：合計約 3 時間 34 分

アップグレードの総所要時間を短縮するには、アップグレードを開始する前、またはタスクを開始する 36 時間以内に完全バックアップを取得してください。詳細については、「ApsaraDB RDS for SQL Server インスタンスのバックアップ」をご参照ください。

増分トランザクションログの適用は、リソースを大量に消費します。small インスタンス（例：2 CPU コアおよび 4 GB のメモリ）では、トランザクションログの量が多いと復元速度が低下する可能性があります。SQL Server 2019 以降では、Accelerated Database Recovery オプションを有効化することで、データベースの復元時間を短縮できます。このオプションについては、Microsoft の公式ドキュメント をご参照ください。

ベストプラクティス

オフピーク時にスケジュールする。影響を最小限に抑えるため、トランザクション量が少ない時間帯にアップグレードを実施してください。

長時間実行トランザクションを避ける。アップグレード中にインデックスの作成、インデックスの再構築、データアーカイブなどの操作を実行しないでください。これらの操作は大規模なトランザクションログを生成し、データベースの復元フェーズを大幅に延長させる可能性があります。

よくある質問

課金

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

API リファレンス

API を介してアップグレードするには、ModifyDBInstanceSpec を使用します。