すべてのプロダクト
Search

このプロダクト

    ApsaraDB RDS:ApsaraDB RDS for PostgreSQL インスタンスのメジャーエンジンバージョンアップグレードとクロスバージョンアップグレード

    ドキュメントセンター

    ApsaraDB RDS:ApsaraDB RDS for PostgreSQL インスタンスのメジャーエンジンバージョンアップグレードとクロスバージョンアップグレード

    最終更新日:Mar 13, 2025

    PostgreSQL コミュニティは、PostgreSQL 9.4 や PostgreSQL 10 などの以前の PostgreSQL バージョンのメンテナンスを停止しました。以前の PostgreSQL バージョンを実行する RDS インスタンスを引き続き使用すると、潜在的なリスクが発生する可能性があります。RDS インスタンスで新しいバージョンを実行したり、新しいバージョンの新機能を使用したりする場合は、RDS インスタンスのメジャーエンジンバージョンをアップグレードすることをお勧めします。

    背景情報

    PostgreSQL コミュニティは、メジャーエンジンバージョンを定期的にリリースしています。新しいメジャーエンジンバージョンには、以前のメジャーエンジンバージョンと比較して、機能とパフォーマンスの面で改善が含まれています。 PostgreSQL コミュニティは、以前のメジャーエンジンバージョンへのテクニカルサポートを段階的に停止します。これにより、これらのバージョンのパフォーマンスリスクとセキュリティリスクの可能性が高まります。ApsaraDB RDS for PostgreSQL は、メジャーエンジンバージョンアップグレード機能を提供します。この機能を使用すると、新しいメジャーエンジンバージョンによって提供されるパフォーマンスと機能を利用し、アップグレードによって発生する可能性のあるリスクを軽減できます。

    アップグレード手順

    1. アップグレードチェックを実行します。

      元の RDS インスタンスがメジャーエンジンバージョンのアップグレードをサポートしているかどうかを確認します。次に、生成されたチェックレポートを表示します。アップグレードチェックレポートのチェック結果が「失敗」の場合、メジャーエンジンバージョンをアップグレードすることはできません。アップグレードチェックに合格した後にのみ、メジャーエンジンバージョンをアップグレードできます。

    2. オプション。互換性テストを実行します。

      RDS インスタンスのメジャーエンジンバージョンをアップグレードした後、新しいメジャーエンジンバージョンがワークロードと互換性がない場合があります。アップグレードを実行する前に、[カットなし] 構成方式を使用して別のインスタンスを作成し、新しいメジャーエンジンバージョンがワークロードと互換性があるかどうかをテストすることをお勧めします。

    3. メジャーエンジンバージョンをアップグレードします。

      元の RDS インスタンスのメジャーエンジンバージョンを再度アップグレードし、[カットオーバー] 構成方式を選択して、ワークロードを新しい RDS インスタンスに切り替えます。[カットオーバー] 構成方式を選択すると、ローカルアップグレードモードとブルーグリーンデプロイメントモードが提供されます。ビジネス要件に基づいてアップグレードモードを選択できます。

      • ローカルアップグレード: メジャーエンジンバージョンのアップグレードは元の RDS インスタンスで実行され、新しい RDS インスタンスは作成されません。アップグレード後、元の RDS インスタンスは新しいメジャーエンジンバージョンを実行し、元の注文、名前、タグ、CloudMonitor のアラート ルール、およびバックアップ設定を継承します。

      • ブルーグリーンデプロイメント: RDS インスタンスのメジャーエンジンバージョンがアップグレードされると、元の RDS インスタンスは保持され、新しい RDS インスタンスが作成されます。新しい RDS インスタンスの作成に対して料金は発生しません。新しい RDS インスタンスが作成された後、元の課金方法とは異なる可能性のある新しい課金方法に基づいて料金が発生します。アップグレードが完了すると、元の RDS インスタンスと新しい RDS インスタンスの両方に対して料金が発生します。また、新しい RDS インスタンスは、元の RDS インスタンスに提供される割引を利用できません。

        元の RDS インスタンスの課金方法

        新しい RDS インスタンスの課金方法

        サブスクリプションまたは従量課金

        従量課金

        サーバーレス

        サーバーレス

      説明

      RDS インスタンスで [ローカル ディスク] を使用している場合、メジャーエンジンバージョンのアップグレードでは [ブルーグリーンデプロイメント] モードのみがサポートされます。RDS インスタンスの [基本情報] ページに移動して、[ストレージ タイプ] を表示できます。

    カットオーバー構成方式とカットなし構成方式の説明

    メジャーエンジンバージョンをアップグレードする場合は、カットオーバー構成パラメーターを構成して、ワークロードを新しいメジャーエンジンバージョンを実行する RDS インスタンスに切り替えるかどうかを指定できます。

    構成方式

    説明

    影響

    カットなし

    システムは、アプリケーションの元の RDS インスタンスのエンドポイントを新しい RDS インスタンスのエンドポイントに自動的に変更しません。アップグレードを実行する前に、カットなし構成方式を選択して、新しいメジャーエンジンバージョンがワークロードと互換性があるかどうかをテストすることをお勧めします。新しいメジャーエンジンバージョンが互換性テストに合格した場合は、新しい RDS インスタンスをリリースできます。その後、[カットオーバー] 構成方式を選択してアップグレードを実行できます。詳細については、「ApsaraDB RDS for PostgreSQL インスタンスのリリースまたはサブスクライブ解除」をご参照ください。

    • データ移行は、元の RDS インスタンスのワークロードを中断しません。

    • [カットなし] 構成方式を選択した場合は、データが新しい RDS インスタンスに移行された後、アプリケーションの元の RDS インスタンスのエンドポイントを新しい RDS インスタンスのエンドポイントに変更する必要があります。 RDS インスタンスのエンドポイントを表示する方法の詳細については、「ApsaraDB RDS for PostgreSQL インスタンスのエンドポイントとポート番号の表示と変更」をご参照ください。

    • 元の RDS インスタンスに対して読み取り専用 RDS インスタンスが作成されている場合は、[カットなし] 構成方式を選択して、必要なメジャーエンジンバージョンを実行する RDS インスタンスを作成できます。ただし、元の読み取り専用 RDS インスタンスを複製することはできません。アップグレードが完了したら、新しい RDS インスタンスに対して読み取り専用 RDS インスタンスを作成する必要があります。詳細については、「読み取り専用 ApsaraDB RDS for PostgreSQL インスタンスの作成」をご参照ください。

    カットオーバー

    ブルーグリーンデプロイメント

    システムは、アプリケーションの元の RDS インスタンスのエンドポイントを新しい RDS インスタンスのエンドポイントに自動的に変更します。アプリケーションのエンドポイント構成を変更する必要はありません。この構成方式は、新しいメジャーエンジンバージョンがワークロードと互換性があることを確認した後にアップグレードを実行するために使用されます。

    • スイッチオーバーが完了すると、ワークロードを元の RDS インスタンスにロールバックすることはできません。注意して進めてください。

    • スイッチオーバー中、元の RDS インスタンスは読み取りリクエストのみを処理します。オフピーク時にスイッチオーバーを実行する必要があります。

    • ローカルアップグレードモードを選択した場合、アップグレードの前後に定期バックアップが実行されます。元の RDS インスタンスと同じ構成と元の RDS インスタンスのデータを持つ RDS インスタンスを使用する場合は、元の RDS インスタンスに対して作成された最新のバックアップ セットを使用して RDS インスタンスを複製できます。

    ローカルアップグレード

    ローカルアップグレードモードを使用する場合、元の RDS インスタンスのメジャーエンジンバージョンのみがアップグレードされ、新しい RDS インスタンスまたは注文は作成されません。アップグレード後、元の RDS インスタンスは新しいメジャーエンジンバージョンを実行し、元の構成を継承します。アプリケーションのエンドポイント構成を変更する必要はありません。この構成方式は、新しいメジャーエンジンバージョンがワークロードと互換性があることを確認した後にアップグレードを実行するために使用されます。

    ハイライト

    • クロスバージョンアップグレード: 元の RDS インスタンスのメジャーエンジンバージョンを新しいバージョンにアップグレードできます。たとえば、メジャーエンジンバージョンを PostgreSQL 10 から PostgreSQL 13 にアップグレードできます。

    • トライアルのスペックアップ: 切り取りなし 構成メソッドを使用して、元の RDS インスタンスのワークロードを中断することなく、スペックアップの実現可能性を検証できます。

    • スムーズなアップグレード:

      • アプリケーションの変更は不要: カットオーバー構成メソッドを使用して、スペックアップを実行できます。アプリケーションのエンドポイント構成を変更する必要はありません。ブルーグリーンデプロイメントモードを使用する場合、スイッチオーバーの完了後、システムは元の RDS インスタンスのエンドポイントを新しい RDS インスタンスのエンドポイントに自動的に変更します。ローカル スペックアップモードを使用する場合、元の RDS インスタンスのエンドポイントは変更されません。

        説明

        • ローカルアップグレードモードを使用する場合、RDS インスタンスの仮想 IP アドレス (VIP) は変更されません。

        • ブルーグリーンデプロイメントモードを使用する場合、新しい RDS インスタンスの VIP は元の RDS インスタンスの VIP とは異なります。アプリケーションで元の RDS インスタンスの VIP を構成している場合は、アプリケーション構成を変更する必要があります。アプリケーションでは、元の RDS インスタンスの VIP ではなくエンドポイントを構成することをお勧めします。詳細については、「エンドポイントとポート番号の表示と変更」をご参照ください。

      • ダウンタイムなし: アップグレードによって元の RDS インスタンスにダウンタイムが発生することはありません。これにより、サービス中断のリスクが軽減されます。ただし、アップグレード中は、元の RDS インスタンスは数分間読み取りリクエストのみを処理します。

      • 予約済みインスタンス構成:

        • 新しい RDS インスタンスは、元の RDS インスタンスの IP アドレス ホワイトリスト、パラメーター設定、および拡張機能を引き継ぎます。ただし、これは、新しいメジャーエンジンバージョンでサポートされていない拡張機能またはパラメーターには適用されません。

        • 元の RDS インスタンスが完全に暗号化されたデータベースをサポートしている場合、新しい RDS インスタンスも完全に暗号化されたデータベースをサポートし、元の RDS インスタンスで使用されているキーを引き継いでデータを暗号化します。詳細については、「ApsaraDB RDS for PostgreSQL インスタンスで完全に暗号化されたデータベースを作成する」をご参照ください。

    課金ルール

    • ローカルアップグレードでは、料金の変更や注文の生成は発生しません。

    • ブルーグリーンデプロイメント

      • 新しい RDS インスタンスの課金方法が変更される場合があります。

        元の RDS インスタンスの課金方法

        新しい RDS インスタンスの課金方法

        サブスクリプションまたは従量課金

        従量課金

        サーバーレス

        サーバーレス

      • アップグレードが完了すると、元の RDS インスタンスと新しい RDS インスタンスの両方に対して課金されます。ワークロードが新しい RDS インスタンスで安定して実行されていることを確認したら、新しい RDS インスタンスの課金方法をサブスクリプションに変更し、元の RDS インスタンスをリリースまたはサブスクライブ解除できます。詳細については、「ApsaraDB RDS for PostgreSQL インスタンスの課金方法を従量課金からサブスクリプションに変更する」および「ApsaraDB RDS for PostgreSQL インスタンスのリリースまたはサブスクライブ解除」をご参照ください。ただし、次の点に注意する必要があります。

        • 有効期限が切れる前にサブスクリプション RDS インスタンスをリリースすると、払い戻しを受けることができます。ただし、払い戻し額は元の購入額よりも少なくなります。

        • 元の RDS インスタンスを割引料金で購入した場合、新しい RDS インスタンスは元の RDS インスタンスに提供される割引を引き継ぎません。元の RDS インスタンスのメジャーエンジンバージョンをアップグレードするかどうかを判断するには、Alibaba Cloud 管理コンソールにログインし、[サブスクライブ解除] ページに移動して払い戻し額を確認できます。

        • 払い戻し額と払い戻しの到着時刻は請求書に表示されます。払い戻しはすぐには届きません。

    前提条件

    元の RDS インスタンスは、次の要件を満たしている必要があります。

    • 元の RDS インスタンスは PostgreSQL 16 以前を実行している。

      説明

      RDS インスタンスのメジャーエンジンバージョンを PostgreSQL 9.4 から PostgreSQL 10、PostgreSQL 11、PostgreSQL 12、PostgreSQL 13、および PostgreSQL 14 に直接アップグレードできます。メジャーエンジンバージョンを PostgreSQL 9.4 から PostgreSQL 15 にアップグレードする場合は、メジャーエンジンバージョンを PostgreSQL 10、PostgreSQL 11、PostgreSQL 12、PostgreSQL 13、または PostgreSQL 14 にアップグレードする必要があります。その後、メジャーエンジンバージョンを PostgreSQL 15 以降にアップグレードできます。

    • 元の RDS インスタンスは仮想プライベートクラウド (VPC) に存在する。

      元の RDS インスタンスがクラシックネットワークに存在する場合は、アップグレードを実行する前に、元の RDS インスタンスのネットワークタイプを VPC に変更する必要があります。ネットワークタイプを変更するときは、[元のクラシックネットワークエンドポイントを予約する] をオフにします。 RDS インスタンスのネットワークタイプを表示または変更する方法の詳細については、「ApsaraDB RDS for PostgreSQL インスタンスのネットワークタイプの変更」をご参照ください。

      説明

      [元のクラシックネットワークエンドポイントを予約する] を選択した場合は、エンドポイントの保持期間が終了するまで待ってから、アップグレードタスクを開始する必要があります。

    • 元の RDS インスタンスは読み取り専用インスタンスではなく、専用クラスタに作成することはできません。詳細については、「読み取り専用 ApsaraDB RDS for PostgreSQL インスタンスの概要」および「ApsaraDB for MyBase とは」をご参照ください。

    • 元の RDS インスタンスの ID が pg-cn で始まっていません。

    • 元の RDS インスタンスの ID は pg-cn で始まらない。

    • 元の RDS インスタンスに対して読み取り専用の RDS インスタンスが作成されている場合、[カットオーバー] 構成メソッドを使用することはできません。[カットオーバー] 構成メソッドを使用する場合は、「スペックアップの実行前後に実行する操作」セクションに記載されている手順に従う必要があります。

    影響

    アップグレードには、次の影響があります。

    • カットオーバー構成方式を選択した場合、アップグレード中にワークロードを新しい RDS インスタンスに切り替える必要があります。元の RDS インスタンスは読み取りリクエストのみを処理し、スイッチオーバー中は数分間の一時的な切断が発生します。オフピーク時にアップグレードを実行することをお勧めします。切断なし構成方式を選択した場合、元の RDS インスタンスは影響を受けません。

      説明

      • 元の RDS インスタンスが読み取りリクエストのみを処理する期間は、データベースオブジェクトの数によって異なります。元の RDS インスタンスに多数のデータベースオブジェクトが存在する場合、元の RDS インスタンスは読み取りリクエストのみを長時間処理します。数百万のデータベースオブジェクトが存在する場合、元の RDS インスタンスは読み取りリクエストのみを数十分から数時間処理する場合があります。SELECT count(1) FROM pg_class; 文を実行して、元の RDS インスタンス内のデータベースオブジェクトの数をクエリできます。

      • 一時的な切断の期間は、ドメインネームシステム ( DNS ) キャッシュがリフレッシュされる間隔によって異なります。別の vSwitch に切り替えて、一時的な切断の期間に基づいてデータベースクライアントで DNS キャッシュをリフレッシュする間隔を推定できます。詳細については、「vSwitch を変更する」をご参照ください。

      • アップグレードの完了に必要な期間は、データ量と元の RDS インスタンス内のデータベースオブジェクトの数によって異なります。元の RDS インスタンスに大量のデータと多数のデータベースオブジェクトが存在する場合、アップグレードの完了には長い時間がかかります。

      • ブルーグリーンデプロイメントモードを使用していて、スイッチオーバー後に元の RDS インスタンスを読み取り専用にしたくない場合は、アップグレード後に rds_force_trans_ro_non_sup パラメーターを off に設定する必要があります。詳細については、「ApsaraDB RDS for PostgreSQL インスタンスのパラメーターを変更する」をご参照ください。

    • 元の RDS インスタンスが新しいメジャーエンジンバージョンでサポートされていないパラメーターを使用している場合、そのパラメーターは新しい RDS インスタンスから削除されます。以前のメジャーエンジンバージョンのパラメーターの値が、新しいメジャーエンジンバージョンでサポートされている値の範囲内にない場合、システムはパラメーターを新しいメジャーエンジンバージョンで指定されたデフォルト値に設定します。

    • ブルーグリーンデプロイメントモードを使用する場合、新しい RDS インスタンスは、元の RDS インスタンスの[名前]、タグ、CloudMonitor のアラートルール、およびバックアップデータを継承しません。詳細については、「ApsaraDB RDS インスタンスにタグを追加する」、「アラートを管理する」、および「ApsaraDB RDS for PostgreSQL インスタンスをバックアップする」をご参照ください。

    • ブルーグリーンデプロイメントモードを使用する場合、元の RDS インスタンスのセルフマネージド読み取り専用 RDS インスタンスと論理レプリケーションスロットは、アップグレード後に新しい RDS インスタンスに自動的に転送されません。アップグレード後、新しい RDS インスタンスの読み取り専用 RDS インスタンスと論理レプリケーションスロットを作成する必要があります。

    • ローカルアップグレードモードを使用する場合、元の RDS インスタンスのセルフマネージド読み取り専用 RDS インスタンスと論理レプリケーションスロットは、アップグレード後に失われます。ビジネス要件に基づいてアップグレードモードを選択する必要があります。

    • 元の RDS インスタンスが、Data Transmission Service ( DTS ) コンソールで作成された移行タスクのソース RDS インスタンスまたは宛先 RDS インスタンスとして機能している場合は、アップグレードの実行後に移行タスクを再作成する必要があります。DTS コンソールで移行タスクを作成する方法の詳細については、「DTS とは」をご参照ください。

    • レプリケーションスロットのサブスクライバーが元の RDS インスタンス上に存在する場合、レプリケーションスロットがプリエンプトされる可能性があります。レプリケーションスロットがプリエンプトされると、データは同期されません。データ同期の問題を回避するには、次の操作を実行する必要があります。ローカルアップグレードモードを使用する場合は、アップグレード前に元の RDS インスタンスでレプリケーションスロットへのサブスクリプションを無効にすることをお勧めします。

      アップグレード中にレプリケーションスロットがプリエンプトされたときにデータが同期されない問題を解決するにはどうすればよいですか。

      • 元の RDS インスタンスにサブスクライブされたデータを保存する場合、アップグレード中に RDS インスタンスが過負荷によって障害が発生しないようにしてください。アップグレード中に RDS インスタンスが過負荷によって障害が発生した場合、レプリケーションスロットは新しい RDS インスタンスによってプリエンプトされる可能性があります。その結果、データは同期されません。

        アップグレードが完了したら、次の SQL 文を実行して、新しい RDS インスタンスでレプリケーションスロットへのサブスクリプションを無効にします。

        \c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

      • 新しい RDS インスタンスにサブスクライブされたデータを保存する場合、元の RDS インスタンスでレプリケーションスロットへのサブスクリプションを無効にする必要があります。その後、アップグレードを実行できます。アップグレードが完了したら、新しい RDS インスタンスでレプリケーションスロットへのサブスクリプションを有効にします。SQL 文の例:

        • 元の RDS インスタンスでサブスクリプションを無効にします。

          \c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

        • 新しい RDS インスタンスでサブスクリプションを有効にします。

          \c your_database
ALTER SUBSCRIPTION your_subscription_name ENABLE;
      説明

    • 読み取り専用 RDS インスタンスが元の RDS インスタンスにアタッチされている場合、直接アップグレードを実行することはできません。

      アップグレードを実行する前後に、次の操作を実行します。

      1. アプリケーションで、読み取り専用 RDS インスタンスのエンドポイントを元の RDS インスタンスのエンドポイントに変更します。

        説明

        サービスの安定性を確保するために、オフピーク時にアプリケーションのエンドポイント構成を変更することをお勧めします。

      2. 読み取り専用 RDS インスタンスを削除します。

      3. メジャーエンジンバージョンをアップグレードします。詳細については、「手順」をご参照ください。

      4. アップグレードが完了したら、新しいメジャーエンジンバージョンを実行している RDS インスタンスの読み取り専用 RDS インスタンスを作成します。詳細については、「読み取り専用 ApsaraDB RDS for PostgreSQL インスタンスを作成する」をご参照ください。

      5. アプリケーションで、元の RDS インスタンスのエンドポイントを新しい読み取り専用 RDS インスタンスのエンドポイントに変更します。

    • メジャーエンジンバージョンをアップグレードする場合は、最新のマイナーエンジンバージョンが必要です。これにより、拡張機能の互換性の問題が発生する可能性があります。詳細については、「マイナーエンジンバージョンを更新する」をご参照ください。

    • アップグレードの完了に必要な期間は、RDS インスタンスのデータ量によって異なります。ApsaraDB RDS コンソールの [タスクセンター] ページでアップグレードの進捗状況を確認できます。詳細については、「タスクセンターを使用する」をご参照ください。

    • RDS インスタンスのメジャーエンジンバージョンをアップグレードした後、アップグレードをロールバックすることはできません。以前のメジャーエンジンバージョンを使用する場合は、必要なメジャーエンジンバージョンを実行する別の RDS インスタンスを作成し、Data Transmission Service ( DTS ) を使用して、アップグレードされた RDS インスタンスのデータを新しく作成された RDS インスタンスに移行する必要があります。

    • アップグレード中、statement_timeout の値は一時的に 0 に設定され、アップグレードの完了後に元の値に戻されます。

    影響

    1. 読み取り専用 RDS インスタンスが元の RDS インスタンスにアタッチされている場合は、アップグレードを実行する前に、次の手順を実行します。

      1. アプリケーションで、読み取り専用 RDS インスタンスのエンドポイントを元の RDS インスタンスのエンドポイントに変更します。

        説明

        サービスの安定性を確保するために、アプリケーションのエンドポイント構成は、オフピーク時に変更することをお勧めします。

      2. 読み取り専用 RDS インスタンスを削除します。

    2. [メジャーバージョンアップグレード] ページに移動します。

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

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

        説明

        ApsaraDB RDS コンソールで [メジャーバージョンアップグレード] が見つからない場合は、RDS インスタンスが 前提条件 に記載されているすべての要件を満たしているかどうかを確認してください。

    3. [アップグレードチェック] タブで、新しいメジャーエンジンバージョンを選択し、[アップグレードチェックレポートの作成] をクリックします。 このプロセスには数分かかります。

      説明

      • RDS インスタンスがアップグレードチェックに合格していることを確認します。 その後、後続の手順に進みます。

      • RDS インスタンスがアップグレードチェックに合格した後に、RDS インスタンスで CREATE EXTENSION 文を実行する場合は、アップグレードチェックを再度実行する必要があります。

      アップグレードチェックレポートで RDS インスタンスがアップグレードチェックに失敗したことが示されている場合は、[レポートコンテンツ] 列の [情報を見る] をクリックして、レポートの失敗に関する詳細を表示できます。 詳細については、「ApsaraDB RDS for PostgreSQL インスタンスへのメジャーエンジンバージョンのアップグレードのチェックレポートの概要」をご参照ください。

    4. [インスタンスのアップグレード] タブをクリックします。 表示されるタブで、表示されている警告を読み、[アップグレードバージョンの選択] を構成し、[アップグレードインスタンスの作成を続行] をクリックします。

    5. 表示されるメッセージでヒントを読み、[OK] をクリックして、パラメータを構成します。 次の表に、主要なパラメータを示します。

      パラメータ

      説明

      [ストレージタイプ]

      新しい RDS インスタンスに使用するストレージタイプを選択します。

      説明

      [アップグレードモード] パラメータが [ローカルアップグレード] に設定されている場合は、このパラメータを構成する必要はありません。

      メジャーエンジンバージョンアップグレード機能は、クラウドディスクのスナップショットに基づいています。 次のストレージタイプのいずれかを選択できます。

      • 汎用 ESSD

      • ESSD PL1

      • ESSD PL2

      • ESSD PL3

      [アベイラビリティーゾーン]

      新しい RDS インスタンスとそのセカンダリ RDS インスタンスのゾーンと vSwitch を指定します。 指定するゾーンは、元の RDS インスタンスのゾーンとは異なる場合があります。

      説明

      [アップグレードモード] パラメータが [ローカルアップグレード] に設定されている場合は、これらのパラメータを構成する必要はありません。

      [アベイラビリティーゾーンの場合]

      [プライマリインスタンススイッチ]

      [スタンバイインスタンススイッチ]

      [カットオーバー構成]

      ワークロードを新しい RDS インスタンスに自動的に切り替えるかどうかを指定します。

      • [カットなし]: システムは、ワークロードを新しい RDS インスタンスに自動的に切り替えません。 アップグレードを実行する前に、[カットなし] 構成メソッドを選択して、新しいメジャーエンジンバージョンがワークロードと互換性があるかどうかをテストすることをお勧めします。 新しいメジャーエンジンバージョンが互換性テストに合格した場合は、新しい RDS インスタンスをリリースできます。 その後、[カットオーバー] 構成メソッドを選択して、アップグレードを実行できます。 詳細については、「ApsaraDB RDS for PostgreSQL インスタンスのリリースまたはサブスクライブ解除」および 手順」をご参照ください。

        説明

        • データ移行は、元の RDS インスタンスでのワークロードを中断しません。

        • [カットなし] 構成メソッドを選択した場合は、データが新しい RDS インスタンスに移行された後、アプリケーションで元の RDS インスタンスのエンドポイントを新しい RDS インスタンスのエンドポイントに変更する必要があります。 RDS インスタンスのエンドポイントを表示する方法の詳細については、「ApsaraDB RDS for PostgreSQL インスタンスのエンドポイントとポート番号の表示と変更」をご参照ください。

      • [カットオーバー]: システムは、ワークロードを新しい RDS インスタンスに自動的に切り替えます。 この構成メソッドは、新しいメジャーエンジンバージョンがワークロードと互換性があることを確認した後に、アップグレードを実行するために使用されます。

        • ローカルアップグレードモードを使用する場合、新しい RDS インスタンスは作成されず、元の RDS インスタンスは元の構成を継承します。 アプリケーションのエンドポイント構成を変更する必要はありません。

        • ブルーグリーンデプロイメントモードを使用する場合、スイッチオーバーが完了すると、アプリケーションは自動的に新しい RDS インスタンスに接続されます。 アプリケーションのエンドポイント構成を変更する必要はありません。

        説明

        • スイッチオーバーが完了すると、ワークロードを元の RDS インスタンスにロールバックすることはできません。 注意して進めてください。

        • スイッチオーバー中、元の RDS インスタンスは読み取りリクエストのみを処理します。 スイッチオーバーは、オフピーク時に実行することをお勧めします。

        • 読み取り専用 RDS インスタンスが元の RDS インスタンスにアタッチされている場合は、[カットオーバー] 構成メソッドを選択できません。 この場合、[カットなし] 構成メソッドを使用してのみ、元の RDS インスタンスのメジャーエンジンバージョンをアップグレードできます。 また、元の RDS インスタンスにアタッチされている読み取り専用 RDS インスタンスは複製されません。 アップグレードが完了したら、新しいメジャーエンジンバージョンを実行する RDS インスタンスの読み取り専用 RDS インスタンスを作成する必要があります。 詳細については、「読み取り専用 ApsaraDB RDS for PostgreSQL インスタンスの作成」をご参照ください。

      [カットオーバー時間]

      データが新しい RDS インスタンスに移行された後、システムがワークロードを新しい RDS インスタンスに切り替える時点を指定します。

      • [即時]: データが新しい RDS インスタンスに移行されると、システムはすぐにワークロードを新しい RDS インスタンスに切り替えます。

      • [インスタンスの運用およびメンテナンス時間]: システムは、指定したメンテナンスウィンドウ中に、ワークロードを新しい RDS インスタンスに切り替えます。 詳細については、「ApsaraDB RDS for PostgreSQL インスタンスのメンテナンスウィンドウの設定」をご参照ください。

      説明

      このパラメータは、[カットオーバー構成] パラメータが [カットオーバー] に設定されている場合にのみ必須です。

      [アップグレードモード]

      アップグレードモードを選択します。

      説明

      • このパラメータは、[カットオーバー構成] パラメータが [カットオーバー] に設定されている場合にのみ必須です。

      • このパラメータは、ローカルディスクを使用する RDS for PostgreSQL インスタンスでは使用できません。 これらのインスタンスでは、デフォルトでブルーグリーンデプロイメントモードが使用されます。

      • [ローカルアップグレード]: メジャーエンジンバージョンアップグレードは元の RDS インスタンスで実行され、新しい RDS インスタンスは作成されません。 アップグレード後、元の RDS インスタンスは新しいメジャーエンジンバージョンを実行し、元の次数、名前、タグ、CloudMonitor のアラートルール、およびバックアップ設定を継承します。

      • [ブルーグリーンデプロイメント]: RDS インスタンスのメジャーエンジンバージョンがアップグレードされると、元の RDS インスタンスは保持され、新しい RDS インスタンスが作成されます。 新しい RDS インスタンスの作成に対して料金は発生しません。 新しい RDS インスタンスが作成されると、元の課金方法とは異なる可能性のある新しい課金方法に基づいて料金が発生します。 アップグレードが完了すると、元の RDS インスタンスと新しい RDS インスタンスの両方に対して料金が発生します。また、新しい RDS インスタンスは、元の RDS インスタンスに提供される割引を利用できません。

      [統計情報収集モード]

      システムが新しい RDS インスタンスの統計情報を収集する時点を指定します。

      • [カット前の収集]: このオプションは、データベースサービスの安定性を確保します。 元の RDS インスタンスに大量のデータが含まれている場合、アップグレードに長い時間がかかる場合があります。

      • [カット後の収集]: このオプションは、アップグレードプロセスを高速化します。 統計が生成されていないテーブルにアクセスすると、指定したクエリプランが正しく実行されない場合があります。 また、ピーク時にデータベースサービスが利用できなくなる可能性があります。

      説明

      [カットなし] 構成メソッドを選択した場合、[カット前の収集] オプションは、新しい RDS インスタンスが読み取りおよび書き込みリクエストの処理を開始する前に、システムが新しい RDS インスタンスの統計情報を収集することを指定します。 [カット後の収集] オプションは、新しい RDS インスタンスが読み取りおよび書き込みリクエストの処理を開始した後に、システムが新しい RDS インスタンスの統計情報を収集することを指定します。

      [ストレージ容量]

      新しい RDS インスタンスのストレージ容量を指定します。

      説明

      [アップグレードモード] パラメータが [ローカルアップグレード] に設定されている場合は、このパラメータを構成する必要はありません。

      元の RDS インスタンスがローカル SSD を使用している場合は、RDS インスタンスのメジャーエンジンバージョンをアップグレードするときに、RDS インスタンスのストレージ容量を削減できます。 [ストレージ容量] パラメータに指定する最小値は、次の要件を満たしている必要があります。

      • 最小値は、次の値のうち小さい方の値によって決まります。

        • 元の RDS インスタンスの使用済みストレージに 120% を掛けた値 (GB)。 結果が 5 の倍数でない場合は、得られた値は 5 の倍数に切り上げられます。

          説明

          元の RDS インスタンスの使用済みストレージは、[監視とアラート] ページの [ディスクストレージ (MB)] セクションで確認できます。 詳細については、「ApsaraDB RDS for PostgreSQL インスタンスの拡張監視メトリックの表示」をご参照ください。

        • 元の RDS インスタンスのストレージ容量。

      • 最小値は、ESSD の最小ストレージ容量以上である必要があります。 最小値が ESSD の最小ストレージ容量より小さい場合は、ESSD の最小ストレージ容量を最小値として使用する必要があります。 次のリストは、さまざまなパフォーマンスレベル (PL) の ESSD の最小ストレージ容量を示しています。

        • ESSD PL1: 20 GB

        • ESSD PL2: 500 GB

        • ESSD PL3: 1,500 GB

      説明

      例:

      • 元の RDS インスタンスのストレージ容量は 100 GB、使用済みストレージは 70 GB で、RDS インスタンスのメジャーエンジンバージョンをアップグレードするときに、ストレージタイプとして ESSD PL1 が選択されています。

        計算方法: 70 × 120% = 84、85 に切り上げ。 [ストレージ容量] パラメータの最小値は 85 GB です。

      • 元の RDS インスタンスのストレージ容量は 700 GB、使用済みストレージは 350 GB で、RDS インスタンスのメジャーエンジンバージョンをアップグレードするときに、ストレージタイプとして ESSD PL2 が選択されています。

        計算方法: 350 × 120% = 420。 得られた値 420 GB は、PL2 の ESSD でサポートされている 500 GB より小さくなっています。 [ストレージ容量] パラメータの最小値は 500 GB です。

      [インスタンス仕様]

      新しい RDS インスタンスのインスタンスタイプを指定します。 サポートされているインスタンスタイプの詳細については、「プライマリ ApsaraDB RDS インスタンスタイプ」をご参照ください。

      説明

      [アップグレードモード] パラメータが [ローカルアップグレード] に設定されている場合は、このパラメータを構成する必要はありません。

    6. [今すぐ作成] をクリックします。

      [アップグレードモード] パラメータが [ブルーグリーンデプロイメント] に設定されている場合、元の RDS インスタンスのステータスは [移行中] に変わり、[作成中] 状態の RDS インスタンスがインスタンスリストに表示されます。 元の RDS インスタンスと新しい RDS インスタンスの両方が [実行中] 状態になると、新しい RDS インスタンスが作成され、アップグレードが完了します。 アップグレードに必要な時間は、データ量によって異なります。

      説明

      • アップグレードタスクを作成した後、タスクを変更または削除することはできません。

      • 元の RDS インスタンスが [移行中] 状態の場合、RDS インスタンスで O&M 操作を実行することはできません。 たとえば、RDS インスタンスのパラメータを変更したり、RDS インスタンスを再起動またはリリースしたりすることはできません。

      • [今すぐ作成] をクリックした後、[リソース不足] というメッセージが表示された場合は、[アベイラビリティーゾーン] パラメータの値を変更します。

      • アップグレードが完了したら、[アップグレード履歴] タブに移動し、アップグレードタスクに対応する [アップグレードログ] 列の [情報を見る] をクリックして、インスタンスが読み取り専用になる期間や詳細なアップグレードプロセスなど、関連情報を表示できます。

    7. 読み取り専用 RDS インスタンスが元の RDS インスタンスにアタッチされていて、手順 1 で読み取り専用 RDS インスタンスを削除した場合は、アップグレード後に次の手順を実行します。

      1. 新しい RDS インスタンスの読み取り専用 RDS インスタンスを作成します。 詳細については、「読み取り専用 ApsaraDB RDS for PostgreSQL インスタンスの作成」をご参照ください。

      2. アプリケーションで、元の RDS インスタンスのエンドポイントを新しい読み取り専用 RDS インスタンスのエンドポイントに変更します。 詳細については、「手順 1」をご参照ください。

    次の手順

    1. [ブルーグリーンデプロイメント] モードを使用し、新しい RDS インスタンスでワークロードが安定して実行されていることを確認したら、できるだけ早く元の RDS インスタンスをリリースします。新しい RDS インスタンスの課金方法をサブスクリプションに変更することをお勧めします。詳細については、「ApsaraDB RDS for PostgreSQL インスタンスをリリースまたはサブスクライブ解除する」および「ApsaraDB RDS for PostgreSQL インスタンスの課金方法を従量課金からサブスクリプションに変更する」をご参照ください。

    2. [ブルーグリーンデプロイメント] モードを使用する場合は、元の RDS インスタンスをリリースします。詳細については、「ApsaraDB RDS for PostgreSQL インスタンスをリリースまたはサブスクライブ解除する」をご参照ください。

      説明

      • 有効期限が切れる前にサブスクリプション RDS インスタンスをリリースすると、払い戻しを受けることができます。ただし、払い戻し額は元の購入額よりも少なくなります。

      • 元の RDS インスタンスを割引料金で購入した場合、新しい RDS インスタンスには、元の RDS インスタンスに提供された割引は引き継がれません。Alibaba Cloud 管理コンソールにログインし、[サブスクライブ解除] ページに移動して、払い戻し額を確認できます。

      • 払い戻し額と払い戻しの到着時刻は、請求書に表示されます。払い戻しはすぐには行われません。

    3. 新しい RDS インスタンスには元の RDS インスタンスの読み取り専用 RDS インスタンスが引き継がれないため、ビジネス要件に基づいて新しい RDS インスタンスの読み取り専用 RDS インスタンスを作成します。詳細については、「読み取り専用 ApsaraDB RDS for PostgreSQL インスタンスを作成する」をご参照ください。

    関連操作

    よくある質問

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

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

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

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

    メジャーエンジンバージョンアップグレードの完了後に新しい RDS インスタンスで raster_overviews ビューを作成すると、ビューの非互換性の問題が発生します。どうすればよいですか。

    PostGIS 拡張機能のバージョンが 2.5.2 より前で、RDS インスタンスのメジャーエンジンバージョンが PostgreSQL 10 または PostgreSQL 11 の場合は、PostGIS 拡張機能のバージョンを更新してから、メジャーエンジンバージョンを PostgreSQL 12 にアップグレードします。この場合、新しい RDS インスタンスで raster_overviews ビューを作成すると、ビューの非互換性の問題が発生する可能性があります。

    この問題を解決するには、次の手順を実行します。

    1. 元の RDS インスタンスで PostGIS 拡張機能のバージョンを更新します。

      更新が成功したことを確認するために、次の文を 2 回実行します。

      SELECT PostGIS_Extensions_Upgrade();
SELECT PostGIS_Extensions_Upgrade();

    2. postgis_raster 拡張機能が使用されているかどうかを確認し、ビジネス要件に基づいて更新方法を選択します。

      postgis_raster 拡張機能が使用されています。

      1. 元の RDS インスタンスで次の文を実行して、raster_overviews ビューを変更します。

        ALTER EXTENSION PostGIS_Raster DROP VIEW raster_overviews;
CREATE OR REPLACE VIEW raster_overviews AS SELECT 1;

      2. RDS インスタンスのメジャーバージョンを PostgreSQL 12 以降にアップグレードします。

      3. アップグレードが完了したら、新しい RDS インスタンスでビューを再作成します。

        CREATE 
OR REPLACE VIEW raster_overviews AS 
SELECT 
  current_database() AS o_table_catalog, 
  n.nspname AS o_table_schema, 
  c.relname AS o_table_name, 
  a.attname AS o_raster_column, 
  current_database() AS r_table_catalog, 
  split_part(
    split_part(s.consrc, '''::name', 1), 
    '''', 
    2
  ): :name AS r_table_schema, 
  split_part(
    split_part(s.consrc, '''::name', 2), 
    '''', 
    2
  ): :name AS r_table_name, 
  split_part(
    split_part(s.consrc, '''::name', 3), 
    '''', 
    2
  ): :name AS r_raster_column, 
  trim(
    both 
    from 
      split_part(s.consrc, ',', 2)
  ): :integer AS overview_factor 
FROM 
  pg_class c, 
  pg_attribute a, 
  pg_type t, 
  pg_namespace n, 
  (
    SELECT 
      connamespace, 
      conrelid, 
      conkey, 
      pg_get_constraintdef(oid) As consrc 
    FROM 
      pg_constraint
  ) AS s 
WHERE 
  t.typname = 'raster' : :name 
  AND a.attisdropped = false 
  AND a.atttypid = t.oid 
  AND a.attrelid = c.oid 
  AND c.relnamespace = n.oid 
  AND c.relkind = ANY(
    ARRAY[ 'r' : :char, 'v' : :char, 'm' : :char, 
    'f' : :char ]
  ) 
  AND s.connamespace = n.oid 
  AND s.conrelid = c.oid 
  AND s.consrc LIKE '%_overview_constraint(%' 
  AND NOT pg_is_other_temp_schema(c.relnamespace) 
  AND has_table_privilege(c.oid, 'SELECT' : :text); ALTER EXTENSION PostGIS_Raster 
ADD 
  VIEW raster_overviews;
      postgis_raster 拡張機能は使用されていません。

      1. 元の RDS インスタンスで次の文を実行して、postgis_raster 拡張機能を削除します。

        DROP EXTENSION PostGIS_Raster;

      2. RDS インスタンスのメジャーバージョンを PostgreSQL 12 以降にアップグレードします。

    アップグレード後にサブスクライブされたデータに不整合があるという問題をどのように処理すればよいですか。

    1. アップグレードが成功したら、新しい RDS インスタンス内のすべてのテーブルデータをクリアし、サブスクリプションを再作成してから、copy_data を true に設定します。詳細については、「ALTER SUBSCRIPTION」をご参照ください。

    2. CONFLICT キーワードを使用して、元の RDS インスタンスで消費されたデータを新しい RDS インスタンスにインポートします。例：

      CREATE TABLE my_tbl(id INT PRIMARY KEY, t TIMESTAMP, val TEXT);

INSERT INTO my_tbl VALUES (1, CURRENT_TIMESTAMP, 'a');
INSERT INTO my_tbl VALUES (2, CURRENT_TIMESTAMP, 'b');
INSERT INTO my_tbl VALUES (3, CURRENT_TIMESTAMP, 'c');

-- 新しいタイムスタンプの場合：更新を実行
INSERT INTO my_tbl VALUES (1, CURRENT_TIMESTAMP, 'd') ON CONFLICT(id) DO UPDATE
	SET t = excluded.t,
		val = excluded.val
	WHERE my_tbl.t < excluded.t;

-- 古いタイムスタンプの場合：何もしない
INSERT INTO my_tbl VALUES (2, CURRENT_TIMESTAMP - '10 hours'::interval, 'e') ON CONFLICT(id) DO UPDATE
	SET t = excluded.t,
		val = excluded.val
	WHERE my_tbl.t < excluded.t;

-- 新しい値の場合：挿入のみ
INSERT INTO my_tbl VALUES (5, CURRENT_TIMESTAMP - '10 hours'::interval, 'f') ON CONFLICT(id) DO UPDATE
	SET t = excluded.t,
		val = excluded.val
	WHERE my_tbl.t < excluded.t;

    アップグレード中にソースインスタンスが読み取り専用になる期間をどのように表示しますか。

    [メジャーバージョンアップグレード] ページの [アップグレード履歴] タブをクリックすると、アップグレードタスクの [カットオーバー時間] と [カットオーバー終了時間] を表示できます。この 2 つの時点の間の期間が、アップグレード中のデータベースの読み取り専用期間です。この期間には、フラッシュされていない DNS キャッシュによって発生する切断期間は含まれません。

    カットオーバーが実際に実行されないシナリオでは、[カットオーバー時間] と [カットオーバー終了時間] もカットオーバーシナリオの参考として表示されます。