ApsaraDB RDS:ブルーグリーンデプロイメントによるメジャーバージョンのアップグレード

前提条件

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

• インスタンスが 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;

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

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