PG16 アップグレードサービス別パラメータ：online-karte-service

手順本体は Cloneリハーサル版 / 本番実施版 / staging-direct版を参照（本書は固有値と実施記録のみ）。 ⚠️ 本サービスは GCP Datastream（外部CDC）を利用する。eligibility と異なり、Blue/Green で 外部 replication slot / publication の取り扱いが必須（→ §5 外部CDC対応）。

対象サービス: online-karte-service担当: SRE（yusaku.ishizawa） / Datastream 運用・合意先: 渥美さん／加藤さん（正確な担当は要確認） 最終更新: 2026-06-24

1. 環境・接続

項目	staging	production
AWS プロファイル（`P`）	`staging-admin`	書き込み権限のある production プロファイル（⚠️ read-only 不可）
リージョン（`R`）	`ap-northeast-1`	`ap-northeast-1`
Secrets Manager Secret ID	`<確認: secret-id>`	`<確認: secret-id>`
DB 名（psql `dbname`）	`<確認: db_name>`	`<確認: db_name>`
踏み台（bastion・SSM port-forward）	`<確認: describe-instances で特定>`	`<確認: describe-instances で特定。DB SG inbound に含まれる踏み台を使う>`
接続方式	`<確認>`	同左

2. クラスタ構成（アップグレード対象）

項目	値
クラスタ識別子（`SOURCE_CL`）	`<確認: online-karte-service の cluster-id>`
インスタンス構成	`<確認: describe-db-clusters の Members で Writer/Reader 台数>`
インスタンスクラス	`<確認: describe-db-instances>`
VPC Security Group	`<確認>`
現行エンジン	`13.x`（`<確認>`）
target エンジン	`16.13`

⚠️ Reader がいる場合、フェーズB の再起動は Reader→Writer の順で1台ずつ。台数を実機で確認。

3. パラメータグループ

役割	名前	family
ソース側 custom CPG（PG13）	`<確認: 現行 custom CPG>`	`aurora-postgresql13`
ターゲット側 Cluster/Instance PG（PG16）	`online-karte-service-pg16`	`aurora-postgresql16`

rds.logical_replication=1（Datastream 利用のため source は既に on の想定＝フェーズB の再起動が不要な可能性。実機で確認）/ wal_sender_timeout=0。
shared_preload_libraries: source の現値（pgaudit 等を含む場合あり）に pg_stat_statements を追加し、PG16 ターゲット CPG にも同値を揃える。
PG16 ターゲット CPG は #13923 / terraform_for_aws #2217 で作成（online-karte-service-pg16、pgaudit 同梱）。

4. 使用拡張・後処理の該当有無

項目	該当	備考
インストール拡張（`\dx`）	`<確認: \dx>`	クローン検証時に確認した内容を反映
pg_stat_statements	要	preload 済み・別途 `CREATE EXTENSION`
外部CDC（GCP Datastream）	使用	→ §5

5. 外部CDC（GCP Datastream）対応 ★online-karte 固有・最重要

背景: Blue/Green では 外部レプリ用の replication slot / publication は新 Green（PG16）へ引き継がれない。再作成時に Datastream が バックフィル（全テーブル再読込） を始める場合があり、本番はデータ量が大きくメンテ枠内に終わらないおそれがある。汎用説明はプレフライトチェックリスト A-2 を参照。

監視・連携先（固有値）

項目	staging	production
GCP Datastream プロジェクト	`fd-datastream-stg`	`fd-datastream-prd`
エラー通知 Slack	`#fdt-online-karte-error-dev`	`#fdt-online-karte-error-prod`
logical slot 名	`<確認: pg_replication_slots で取得>`	`<確認>`
publication 名	`<確認: pg_publication で取得（FOR ALL TABLES の想定）>`	`<確認>`

⚠️ BG 作成前の重大な前提: source に 外部 logical replication（Datastream の slot ＋ publication）が存在すると Blue/Green 作成自体が失敗する（Replica creation is canceled due to external replication）。クローン検証（mental-online-karte #13732）で実証済み。BG 作成前に slot/publication の扱いを Datastream 運用担当（渥美さん／加藤さん。正確な担当は要確認）と合意すること（停止→drop→切替後に再作成・再開、等）。

5-1. 事前判定（read-only / preflight 連携）

preflight A-2 の判定SQL一式を online-karte DB で実行し、CDC の実体を把握する。

sql

SELECT slot_name, plugin, slot_type, active, restart_lsn FROM pg_replication_slots;  -- Datastream の slot
SELECT pubname, puballtables, pubinsert, pubupdate, pubdelete FROM pg_publication;    -- 購読リスト
SELECT application_name, state, client_addr, sync_state FROM pg_stat_replication;     -- 配信中の walsender
SHOW rds.logical_replication;  -- on の想定

期待: いずれも行が出る／on（eligibility は全0・off で非該当だった）。取得した slot/publication 名を上表へ記録。
GCP 側でも fd-datastream-stg/prd の stream / connection profile が本 Aurora を指していることを確認。

5-2. staging で backfill を実測（staging-direct リハーサル時）

procedure-staging-direct の BG→Switchover を online-karte staging で実施し、バックフィルの有無・所要時間を計測する。

（Datastream 運用担当：渥美さん／加藤さんと）切替前に Datastream ストリームを一時停止。
BG 作成（slot/publication の扱いは 5-0 の合意に従う）→ Green 検証 → Switchover。
Switchover 後、新 PG16 で slot/publication を再作成 → Datastream を再開。
GCP コンソール（fd-datastream-stg）でストリームが Backfill 状態に入るか・完了まで何分かを計測。#fdt-online-karte-error-dev のエラーも監視。
計測結果（backfill 有無・所要・再開可否）を §9 実施記録へ。本番はデータ量が大きいので staging 実測より長くなる前提で枠を見積もる。

参考実績（@takahiro-oga 共有・2026-06-24）:
初回 Datastream セットアップ時のバックフィルは約 1時間20分（当時の作業ログ）。枠見積りの初期値に使う（その後データ増のため現在は延びている前提で要再実測）。
バックフィルの実行ジョブ数（並列度）を上げると短縮できる余地あり。DB 負荷は上がるが、メンテ中はほぼ無風のため攻めやすい。並列度の引き上げは別途検討（事前に staging で負荷と所要のトレードオフを確認）。
参考資料: Slack 作業ログ / Notion: github Datastream→DB

5-3. 本番切替時のコンティンジェンシー（停止→再開）

切替前: fd-datastream-prd のストリームを一時停止（渥美さん／加藤さん）。
Switchover 後（D-5 前後）: 新 PG16 で slot/publication を再作成 → ストリーム再開。
再開時に 差分(CDC)から継続できれば枠は短く済む。backfill 必須なら別枠で流す等の段取り（5-2 の実測で判断）。
切替中〜切替後は #fdt-online-karte-error-prod ＋ GCP コンソールで停止/エラー/ラグを確認。
関連: procedure-production D-5（BG 用 slot の解消確認＋外部レプリ slot の別途復旧）。

6. Blue/Green 名・スナップショット名

項目	値
Blue/Green 名（本番）	`<cluster-id>-bg`
Switchover 前スナップショット	`<cluster-id>-pre-pg16-<YYYYMMDDHHMM>`

7. 整合確認テーブル（Green/Switchover 後の件数確認）

sql

-- online-karte-service 固有の主要テーブルを列挙（要確認）
SELECT COUNT(*) FROM <table_a>;
SELECT COUNT(*) FROM <table_b>;

8. Terraform 整合対象（Switchover 後）

rds_engine_version を 13.x → 16.13、parameter group family を aurora-postgresql16（online-karte-service-pg16 参照）へ。
terraform plan に downgrade / replace（ForceNew）が出ないことを確認してから apply。

9. 実施記録

日付	環境	フェーズ	結果・所要・気付き
2026-06	staging（clone）	リハーサル	Clone から BG 作成。外部 Datastream slot/publication があり BG 作成が失敗 → slot/publication を drop して成功（#13732）。Green 作成約31分。
（参考）初回構築時	production	Datastream 構築	初回バックフィル約1時間20分（@takahiro-oga 共有）。現在はデータ増で延びている前提。並列ジョブ数引き上げで短縮余地あり（§5-2 参考資料）。
`<YYYY-MM-DD>`	staging	staging-direct	`<backfill 有無・所要・再開可否を記録>`
`<YYYY-MM-DD>`	production	本番	`<メンテ枠 / snapshot 名 / Datastream 再開結果>`

10. 関連 Issue / PR

棚卸し・方針: mental-online-karte #13044
クローン→BG 検証記録: mental-online-karte #13732
PG16 ターゲット CPG（online-karte-service-pg16）: mental-online-karte #13923 / terraform_for_aws #2217
Datastream 初回構築の作業ログ（バックフィル所要約1時間20分）: Slack
Datastream→DB 連携の設計資料: Notion: github Datastream→DB

PG16 アップグレード サービス別パラメータ：online-karte-service ​

1. 環境・接続 ​

2. クラスタ構成（アップグレード対象） ​

3. パラメータグループ ​

4. 使用拡張・後処理の該当有無 ​

5. 外部CDC（GCP Datastream）対応 ★online-karte 固有・最重要 ​

5-1. 事前判定（read-only / preflight 連携） ​

5-2. staging で backfill を実測（staging-direct リハーサル時） ​

5-3. 本番切替時のコンティンジェンシー（停止→再開） ​

6. Blue/Green 名・スナップショット名 ​

7. 整合確認テーブル（Green/Switchover 後の件数確認） ​

8. Terraform 整合対象（Switchover 後） ​

9. 実施記録 ​

10. 関連 Issue / PR ​