ApsaraDB RDS:Upgrade a major version using blue-green deployment

前提条件

開始する前に、以下を確認してください：

• インスタンスが ApsaraDB RDS for PostgreSQL 16 またはそれ以前のバージョンを実行していること

• インスタンスが読み取り専用インスタンスまたは専用クラスターインスタンスではないこと

• インスタンスで Babelfish が有効になっていないこと (マイナーエンジンバージョン番号の末尾が babelfish ではないこと)

課金

ブルーグリーンデプロイメントによるアップグレードを開始すると、システムはソースインスタンスに基づいて新しいインスタンスを作成します。ソースインスタンスをリリースするまで、両方のインスタンスが個別に課金されます。

ご利用のサービスが新しいインスタンスで安定して稼働することを確認した後、新しいインスタンスをサブスクリプションに変換し、ソースインスタンスをリリースまたはサブスクリプションの解除を行ってください。

考えられる影響

アップグレードを開始する前に、以下をご確認ください。

ステップ 1：アップグレード前チェックの実行

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

2. (任意) ソースインスタンスに読み取り専用インスタンスが存在する場合、オフピーク時間にアプリケーションの読み取り専用インスタンスのエンドポイントをプライマリインスタンスのエンドポイントに変更し、その後、読み取り専用インスタンスを削除します。

   読み取り専用ノードとレプリケーションスロットは新しいインスタンスに自動的に転送されないため、アップグレード前に読み取り専用インスタンスを削除する必要があります。アップグレード後、新しいインスタンスで新しい読み取り専用インスタンスを作成してください。

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

   [メジャーバージョンアップ] が表示されない場合は、ご利用のインスタンスが上記の前提条件を満たしているか確認してください。

4. [アップグレードチェック] タブで、[アップグレードチェックレポートの作成] をクリックします。

5. ターゲットバージョンを選択し、[アップグレードモード] を [ブルーグリーンデプロイメント] に設定し、[OK] をクリックします。インスタンスのステータスが [インスタンスのメンテナンス中] に変わります。チェックが完了すると、ステータスは [実行中] に戻ります。

6. チェックレポートの結果を確認します：

   • 成功 または 警告：ステップ 2 に進みます。

   • 失敗：[情報の表示] をクリックし、特定された問題を修正して、再度チェックを実行します。

   重要

   • [警告] の結果が出た場合は、指摘されたすべての項目を修正し、結果が [成功] になるまで再度チェックを実行してください。

   • チェックが成功した後にプライマリインスタンスでプラグインを作成した場合は、先に進む前にもう一度チェックを実行してください。

次のステップ

1. ブルーグリーンデプロイメント (切り替え) メソッドを使用してアップグレードした場合、ご利用のサービスが新しいインスタンスで安定して稼働することを確認した後、ソースインスタンスをリリースします。コストを節約するために、新しいインスタンスの課金方法をサブスクリプションに変換します。

   有効期限前にサブスクリプションインスタンスをリリースすると、金銭的な損失が発生する可能性があります。新しいインスタンスは、ソースインスタンスの割引を継承しません。返金は実際のサブスクリプション解除請求書に従い、リアルタイムでは処理されません。

2. (任意) アップグレード前に読み取り専用インスタンスを削除した場合、新しいインスタンスで再作成します：

   1. 新しいインスタンスでPostgreSQL 読み取り専用インスタンスを作成します。

   2. アプリケーションで、エンドポイントを新しい読み取り専用インスタンスを指すように更新します。

API リファレンス

参考

• メジャーバージョンアップの概要

• ゼロダウンタイムモードを使用してメジャーバージョンアップを実行する

• インプレースアップグレードモードを使用してメジャーバージョンアップを実行する

• ApsaraDB RDS for PostgreSQL のメジャーバージョンアップグレードチェックレポートの解釈

よくある質問

メジャーバージョンアップ中にインスタンスを変更できますか？

いいえ。アップグレードが進行中の間、インスタンスは変更できません。変更はアップグレードが完了した後にのみ可能です。

自動メジャーバージョンアップはサポートされていますか？

いいえ。メジャーバージョンアップは手動でトリガーする必要があります。

メジャーバージョンのダウングレードはサポートされていますか？

いいえ。メジャーバージョンアップ後のダウングレードはサポートされていません。より低いバージョンを実行するには、そのバージョンで新しいインスタンスを購入し、Data Transmission Service (DTS) を使用してデータを移行してください。

メジャーバージョンアップ後、新しいインスタンスでビューを作成する際に `raster_overviews` の競合が発生します。どうすれば修正できますか？

この問題は、PostGIS のバージョンが 2.5.2 より前で、PostGIS プラグインを先にアップグレードせずに PostgreSQL 10 または 11 から PostgreSQL 12 にアップグレードしている場合に発生します。

ステップ 1：ソースインスタンスで PostGIS プラグインをアップグレードする

アップグレードが正常に完了することを確認するために、次のコマンドを 2 回実行します：

SELECT PostGIS_Extensions_Upgrade();
SELECT PostGIS_Extensions_Upgrade();

ステップ 2：PostGIS Raster プラグインを使用しているかどうかに基づいて修正方法を選択する

PostGIS Raster プラグインが使用中の場合：

1. ソースインスタンスで、raster_overviews ビューを拡張からデタッチし、プレースホルダーに置き換えます：

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

2. PostgreSQL インスタンスを少なくとも PostgreSQL 12 にアップグレードします。

3. アップグレード後、新しいインスタンスでビューを再作成します：

   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. ソースインスタンスでプラグインをドロップします：

   DROP EXTENSION PostGIS_Raster;

2. PostgreSQL インスタンスを少なくとも PostgreSQL 12 にアップグレードします。

アップグレード中のレプリケーションスロットの競合によるデータの不整合を防ぐにはどうすればよいですか？

ソースインスタンスがレプリケーションスロットのサブスクライバーである場合、アップグレード中にレプリケーションスロットが新しいインスタンスによって競合される可能性があり、データの不整合を引き起こすことがあります。

ソース (下位バージョン) インスタンスのサブスクリプションデータを保持するには：アップグレード中にソースインスタンスが過度の負荷で失敗しないようにして、レプリケーションスロットが競合されるのを防ぎます。アップグレードが完了したら、新しいインスタンスでサブスクリプションを無効にします：

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

新しい (上位バージョン) インスタンスのサブスクリプションデータを保持するには：アップグレードを開始する前にソースインスタンスでサブスクリプションを無効にし、アップグレードが完了した後に新しいインスタンスで有効にします。

ソースインスタンスで無効にする：

\c your_database
ALTER SUBSCRIPTION your_subscription_name DISABLE;

新しいインスタンスで有効にする：

\c your_database
ALTER SUBSCRIPTION your_subscription_name ENABLE;

詳細については、「論理サブスクリプション」および「変更追跡」をご参照ください。

アップグレード後のサブスクリプションデータの不整合をどのように処理すればよいですか？

すでに不整合が発生している場合は、次のアプローチを使用して調整します：

1. 新しいインスタンスで、影響を受けたテーブルデータを削除し、copy_data=true でサブスクリプションを再作成します。詳細については、「ALTER SUBSCRIPTION」をご参照ください。

2. ON 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');
   
   -- 新しいタイムスタンプ：既存の行を更新
   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;

なぜアップグレード前に読み取り専用インスタンスを削除する必要があるのですか？

ソースインスタンスの読み取り専用ノードとレプリケーションスロットは、アップグレード後に新しいインスタンスに自動的に転送されません。アップグレード前に読み取り専用インスタンスを削除することで、エンドポイントの競合を防ぎ、クリーンな切り替えを保証します。アップグレード後、新しいインスタンスで新しい読み取り専用インスタンスを作成し、アプリケーションのエンドポイントを適宜更新してください。