ゼロダウンタイムモードを使用したメジャーバージョンのアップグレード - ApsaraDB RDS

ApsaraDB RDS for PostgreSQL インスタンスのメジャーエンジンバージョンをアップグレードする際に、ゼロダウンタイムモードを使用すると、データベースを完全に稼働させたままアップグレードできます。このプロセス全体を通じて、インスタンスは読み取りおよび書き込み操作を受け付けます。最終的なスイッチオーバー中には、シーケンス数と大規模トランザクションの書き込み量に応じて、数秒間のみ読み取り専用モードになります。

その他のアップグレード方法については、「メジャーバージョンアップグレードソリューションの概要」をご参照ください。

仕組み

ゼロダウンタイムモードでは、pg_upgrade を実行してご利用のインスタンスのスナップショットをターゲットバージョンにアップグレードし、その後ネイティブの論理レプリケーションを使用してソースから増分変更を同期します。スイッチオーバーをトリガーする前に、宛先インスタンスを検証してください。スイッチオーバーを開始すると、シーケンスが同期される間にインスタンスが一時的に読み取り専用になり、その後トラフィックが新しいバージョンに切り替わります。

課金

無料です。

前提条件

開始前に、以下の条件を満たしていることを確認してください。

インスタンスが ApsaraDB RDS for PostgreSQL 16 またはそれ以前のバージョンで動作していること。
ストレージタイプがクラウドディスクであること。パフォーマンス専有型ローカルディスクを使用しているインスタンスは、ブルーグリーンデプロイメントモードのみ使用できます。
課金方法が従量課金またはサブスクリプションであること。Serverless インスタンスは、ブルーグリーンデプロイメントモードのみ使用できます。
インスタンスが読み取り専用インスタンスまたは専用クラスターインスタンスでないこと。
wal_level パラメーターが logical に設定されていること。ゼロダウンタイムアップグレードは論理レプリケーションに依存するため、wal_level が replica または minimal の場合、事前アップグレードチェックは失敗します。設定されていない場合は、続行前にインスタンスパラメーターを変更してください。
Babelfish が有効になっていないこと。マイナーエンジンバージョン番号が babelfish で終わってはいけません。

注意事項

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

ビジネスへの影響

アップグレード開始からスイッチオーバー完了までの間、DDL (Data Definition Language) 操作は禁止されます。ソースインスタンスのダウンタイムは数秒単位で、シーケンス数と大規模トランザクションの書き込み量によって異なります。

レプリケーションスロット

ソースインスタンスにパブリケーション (レプリケーションスロットの公開側) がある場合、そのレプリケーションスロットはアップグレード後に失われます。
ソースインスタンスにサブスクライバー (レプリケーションスロットの購読側) がある場合、レプリケーションスロットのプリエンプションによりデータ同期に問題が発生する可能性があります。詳細については、「よくある質問」をご参照ください。

パラメーターの変更

ターゲットバージョンでサポートされていないパラメーターは自動的に削除されます。
ターゲットバージョンの有効範囲外にある値を持つパラメーターは、ターゲットバージョンのパラメーターテンプレートのデフォルト値にリセットされます。
statement_timeout はアップグレード中に一時的に 0 に設定され、完了後に元の値に戻ります。

DTS タスク

インスタンスが Data Transmission Service (DTS) のソースまたは宛先である場合、アップグレード後に DTS タスクを再作成してください。

プラグインの互換性

アップグレードにより、インスタンスは最新のマイナーエンジンバージョンに自動的に更新されるため、プラグインの互換性に問題が発生する可能性があります。

バックアップ

クローンベースのリカバリをサポートするために、アップグレード前後で完全バックアップが実行されます。

アップグレード各段階での影響

アップグレード段階	影響
メジャーバージョンアップグレードの開始	DDL 操作が禁止されます。
レプリケーションスロットおよびパブリケーションの作成	DDL 操作が禁止されます。WAL ログの蓄積が始まります。
サブスクライバーの開始および論理レプリケーション関係の確立	DDL 操作が禁止されます。WAL ログの消費が始まり、蓄積は停止します。論理レプリケーションにより一定のリソースペイロードが発生します。このペイロードはデータベース数およびトラフィックと密接に関連しています。
スイッチオーバーの開始	DDL 操作が禁止されます。論理レプリケーションにより一定のリソースペイロードが発生します。このペイロードはデータベース数およびトラフィックと密接に関連しています。インスタンスは読み取り専用になり、読み取り専用の持続時間はシーケンス数に関連しています。
スイッチオーバーの完了 (アップグレード完了)	論理レプリケーションスロットが削除され、論理レプリケーションによって発生していたリソースペイロードが解消されます。インスタンスは通常の読み取りおよび書き込み操作を再開します。

アップグレードタスクが開始されたら、アップグレード履歴 タブに移動します。アップグレードログ 列で対象のアップグレードタスクの 情報を表示 をクリックすると、アップグレードプロセスの詳細を確認できます。

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

ApsaraDB RDS コンソールにログインします。上部ナビゲーションバーでインスタンスが配置されているリージョンを選択し、インスタンスを見つけてその ID をクリックします。
左側のナビゲーションウィンドウで、メジャーバージョンアップグレード をクリックします。

メジャーバージョンアップグレード が表示されない場合は、インスタンスのバージョンおよび構成を確認してください。詳細については、「前提条件」をご参照ください。
アップグレードチェック タブで、アップグレードチェックレポートの作成 をクリックします。
ターゲットバージョンを選択し、アップグレードモード を Zero Downtime に設定して、OK をクリックします。インスタンスステータスが Maintaining Instance に変化します。チェックが完了すると、ステータスは Running に戻ります。
チェック結果を確認します。チェック結果の解釈方法については、「ApsaraDB RDS for PostgreSQL メジャーバージョンアップグレードチェックレポートの解釈」をご参照ください。
- Success または Warning の場合：ステップ 2 に進みます。
- Failed の場合：情報を表示 をクリックして報告された問題を修正し、再度チェックを実行します。
重要
- 結果が Warning の場合、報告されたすべての問題を修正し、結果が Success になるまで再度チェックを実行してください。 - 成功したチェック後にプライマリインスタンスにプラグインを作成した場合は、アップグレード前に再度チェックを実行してください。

ステップ 2：アップグレードの開始

このステップを実行する前に、ステップ 1：事前アップグレードチェックの実行 を完了していることを確認してください。アップグレードチェック タブでアップグレードチェックレポートを作成し、チェック結果が Success または Warning であることを確認してから、アップグレードタスクを作成してください。

インスタンスのアップグレード タブをクリックし、警告を読み、ターゲットバージョンの選択 からバージョンを選択して、アップグレードタスクの作成 をクリックします。
ダイアログボックスでプロンプトを読み、OK をクリックします。
メジャーエンジンバージョンアップグレードタスクの作成 セクションで、アップグレードモード を Zero Downtime に設定して、作成をクリックします。

インスタンスステータスが Migrating に変化すると、アップグレードタスクが開始されています。

所要時間はインスタンス内のデータベースオブジェクト数に依存します。オブジェクト数が多いほど、時間が長くなります。タスクハブで進捗を追跡できます。

重要

アップグレードタスクは作成後に変更または削除できません。
インスタンスが Migrating 状態の間は、パラメーターの変更、再起動、リリースなどの運用管理 (O&M) タスクはサポートされません。

ステップ 3：検証およびスイッチオーバー

宛先インスタンスの検証

インスタンスステータスが Migrating から Migrating Data Out に変化すると、論理レプリケーションが確立され、宛先インスタンスの検証準備が整います。

アップグレード履歴 タブに移動し、アップグレードレコードの Later Version Verification URL を使用して宛先インスタンスに接続し、データを検証します。

このフェーズ中、宛先インスタンスは読み取り専用モードです。書き込み操作はサポートされません。

新しいバージョンへのスイッチオーバー

データが期待通りであり、かつ Upgrade Result が Synchronizing であることを確認したら、アップグレードログ 列で スイッチオーバー をクリックします。

- Upgrade Result が異なるステータスを示している場合は、「アップグレード結果の説明」をご参照ください。 - アップグレードを中止するには、アップグレードログ 列で キャンセル をクリックします。これにより、論理レプリケーションスロットが削除され、ソースインスタンスからレプリケーションオーバーヘッドが削除され、DDL 操作が再び有効になります。
スイッチオーバー ダイアログボックスで、書き込みダウンタイム許容時間 (秒単位) を設定し、OK をクリックします。この設定により、システムはスイッチオーバー完了前にレプリケーションラグが解消されるのを待ち、データ整合性を確保します。この待機中、Upgrade Result は Read-only を示します。許容期間を超えると、システムは Synchronizing に戻り、読み取り専用制限が解除されます。Upgrade Result が Read-only に変化すると、スイッチオーバーが進行中であり、インスタンスステータスは Migrating です。すでに開始されたスイッチオーバーをキャンセルするには、アップグレードログ 列で Interrupted をクリックします。
Upgrade Result が Succeeded に変化すると、スイッチオーバーが完了し、インスタンスステータスは Running になります。インスタンスの 基本情報 ページで現在のバージョンを確認します。

アップグレード後の正確な読み取り専用時間を確認するには、アップグレード履歴 タブに移動し、アップグレードログ 列で 情報を表示 をクリックします。読み取り専用時間は Switching time と Switching completion time の間隔であり、DNS キャッシュの伝搬によりインスタンスが到達不能になる時間は含まれません。

アップグレード結果の説明

アップグレード履歴 タブの アップグレード結果 列には、アップグレード中に次のいずれかの値が表示されます。

アップグレード結果	インスタンスステータス	説明	利用可能な操作
Running	Migrating	アップグレードタスクが実行中です。	なし。
Synchronizing	Migrating Data Out	論理レプリケーションは正常です。	新しいバージョンに切り替える、またはアップグレードをキャンセルする。
Replication Interrupted	Migrating Data Out	論理レプリケーションが異常です。	アップグレードログを確認して原因を特定する、またはアップグレードをキャンセルする。
Read-only	Migrating	スイッチオーバーが進行中です。シーケンスの同期中にインスタンスは読み取り専用になります。	中断：スイッチオーバーをキャンセルする。
Switchover	Migrating	シーケンスの同期が完了し、スイッチオーバーの最終処理中です。	なし。
Cancel	Running	アップグレードタスクがキャンセルされました。	なし。
Succeeded	Running	アップグレードタスクが正常に完了しました。	なし。

API リファレンス

API オペレーション	説明
UpgradeDBInstanceMajorVersionPrecheck	メジャーバージョンアップグレードの事前チェックを実行します。
DescribeUpgradeMajorVersionPrecheckTask	事前アップグレードチェックレポートを照会します。
UpgradeDBInstanceMajorVersion	メジャーエンジンバージョンをアップグレードします。
DescribeUpgradeMajorVersionTask	メジャーバージョンアップグレードタスクの履歴を照会します。

よくある質問

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

いいえ。インスタンスタイプの変更を含むインスタンスの変更は、アップグレード中はサポートされません。他の操作はアップグレード完了後に実行してください。

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

いいえ。メジャーエンジンバージョンへの自動アップグレードはサポートされていません。

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

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

メジャーバージョンアップグレード後、宛先インスタンスで raster_overviews ビューを作成すると raster_overviews の競合が発生します。これを修正するにはどうすればよいですか？

この競合は、PostGIS バージョンが 2.5.2 よりも古く、ソースインスタンスが PostgreSQL 10 または 11 で動作しており、PostgreSQL 12 にアップグレードする場合に発生することがあります。

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

以下のコマンドを 2 回実行して、成功することを確認してください。

SELECT PostGIS_Extensions_Upgrade();
SELECT PostGIS_Extensions_Upgrade();

ステップ 2：PostGIS Raster プラグインの使用状況に応じて修正方法を選択します。

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

ソースインスタンスで以下のコマンドを実行し、raster_overviews ビューを拡張からデタッチします。
```
ALTER EXTENSION PostGIS_Raster DROP VIEW raster_overviews;
CREATE OR REPLACE VIEW raster_overviews AS SELECT 1;
```
PostgreSQL インスタンスを PostgreSQL 12 以上にアップグレードします。

アップグレード後、宛先インスタンスでビューを再作成します。

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 プラグインを使用していない場合：

ソースインスタンスにプラグインをドロップします：
```
DROP EXTENSION PostGIS_Raster;
```
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;

データサブスクリプションにレプリケーションスロットを使用する方法の詳細については、「論理サブスクリプション」および「変更追跡」をご参照ください。すでにサブスクリプションデータに不整合が発生している場合は、次の FAQ をご参照ください。

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

アップグレードが成功したら、宛先インスタンス (上位バージョンで動作) 上のテーブルデータを削除し、copy_data=true でサブスクリプションを再作成します。詳細については、「ALTER SUBSCRIPTION」をご参照ください。

あるいは、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;

データ移行フェーズが予想より長引いているのはなぜですか？

データ移行フェーズ (インスタンスステータスが Migrating の間) にかかる時間は、データ量、データベースオブジェクト数、インスタンスの仕様、ネットワーク帯域幅に依存します。予想より長引いている場合は、以下を確認してください。

Cloud Monitor でのインスタンスの CPU および I/O 負荷。
pg_stat_replication ビューでのレプリケーションラグ。
ネットワーク帯域幅が上限に達していないか。

ApsaraDB RDS:ゼロダウンタイムモードを使用したメジャーバージョンのアップグレード

仕組み

課金