ゼロダウンタイムモードによるメジャーバージョンのアップグレード - ApsaraDB RDS

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

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

仕組み

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

課金

無料です。

前提条件

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

インスタンスが ApsaraDB RDS for PostgreSQL 16 またはそれ以前のバージョンを実行していること。
ストレージタイプがクラウドディスクであること。パフォーマンス専有型ローカルディスクを採用しているインスタンスは、ブルーグリーンデプロイメントモードのみ使用可能です。
課金方法が従量課金またはサブスクリプションであること。サーバーレスインスタンスは、ブルーグリーンデプロイメントモードのみ使用可能です。
インスタンスが読み取り専用インスタンスまたは専用クラスターインスタンスでないこと。
wal_level パラメーターが logical に設定されていること。設定されていない場合は、インスタンスのパラメーターを変更してから続行してください。
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 をクリックします。
左側のナビゲーションウィンドウで、メジャーバージョンアップグレード をクリックします。
メジャーバージョンアップグレード が表示されない場合は、インスタンスのバージョンおよび構成を確認してください。詳細については、「前提条件」をご参照ください。
アップグレードチェック タブで、アップグレードチェックレポートの作成 をクリックします。
宛先バージョンを選択し、アップグレードモード を ゼロダウンタイム に設定して、OK をクリックします。インスタンスのステータスが インスタンスメンテナンス中 に変更されます。チェック完了後、ステータスは 実行中 に戻ります。
チェック結果を確認します。チェック結果の解釈方法については、「ApsaraDB RDS for PostgreSQL のメジャーバージョンアップグレードチェックレポートの解釈方法」をご参照ください。
- 成功または警告の場合：ステップ 2 に進んでください。
- 失敗の場合：情報の表示 をクリックし、報告された問題を修正したうえで、再度チェックを実行してください。
重要
- 結果が警告の場合は、すべての報告された問題を修正し、結果が成功になるまでチェックを再実行してください。 - 成功したチェック後にプライマリインスタンス上でプラグインを作成した場合は、アップグレード前に再度チェックを実行してください。

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

インスタンスのアップグレード タブをクリックし、警告メッセージを確認したうえで、宛先バージョンの選択 からバージョンを選択し、アップグレードタスクの作成 をクリックします。
ダイアログボックスで案内メッセージを確認し、OK をクリックします。
メジャーエンジンバージョンアップグレードタスクの作成 セクションで、アップグレードモード を ゼロダウンタイム に設定し、作成をクリックします。

インスタンスのステータスが 移行中 に変更された場合、アップグレードタスクが開始されています。

所要時間は、インスタンス内のデータベースオブジェクトの数に依存します。オブジェクト数が多いほど、時間がかかります。進行状況は、「タスクハブ」で確認できます。

重要

作成後のアップグレードタスクは、変更または削除できません。
インスタンスが 移行中 ステータスの間は、パラメーターの変更、再起動、インスタンスのリリースなどの O&M（運用・保守）タスクはサポートされていません。

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

宛先インスタンスの検証

インスタンスのステータスが 移行中 から データ送出中 に変更された時点で、論理レプリケーションが確立され、宛先インスタンスの検証が可能になります。

アップグレード履歴 タブに移動し、アップグレード記録から 後方互換バージョン検証 URL を使用して宛先インスタンスに接続し、データを検証してください。

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

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

データが期待通りであることを確認し、アップグレード結果 が 同期中 と表示されたら、スイッチオーバー を アップグレードログ 列でクリックします。
- アップグレード結果 が異なるステータスを示す場合は、「アップグレード結果の説明」をご参照ください。 - アップグレードを中止する場合は、キャンセル を アップグレードログ 列でクリックしてください。これにより、論理レプリケーションスロットが削除され、ソースインスタンスのレプリケーションオーバーヘッドが解消され、DDL 操作が再び有効になります。
スイッチオーバー ダイアログボックスで、書き込みダウンタイム許容値（秒単位）を設定し、OK をクリックします。この設定により、システムはスイッチオーバー完了前にレプリケーションラグの解消を待機し、データ整合性を確保します。この待機中は、アップグレード結果 が 読み取り専用 と表示されます。許容期間を超えた場合、システムは 同期中 に戻り、読み取り専用制限が解除されます。アップグレード結果 が 読み取り専用 に変更された時点で、スイッチオーバーが進行中であり、インスタンスのステータスは 移行中 となります。すでに開始されたスイッチオーバーを中止するには、中断を アップグレードログ 列でクリックしてください。
アップグレード結果 が成功に変更された場合、スイッチオーバーが完了し、インスタンスのステータスは 実行中 になります。インスタンスの 基本情報 ページで、現在のバージョンを確認してください。
アップグレード後の正確な読み取り専用期間を確認するには、アップグレード履歴 タブに移動し、情報の表示 を アップグレードログ 列でクリックしてください。切り替え時間 と 切り替え完了時間 の間隔が読み取り専用時間であり、DNS キャッシュ伝搬によるインスタンス到達不能時間は含まれません。

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

アップグレード結果 列は、アップグレード履歴 タブ上で、アップグレード中のいずれかの値を表示します。

アップグレード結果	インスタンスステータス	説明	利用可能な操作
実行中	移行中	アップグレードタスクが実行中です。	操作はありません。
同期中	データ送出中	論理レプリケーションが正常です。	新バージョンへのスイッチオーバー、またはアップグレードの中止。
レプリケーション中断	データ送出中	論理レプリケーションが異常です。	アップグレードログを確認して原因を特定する、またはアップグレードを中止する。
読み取り専用	移行中	スイッチオーバーが進行中です。シーケンスの同期中は、インスタンスが読み取り専用になります。	中断：スイッチオーバーの中止。
スイッチオーバー	移行中	シーケンス同期が完了し、スイッチオーバーの最終処理が行われています。	なし。
キャンセル	実行中	アップグレードタスクがキャンセルされました。	操作はありません。
成功	実行中	アップグレードタスクが正常に完了しました。	なし。

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;

ApsaraDB RDS:ゼロダウンタイムモードによるメジャーバージョンのアップグレード

仕組み

課金