Migration de région

La migration de région déplace un projet existant depuis la région dans laquelle il a été créé vers une autre. Vous y recourez lorsque votre trafic s'est rapproché d'une autre région (latence aller-retour plus faible), ou lorsqu'une exigence de conformité ou de résidence des données impose que vos données vivent dans une juridiction particulière.

La migration change l'endroit où vivent vos données, pas ce qu'elles sont. Vos branches, rôles, bases de données et les lignes qu'elles contiennent sont tous repris. La seule chose qui change côté client est l'hôte dans votre chaîne de connexion — votre projet atterrit sur un nouvel hôte d'endpoint dans la région de destination, de sorte que votre DATABASE_URL doit être repointée une fois la bascule terminée.

How it works

Une migration gérée s'exécute comme une copie contrôlée et validée, avec une bascule explicite que vous approuvez. Les étapes :

1. Gel — le projet source est brièvement placé dans un état en lecture seule / suspendu pour que la copie ait une cible cohérente et immobile.
2. Dump — un dump logique de chaque branche est pris depuis la région source.
3. Transfert — le dump est déplacé vers la région de destination via TLS.
4. Restauration — le dump est restauré dans un projet fraîchement provisionné dans la région de destination.
5. Validation — la destination est vérifiée pour l'équivalence octet-à-octet avec la source : l'empreinte de schéma, le nombre de lignes par table et les sommes de contrôle de contenu doivent tous correspondre avant que la migration ne soit proposée pour la bascule.
6. Confirmation — rien ne bascule automatiquement. Vous examinez les résultats de validation et confirmez explicitement la bascule.
7. Bascule — les endpoints actifs du projet sont repointés vers la région de destination. L'hôte de la chaîne de connexion change.

Si vous annulez avant la bascule, ou si la validation échoue à une étape quelconque, la migration revient en arrière : l'échafaudage de destination est jeté et le projet source est sorti de son état en lecture seule, intact.

Size guidance

La fenêtre en lecture seule évolue avec la taille de vos données :

• Moins de 10 Go — se termine généralement en moins de 15 minutes.
• 10 à 100 Go — une fenêtre étendue ; prévoyez une période en lecture seule plus longue et planifiez-la en dehors des heures de pointe.
• Plus de 100 Go — contactez le support pour une migration assistée. Les grands projets sont migrés avec un runbook pratique plutôt qu'avec le flux en libre-service.

Managed migration (console)

La migration de région gérée est en cours de déploiement. L'assistant décrit ici est activé progressivement ; si vous ne voyez pas encore Migrate region dans les paramètres de votre projet, utilisez le runbook manuel ci-dessous, qui fonctionne sur tous les projets aujourd'hui.

L'assistant de la console parcourt le flux ci-dessus :

1. Ouvrez le projet et allez dans Settings → Migrate region.
2. Sélectionner la destination — choisissez la région cible dans la liste déroulante. La région actuelle est affichée pour référence.
3. Examiner l'impact — l'assistant résume ce qui va se passer : la fenêtre en lecture seule que le projet connaîtra, et le fait que l'hôte de la chaîne de connexion change à la bascule.
4. Suivre la progression — chaque branche affiche sa propre progression à travers dump → transfert → restauration. L'assistant diffuse le statut pendant l'exécution de la migration.
5. Examiner la validation — lorsque la copie est terminée, les résultats de validation sont affichés par branche : correspondance de l'empreinte de schéma, du nombre de lignes et de la somme de contrôle.
6. Confirmer la bascule — une fois la validation au vert, confirmez la bascule. C'est le point sans retour automatique.
7. Mettre à jour DATABASE_URL — après la bascule, copiez la nouvelle chaîne de connexion depuis la carte d'endpoint et mettez à jour la DATABASE_URL de votre application. L'hôte a changé ; tout le reste est identique.

Manual migration runbook

Ce runbook fonctionne aujourd'hui, sur tous les forfaits. Il utilise l'outillage Postgres standard et les chaînes de connexion publiques, il n'a donc aucune dépendance au flux géré. La forme est : monter un nouveau projet dans la région cible, y copier les données avec pg_dump / pg_restore, vérifier, puis repointer et supprimer l'ancien projet.

1. Create the destination project

Créez un nouveau projet dans la région cible (console New project, ou l'API). Faites correspondre la version majeure de Postgres du projet source. Notez la chaîne de connexion du nouveau projet depuis la carte d'endpoint.

2. Dump the source

Dumpez depuis la chaîne de connexion du projet source au format custom. --no-owner et --no-privileges gardent le dump portable à travers les rôles fraîchement créés dans la destination :

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

Restaurez dans la chaîne de connexion du projet destination. --single-transaction plus --exit-on-error rend la restauration tout-ou-rien : si quelque chose échoue, la destination reste propre plutôt que à moitié chargée :

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

Confirmez que la destination correspond à la source avant de basculer. Comparez le nombre de lignes par table sur les deux chaînes de connexion :

SELECT relname, n_live_tup
FROM pg_stat_user_tables
ORDER BY relname;

Pour un contrôle plus poussé, vérifiez par échantillonnage les sommes de contrôle de contenu sur les tables les plus importantes. Exécutez ceci sur la source et la destination et comparez les résultats :

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

Un nombre de lignes et des sommes de contrôle correspondants signifient que les données ont été reprises intactes.

5. Cut over and clean up

Repointez la DATABASE_URL de votre application vers la chaîne de connexion de la destination. Une fois que vous avez confirmé que l'application fonctionne correctement avec le nouveau projet, supprimez l'ancien projet pour cesser d'être facturé :

keon projects delete <old-project-id>

Supprimer un projet est irréversible — ne le faites qu'après avoir vérifié la destination et basculé tout le trafic vers elle.

FAQ

How much downtime should I expect?

Pour une migration gérée, la seule perturbation est la fenêtre en lecture seule pendant la copie — les écritures sont suspendues, les lectures continuent. La fenêtre évolue avec la taille des données (voir recommandations de taille) : moins de 15 minutes pour les projets sous 10 Go, plus longue pour les plus gros. Pour le runbook manuel, l'indisponibilité est la fenêtre que vous choisissez pour arrêter les écritures pendant que vous dumpez, restaurez et vérifiez.

Can I cancel a migration?

Oui — à tout moment avant la bascule finale. L'annulation jette l'échafaudage de destination et ramène le projet source à la normale ; la source n'est jamais modifiée tant que vous ne confirmez pas le basculement, de sorte qu'une annulation vous laisse exactement là où vous avez commencé.

What happens to my branches?

Chaque branche est migrée. Sachez qu'un dump-and-restore logique aplatit l'historique copy-on-write : chaque branche est reprise avec ses données actuelles, mais la relation fork-at-LSN entre une branche enfant et son parent n'est pas préservée — les branches de destination repartent à neuf à partir des données migrées plutôt que de partager des pages. Les données sont intactes ; la filiation de stockage partagé ne l'est pas.

Do my passwords and roles survive?

Les rôles sont recréés dans le cadre de la mise en place du projet de destination, et les données qu'ils possèdent sont reprises. Comme le runbook manuel dumpe avec --no-owner --no-privileges, la propriété des rôles et les grants ne sont pas portés par le dump — vous les réappliquez sur la destination. Traitez la parité rôle/mot de passe comme quelque chose à vérifier et à rétablir après la migration, pas comme automatique. Le flux géré recrée les rôles du projet pour vous, mais la même prudence s'applique : confirmez que le rôle de connexion et le mot de passe de votre application fonctionnent sur la destination avant la bascule.

Do my connection strings change?

Oui — l'hôte change, car votre projet se déplace vers un nouvel hôte d'endpoint dans la région de destination. Vous mettez à jour DATABASE_URL (et tout autre endroit où l'hôte est codé en dur) une fois, à la bascule. Vos clés d'API (nsk_…) sont rattachées au compte et ne sont pas affectées par une migration de région.

Is my data encrypted in transit?

Oui. Le transfert entre régions s'effectue via TLS, et le dump depuis la source comme la restauration dans la destination utilisent les connexions Postgres standard sslmode=require décrites dans Chaînes de connexion.

Related

• Régions — le catalogue entre lequel vous migrez.
• Projets — l'unité qui migre dans son ensemble.
• Chaînes de connexion — le format filaire dont l'hôte change à la bascule.
• Branches — les enfants copy-on-write, et comment dump/restore affecte leur filiation.