Regionsmigration

Regionsmigration verschiebt ein bestehendes Projekt aus der Region, in der es erstellt wurde, in eine andere. Sie greifen darauf zurück, wenn sich Ihr Traffic näher an eine andere Region verlagert hat (geringere Round-Trip-Latenz) oder wenn eine Compliance- oder Datenresidenz-Anforderung vorschreibt, dass Ihre Daten in einer bestimmten Rechtsordnung liegen müssen.

Die Migration ändert, wo Ihre Daten liegen, nicht was sie sind. Ihre Branches, Rollen, Datenbanken und die darin enthaltenen Zeilen werden alle übernommen. Das Einzige, was sich auf der Client-Seite ändert, ist der Host in Ihrer Verbindungszeichenfolge — Ihr Projekt landet auf einem neuen Endpoint-Host in der Zielregion, sodass Ihre DATABASE_URL neu ausgerichtet werden muss, sobald die Umstellung abgeschlossen ist.

How it works

Eine verwaltete Migration läuft als kontrollierte, validierte Kopie mit einer expliziten Umstellung ab, die Sie genehmigen. Die Phasen:

1. Freeze — das Quellprojekt wird kurz in einen schreibgeschützten / ausgesetzten Zustand versetzt, damit die Kopie ein konsistentes, unbewegliches Ziel hat.
2. Dump — ein logischer Dump jedes Branches wird aus der Quellregion erstellt.
3. Transfer — der Dump wird über TLS in die Zielregion verschoben.
4. Restore — der Dump wird in ein frisch bereitgestelltes Projekt in der Zielregion wiederhergestellt.
5. Validate — das Ziel wird auf Byte-Äquivalenz mit der Quelle geprüft: Schema-Fingerabdruck, Zeilenzahlen pro Tabelle und Inhalts-Prüfsummen müssen alle übereinstimmen, bevor die Migration zur Umstellung angeboten wird.
6. Confirm — nichts schaltet automatisch um. Sie prüfen die Validierungsergebnisse und bestätigen die Umstellung ausdrücklich.
7. Cutover — die aktiven Endpoints des Projekts werden auf die Zielregion umgeleitet. Der Host der Verbindungszeichenfolge ändert sich.

Wenn Sie vor der Umstellung abbrechen oder wenn die Validierung in irgendeiner Phase fehlschlägt, wird die Migration zurückgerollt: das Ziel-Gerüst wird verworfen und das Quellprojekt wird aus seinem schreibgeschützten Zustand geholt, unverändert.

Size guidance

Das schreibgeschützte Zeitfenster skaliert mit der Größe Ihrer Daten:

• Unter 10 GB — wird typischerweise in unter 15 Minuten abgeschlossen.
• 10–100 GB — ein erweitertes Zeitfenster; planen Sie eine längere schreibgeschützte Phase ein und legen Sie sie außerhalb der Spitzenzeiten.
• Über 100 GB — kontaktieren Sie den Support für eine begleitete Migration. Große Projekte werden mit einem handgeführten Runbook statt mit dem Self-Service-Ablauf migriert.

Managed migration (console)

Die verwaltete Regionsmigration wird schrittweise ausgerollt. Der hier beschriebene Assistent wird nach und nach aktiviert; wenn Sie Migrate region in Ihren Projekteinstellungen noch nicht sehen, verwenden Sie das manuelle Runbook unten, das heute für jedes Projekt funktioniert.

Der Konsolen-Assistent führt durch den obigen Ablauf:

1. Öffnen Sie das Projekt und gehen Sie zu Settings → Migrate region.
2. Ziel auswählen — wählen Sie die Zielregion aus der Dropdown-Liste. Die aktuelle Region wird zur Referenz angezeigt.
3. Auswirkungen prüfen — der Assistent fasst zusammen, was gleich passieren wird: das schreibgeschützte Zeitfenster, das das Projekt erleben wird, und die Tatsache, dass sich der Host der Verbindungszeichenfolge bei der Umstellung ändert.
4. Fortschritt überwachen — jeder Branch zeigt seinen eigenen Fortschritt durch Dump → Transfer → Restore. Der Assistent streamt den Status während des Migrationslaufs.
5. Validierung prüfen — wenn die Kopie abgeschlossen ist, werden die Validierungsergebnisse pro Branch angezeigt: Übereinstimmung des Schema-Fingerabdrucks, der Zeilenzahl und der Prüfsumme.
6. Umschaltung bestätigen — sobald die Validierung grün ist, bestätigen Sie die Umstellung. Dies ist der Punkt ohne automatische Rückkehr.
7. DATABASE_URL aktualisieren — kopieren Sie nach der Umstellung die neue Verbindungszeichenfolge von der Endpoint-Karte und aktualisieren Sie die DATABASE_URL Ihrer Anwendung. Der Host hat sich geändert; alles andere bleibt gleich.

Manual migration runbook

Dieses Runbook funktioniert heute, in jedem Tarif. Es verwendet Standard-Postgres-Werkzeuge und die öffentlichen Verbindungszeichenfolgen und hat daher keine Abhängigkeit vom verwalteten Ablauf. Die Form ist: ein neues Projekt in der Zielregion aufsetzen, die Daten mit pg_dump / pg_restore hineinkopieren, verifizieren, dann neu ausrichten und das alte Projekt löschen.

1. Create the destination project

Erstellen Sie ein neues Projekt in der Ziel-Region (Konsole New project oder die API). Stimmen Sie die Postgres- Hauptversion des Quellprojekts ab. Notieren Sie die Verbindungszeichenfolge des neuen Projekts von der Endpoint-Karte.

2. Dump the source

Dumpen Sie aus der Verbindungszeichenfolge des Quell-Projekts im Custom-Format. --no-owner und --no-privileges halten den Dump über die frisch erstellten Rollen im Ziel hinweg portabel:

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

Stellen Sie in die Verbindungszeichenfolge des Ziel-Projekts wieder her. --single-transaction plus --exit-on-error macht die Wiederherstellung zu einem Alles-oder-Nichts-Vorgang: wenn etwas fehlschlägt, bleibt das Ziel sauber statt halb geladen:

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

Bestätigen Sie, dass das Ziel mit der Quelle übereinstimmt, bevor Sie umstellen. Vergleichen Sie die Zeilenzahlen pro Tabelle gegen beide Verbindungszeichenfolgen:

SELECT relname, n_live_tup
FROM pg_stat_user_tables
ORDER BY relname;

Für eine stärkere Prüfung stichproben Sie Inhalts-Prüfsummen auf den wichtigsten Tabellen. Führen Sie dies gegen Quelle und Ziel aus und vergleichen Sie die Ergebnisse:

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

Übereinstimmende Zeilenzahlen und Prüfsummen bedeuten, dass die Daten unversehrt übernommen wurden.

5. Cut over and clean up

Richten Sie die DATABASE_URL Ihrer Anwendung auf die Verbindungszeichenfolge des Ziels neu aus. Sobald Sie bestätigt haben, dass die Anwendung gegen das neue Projekt fehlerfrei läuft, löschen Sie das alte Projekt, um die Abrechnung dafür zu beenden:

keon projects delete <old-project-id>

Das Löschen eines Projekts ist unumkehrbar — tun Sie dies erst, nachdem Sie das Ziel verifiziert und den gesamten Traffic darauf umgeschaltet haben.

FAQ

How much downtime should I expect?

Bei einer verwalteten Migration ist die einzige Störung das schreibgeschützte Zeitfenster während der Kopie — Schreibvorgänge werden pausiert, Lesevorgänge laufen weiter. Das Zeitfenster skaliert mit der Datengröße (siehe Größenrichtwerte): unter 15 Minuten für Projekte unter 10 GB, länger für größere. Beim manuellen Runbook ist die Ausfallzeit das Zeitfenster, das Sie wählen, um Schreibvorgänge zu stoppen, während Sie dumpen, wiederherstellen und verifizieren.

Can I cancel a migration?

Ja — jederzeit vor der finalen Umstellung. Ein Abbruch verwirft das Ziel-Gerüst und versetzt das Quellprojekt in den Normalzustand zurück; die Quelle wird nie verändert, bis Sie die Umschaltung bestätigen, sodass ein Abbruch Sie genau dort zurücklässt, wo Sie begonnen haben.

What happens to my branches?

Jeder Branch wird migriert. Beachten Sie, dass ein logisches Dump-und- Restore die Copy-on-Write-Historie abflacht: jeder Branch wird mit seinen aktuellen Daten übernommen, aber die Fork-at-LSN-Beziehung zwischen einem Child-Branch und seinem Parent bleibt nicht erhalten — die Ziel-Branches starten frisch aus den migrierten Daten, statt Pages zu teilen. Die Daten sind unversehrt; die geteilte Speicher-Abstammung nicht.

Do my passwords and roles survive?

Rollen werden als Teil des Aufsetzens des Zielprojekts neu erstellt, und die Daten, die sie besitzen, werden übernommen. Da das manuelle Runbook mit --no-owner --no-privileges dumpt, werden Rollen-Eigentümerschaft und Grants vom Dump nicht übertragen — Sie wenden sie auf dem Ziel erneut an. Behandeln Sie die Rollen-/Passwort-Parität als etwas, das nach der Migration zu verifizieren und wiederherzustellen ist, nicht als automatisch. Der verwaltete Ablauf erstellt die Rollen des Projekts für Sie neu, aber dieselbe Vorsicht gilt: bestätigen Sie, dass die Login-Rolle und das Passwort Ihrer Anwendung gegen das Ziel funktionieren, bevor Sie umstellen.

Do my connection strings change?

Ja — der Host ändert sich, weil Ihr Projekt auf einen neuen Endpoint-Host in der Zielregion umzieht. Sie aktualisieren DATABASE_URL (und jede andere Stelle, an der der Host fest verdrahtet ist) einmal, bei der Umstellung. Ihre API-Schlüssel (nsk_…) sind kontenbezogen und werden von einer Regionsmigration nicht beeinflusst.

Is my data encrypted in transit?

Ja. Der Transfer zwischen Regionen läuft über TLS, und sowohl der Dump aus der Quelle als auch die Wiederherstellung in das Ziel verwenden die standardmäßigen sslmode=require-Postgres-Verbindungen, die in Verbindungszeichenfolgen beschrieben sind.

Related

• Regionen — der Katalog, zwischen dem Sie migrieren.
• Projekte — die Einheit, die als Ganzes migriert.
• Verbindungszeichenfolgen — das Wire-Format, dessen Host sich bei der Umstellung ändert.
• Branches — Copy-on-Write-Children und wie Dump/Restore ihre Abstammung beeinflusst.