リージョン移行

リージョン移行 は、既存のプロジェクトを作成時の リージョン から別のリージョンへ移動します。トラフィックが別のリージョンに近づいた（ラウンドトリップ レイテンシが下がる）ときや、コンプライアンスやデータレジデンシー要件によりデータが特定の 管轄区域に存在しなければならないときに利用します。

移行はデータが どこ に存在するかを変えるものであり、データが 何 であるかは変えません。 ブランチ、ロール、データベース、そしてその中の行はすべて引き継がれます。クライアント側で変わる 唯一のものは、接続文字列内の ホスト です — プロジェクトは移行先リージョンの新しい エンドポイントホストに着地するため、カットオーバーが完了したら DATABASE_URL を一度 付け替える必要があります。

How it works

マネージド移行は、あなたが明示的に承認するカットオーバーを伴う、制御され検証されたコピーとして 実行されます。各ステージ:

1. フリーズ — コピーが一貫した、動かない対象を得られるように、移行元プロジェクトを 短時間だけ読み取り専用 / 一時停止状態にします。
2. ダンプ — 移行元リージョンからすべてのブランチの論理ダンプを取得します。
3. 転送 — ダンプを TLS 経由で移行先リージョンへ移動します。
4. リストア — ダンプを移行先リージョンに新しくプロビジョニングされたプロジェクトへ リストアします。
5. 検証 — 移行先が移行元に対してバイト等価かどうかを確認します。スキーマフィンガープリント、 テーブルごとの行数、コンテンツチェックサムがすべて一致してから、移行がカットオーバー向けに 提示されます。
6. 確認 — 自動では何も切り替わりません。検証結果を確認し、カットオーバーを明示的に承認します。
7. カットオーバー — プロジェクトのアクティブなエンドポイントが移行先リージョンへ 付け替えられます。接続文字列のホストが変わります。

カットオーバー前にキャンセルした場合、またはいずれかのステージで検証が失敗した場合、移行は ロールバック されます。移行先の足場は破棄され、移行元プロジェクトは読み取り専用状態から 戻され、変更されません。

Size guidance

読み取り専用ウィンドウはデータのサイズに応じてスケールします。

• 10 GB 未満 — 通常 15 分以内に完了します。
• 10〜100 GB — 延長ウィンドウ。より長い読み取り専用期間を見込み、ピーク時間外に スケジュールしてください。
• 100 GB 超 — アシスト付き移行については サポートに連絡 してください。 大規模プロジェクトは、セルフサービスフローではなく実地のランブックで移行されます。

Managed migration (console)

マネージドリージョン移行は 段階的に展開中 です。ここで説明するウィザードは順次有効化されて います。プロジェクト設定にまだ Migrate region が表示されない場合は、下記の 手動ランブック を使ってください。これは今日すべての プロジェクトで動作します。

コンソールウィザードは上記のフローを案内します。

1. プロジェクトを開き、Settings → Migrate region に移動します。
2. 移行先の選択 — ドロップダウンからターゲットリージョンを選びます。現在のリージョンが 参考として表示されます。
3. 影響の確認 — ウィザードがこれから起こることを要約します。プロジェクトが経験する 読み取り専用ウィンドウと、カットオーバー時に接続文字列のホストが変わるという事実です。
4. 進捗の監視 — 各ブランチがダンプ → 転送 → リストアの進捗を個別に表示します。移行の実行に 合わせてウィザードがステータスをストリーミングします。
5. 検証の確認 — コピーが完了すると、検証結果がブランチごとに表示されます。スキーマ フィンガープリントの一致、行数の一致、チェックサムの一致です。
6. 切り替えの確認 — 検証がグリーンになったら、カットオーバーを承認します。これが自動では 戻れない地点です。
7. DATABASE_URL の更新 — カットオーバー後、エンドポイントカードから新しい接続文字列を コピーし、アプリケーションの DATABASE_URL を更新します。ホストが変わっています。それ以外は 同じです。

Manual migration runbook

このランブックは 今日、どのプランでも 動作します。標準的な Postgres ツールとパブリックな 接続文字列を使うため、マネージドフローに依存しません。流れは次のとおりです。ターゲット リージョンに新しいプロジェクトを立ち上げ、pg_dump / pg_restore でデータをコピーし、検証し、 それから付け替えて古いプロジェクトを削除します。

1. Create the destination project

ターゲット リージョン に新しいプロジェクトを作成します（コンソールの New project、または API）。移行元プロジェクトの Postgres メジャーバージョンに合わせます。 エンドポイントカードから新しいプロジェクトの接続文字列を控えます。

2. Dump the source

移行元 プロジェクトの接続文字列からカスタム形式でダンプします。--no-owner と --no-privileges により、ダンプは移行先で新しく作成されたロール間で移植可能になります。

pg_dump \
  --format=custom \
  --no-owner \
  --no-privileges \
  "postgresql://app:SOURCE_PWD@ep_SOURCE.kisenon.com:5432/main?sslmode=require" \
  --file=migration.dump

3. Restore into the destination

移行先 プロジェクトの接続文字列へリストアします。--single-transaction に --exit-on-error を加えることで、リストアはオールオアナッシングになります。何かが失敗しても、 移行先は中途半端にロードされるのではなくクリーンなまま残ります。

pg_restore \
  --no-owner \
  --no-privileges \
  --single-transaction \
  --exit-on-error \
  --dbname "postgresql://app:DEST_PWD@ep_DEST.kisenon.com:5432/main?sslmode=require" \
  migration.dump

4. Verify

カットオーバーの前に、移行先が移行元と一致することを確認します。両方の接続文字列に対して テーブルごとの行数を比較します。

SELECT relname, n_live_tup
FROM pg_stat_user_tables
ORDER BY relname;

より強力なチェックのために、最も重要なテーブルでコンテンツチェックサムをスポットチェックします。 これを移行元と移行先の両方に対して実行し、結果を比較します。

SELECT md5(string_agg(t::text, '' ORDER BY t)) AS checksum
FROM my_table AS t;

行数とチェックサムが一致すれば、データはそのまま引き継がれています。

5. Cut over and clean up

アプリケーションの DATABASE_URL を移行先の接続文字列に付け替えます。新しいプロジェクトに対して アプリケーションが正常であることを確認したら、課金を止めるために古いプロジェクトを削除します。

keon projects delete <old-project-id>

プロジェクトの削除は取り消せません。移行先を検証し、すべてのトラフィックをそちらへ切り替えた後に のみ実行してください。

FAQ

How much downtime should I expect?

マネージド移行の場合、唯一の中断はコピー中の読み取り専用ウィンドウです。書き込みは一時停止し、 読み取りは継続します。ウィンドウはデータサイズに応じてスケールします（サイズの目安 を参照）。10 GB 未満のプロジェクトでは 15 分未満、より大きいものではより長くなります。手動 ランブックの場合、ダウンタイムはダンプ、リストア、検証の間に書き込みを止めるために選んだ ウィンドウです。

Can I cancel a migration?

はい — 最終カットオーバーの前 であればいつでも。キャンセルすると移行先の足場が破棄され、 移行元プロジェクトは通常に戻ります。切り替えを承認するまで移行元は決して変更されないため、 キャンセルすれば開始時とまったく同じ場所に残ります。

What happens to my branches?

すべてのブランチが移行されます。論理ダンプとリストアはコピーオンライトの履歴を フラット化 する 点に注意してください。各ブランチは現在のデータとともに引き継がれますが、子ブランチとその親の間の fork-at-LSN 関係は保持されません — 移行先のブランチはページを共有するのではなく、移行された データから新しく始まります。データはそのままですが、共有ストレージの系譜は失われます。

Do my passwords and roles survive?

ロールは移行先プロジェクトを立ち上げる一部として再作成され、それらが所有するデータは引き継がれ ます。手動ランブックは --no-owner --no-privileges でダンプするため、ロールの所有権とグラントは ダンプによって 引き継がれません — 移行先で再適用します。ロール / パスワードの整合性は移行後に 検証し再確立すべきものとして扱い、自動的なものとは考えないでください。マネージドフローは プロジェクトのロールを再作成しますが、同じ注意が当てはまります。カットオーバー前に、 アプリケーションのログインロールとパスワードが移行先で機能することを確認してください。

Do my connection strings change?

はい — ホスト が変わります。プロジェクトが移行先リージョンの新しいエンドポイントホストへ 移動するためです。カットオーバー時に一度、DATABASE_URL（およびホストがハードコードされている 他のすべての場所）を更新します。API キー（nsk_…）はアカウントスコープであり、リージョン移行の 影響を 受けません。

Is my data encrypted in transit?

はい。リージョン間の転送は TLS 経由で実行され、移行元からのダンプと移行先へのリストアの両方が、 接続文字列 で説明されている標準の sslmode=require Postgres 接続を 使用します。

Related

• リージョン — 移行元と移行先のカタログ。
• プロジェクト — 全体として移行される単位。
• 接続文字列 — カットオーバー時にホストが変わるワイヤー形式。
• ブランチ — コピーオンライトの子と、ダンプ / リストアがその系譜に 与える影響。