すべてのプロダクト
Search

このプロダクト

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

    ドキュメントセンター

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

    最終更新日:Dec 18, 2024

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

    背景情報

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

    アップグレード手順

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

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

    2. 必要に応じて、 互換性テストを実行します。

      RDSインスタンスのメジャーエンジンバージョンをアップグレードすると、新しいメジャーエンジンバージョンがワークロードと互換性がない可能性があります。 アップグレードを実行する前に、[切断なし] 設定方法を使用して、新しいメジャーエンジンバージョンがワークロードと互換性があるかどうかをテストすることを推奨します。

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

      元のRDSインスタンスのメジャーエンジンバージョンを再度アップグレードし、[Cutover] 設定方法を選択して、ワークロードを新しいRDSインスタンスに切り替えます。 [カットオーバー] 設定方法を選択した場合、ローカルアップグレードモードとblue-green展開モードが提供されます。 ビジネス要件に基づいてアップグレードモードを選択できます。

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

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

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

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

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

        従量課金

        Serverless

        Serverless

      説明

      ローカルディスクを使用するRDS for PostgreSQLインスタンスは、blue-greenデプロイメントモードのみをサポートします。

    Cutoverの記述および切断の構成方法無し

    メジャーエンジンのバージョンをアップグレードするときに、Cutover設定パラメーターを設定して、新しいメジャーエンジンのバージョンを実行する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インスタンスのワークロードを中断することなくアップグレードの実現可能性を確認できます。

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

      • アプリケーションの変更なし: Cutover設定方法を使用してアップグレードを実行できます。 アプリケーションのエンドポイント構成を変更する必要はありません。 blue-greenデプロイモードを使用すると、切り替えが完了すると、元のRDSインスタンスのエンドポイントが新しいRDSインスタンスのエンドポイントに自動的に変更されます。 ローカルアップグレードモードを使用する場合、元のRDSインスタンスのエンドポイントは変更されません。

        説明

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

        • blue-greenデプロイモードを使用する場合、新しいRDSインスタンスのVIPは元のRDSインスタンスのVIPとは異なります。 アプリケーションで元のRDSインスタンスのVIPを設定する場合は、アプリケーション設定を変更する必要があります。 アプリケーションで元のRDSインスタンスのVIPの代わりにエンドポイントを設定することを推奨します。 詳細については、「エンドポイントとポート番号の表示と変更」をご参照ください。

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

      • リザーブドインスタンス設定:

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

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

    課金ルール

    • ローカルアップグレードは料金の変更を引き起こさず、注文を生成しません。

    • ブルーグリーン展開

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

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

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

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

        従量課金

        Serverless

        Serverless

      • アップグレードが完了すると、元の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で始まりません。

    • Babelfishは、元のRDSインスタンスに対して有効になっていません。 元のRDSインスタンスのマイナーエンジンバージョンにbabelfishが含まれていない場合、Babelfishは有効になりません。

    • 元のRDSインスタンスに対して読み取り専用RDSインスタンスが作成されている場合、Cutover設定方法は使用できません。 Cutover設定方法を使用する場合は、[アップグレードを実行する前後に次の操作を実行する] セクションの手順に従う必要があります。

    影響

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

    • Cutover設定方法を選択した場合、アップグレード中にワークロードを新しいRDSインスタンスに切り替える必要があります。 元のRDSインスタンスは読み取り要求のみを処理し、切り替え中に数分間続く一時的な接続が発生します。 オフピーク時にアップグレードを実行することを推奨します。 [切断設定なし] を選択した場合、元のRDSインスタンスは影響を受けません。

      説明

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

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

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

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

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

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

    • blue-greenデプロイモードを使用している場合、アップグレード後、元の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インスタンスに使用するストレージタイプを選択します。

      説明

      Upgrade modeパラメーターがLocal upgradeに設定されている場合、このパラメーターを設定する必要はありません。

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

      • 一般的なESSD

      • ESSD PL1

      • ESSD PL2

      • ESSD PL3

      利用可能なゾーン

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

      説明

      Upgrade modeパラメーターがLocal upgradeに設定されている場合、これらのパラメーターを設定する必要はありません。

      利用可能なゾーン

      プライマリインスタンスの切り替え

      スタンバイインスタンスの切り替え

      カットオーバー設定

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

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

        説明

        • データ移行によって、元のRDSインスタンスのワークロードが中断されることはありません。

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

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

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

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

        説明

        • 切り替えが完了すると、ワークロードを元のRDSインスタンスにロールバックすることはできません。 作業は慎重に行ってください。

        • 切り替え中、元のRDSインスタンスは読み取り要求のみを処理します。 そのため、ピーク時間外に切り替えを実行することを推奨します。

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

      カットオーバー時間

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

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

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

      説明

      このパラメーターは、Cutover設定パラメーターがCutoverに設定されている場合にのみ必要です。

      アップグレードモード

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

      説明

      • このパラメーターは、Cutover設定パラメーターがCutoverに設定されている場合にのみ必要です。

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

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

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

      統計情報収集モード

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

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

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

      説明

      [切断なし] 設定方法を選択した場合、[切断前の収集] オプションは、新しいRDSインスタンスが読み書き要求の処理を開始する前に新しいRDSインスタンスの統計を収集することを指定し、[切断後の収集] オプションは、新しいRDSインスタンスが読み書き要求の処理を開始した後に新しいRDSインスタンスの統計を収集することを指定します。

      保管スペース

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

      説明

      Upgrade modeパラメーターがLocal upgradeに設定されている場合、このパラメーターを設定する必要はありません。

      元の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インスタンスのメジャーエンジンバージョンをアップグレードする場合、元のRDSインスタンスのストレージ容量は100 GB、70 GBのストレージが使用され、ESSD PL1がストレージタイプとして選択されます。

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

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

        計算方法: 350 × 120% = 420。 取得された値420 GBは、PL2のESSDでサポートされている500 GBよりも小さい。 ストレージスペースパラメーターの最小値は500 GBです。

      インスタンス仕様

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

      説明

      Upgrade modeパラメーターがLocal upgradeに設定されている場合、このパラメーターを設定する必要はありません。

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

      Upgrade modeパラメーターがBlue green deploymentに設定されている場合、元の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. blue-green deploymentモードを使用し、新しいRDSインスタンスでワークロードが安定して実行されていることを確認した場合は、新しいRDSインスタンスの課金方法をサブスクリプションに変更します。 詳細については、「ApsaraDB RDS For PostgreSQLインスタンスの課金方法を従量課金からサブスクリプションに変更する」をご参照ください。

    2. blue-green deploymentモードを使用する場合は、元のRDSインスタンスをリリースします。 詳細については、「ApsaraDB RDS For PostgreSQLインスタンスのリリースまたはサブスクリプション解除」をご参照ください。

      説明

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

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

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

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

    関連する API 操作

    よくある質問

    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サブスクリプション」をご参照ください。

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

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

-- in case with newer timestamp: do update
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;

-- in case with older timestamp: do nothing
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;

-- in case with new val: just insert
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キャッシュによる切断期間は含まれません。

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