Migrez votre base Postgres vers Canner, avec peu ou pas d’interruption.

Vidage et restauration (canner db migrate-in) est la voie la plus simple et fonctionne avec tous les forfaits Canner. Les écritures sur l’ancienne base s’arrêtent pendant l’opération : l’interruption dure autant que la copie. Convient à une petite base, ou à une base qu’on peut mettre hors ligne pendant la nuit.

Suivi en direct (un abonnement entrant) copie les lignes existantes, puis diffuse les changements de l’ancien serveur jusqu’à la bascule. Elle exige l’instance dédiée (9 $ CA par mois par projet, tout forfait payant) et une source que vous pouvez configurer pour la réplication logique. Choisissez-la quand l’interruption doit durer quelques secondes.

Dans les deux cas, la source doit être joignable depuis Internet à une adresse publique. Une base qui n’accepte que les connexions d’un réseau privé ne fonctionnera pas tant que vous ne l’ouvrez pas à Canner.

• Créez d’abord la base Canner, dans la version de Postgres voulue (17 ou 18, fixée à la création).
• Vérifiez le bassin de stockage : la copie compte dans la limite de votre organisation. Les sauvegardes et les téléversements s’arrêtent à 100 %, et les écritures se verrouillent à 10 % au-delà.
• Listez les extensions utilisées. L’instance dédiée en offre 14 (pgvector, PostGIS, pg_trgm, pg_cron, hstore et d’autres); postgres_fdw, dblink et file_fdw ne sont pas offertes.

Canner transfère la base depuis la source sans fichier local, ce qui convient aussi aux bases trop grosses pour être téléchargées. Elle fonctionne avec tout serveur Postgres public : Supabase, Neon, Heroku, Amazon RDS, Render et d’autres.

# Transférer une base directement depuis un serveur Postgres joignable publiquement
canner db migrate-in --from postgres://user:pass@source.example.com:5432/appdb

Avec un abonnement, l’ancien serveur continue de recevoir des écritures pendant que Canner le rattrape. Vous basculez quand tout est synchronisé. Les étapes :

• Préparez la source. Elle exige wal_level = logical et un utilisateur ayant l’attribut REPLICATION. Sur un service géré, c’est un paramètre ou un réglage de rôle; la documentation du fournisseur explique comment. Créez ensuite une publication pour les tables.
• Créez d’abord les tables sur Canner. La réplication logique copie les lignes, pas le schéma. Restaurez le schéma avec les mêmes noms de tables et de colonnes.
• Activez l’accès externe pour la cible afin de vous connecter depuis votre propre poste (TLS seulement, liste d’adresses autorisées), et installez les extensions dont votre schéma a besoin sur l’instance dédiée.
• Ajoutez l’abonnement avec l’URL de la source lue depuis une variable d’environnement, pour que le mot de passe ne soit jamais affiché. Canner copie les lignes existantes, puis diffuse les changements. Vous voyez combien de tables sont synchronisées et quand le dernier changement est arrivé. Jusqu’à cinq abonnements par base.

# Sur la source : publier les tables (exige wal_level = logical et un utilisateur REPLICATION)
CREATE PUBLICATION app_pub FOR ALL TABLES;

# Copier le schéma seulement : les tables doivent d’abord exister chez Canner
export SRC_URL='postgres://repl_user:pass@source.example.com:5432/appdb'
pg_dump --schema-only --no-owner --no-privileges "$SRC_URL" | psql "$CANNER_URL"

# Suivre la source en direct (URL lue depuis une variable, jamais affichée)
canner db subscriptions appdb add legacy --from-env SRC_URL --publication app_pub

Les changements sont appliqués avec les droits du propriétaire de vos tables, jamais en superutilisateur : les déclencheurs (triggers) de vos tables s’exécutent donc avec vos droits seulement.

Les changements répliqués s’exécutent aussi avec un search_path vide. Une fonction de déclencheur doit utiliser des noms qualifiés par le schéma, par exemple public.audit plutôt que audit. Si un changement ne peut pas être appliqué (une table manquante, une ligne en conflit), l’abonnement affiche Échec, vous recevez une alerte, et il réessaie de lui-même une fois la cause corrigée.

Une publication n’inclut que les tables que vous nommez, et ajouter des tables plus tard exige d’actualiser l’abonnement. La réplication logique ne copie pas les valeurs des séquences : vérifiez les séquences après la bascule (section suivante).

• Attendez que l’abonnement soit synchronisé : toutes les tables à jour et l’heure du dernier changement récente.
• Arrêtez les écritures sur la source. Mettez l’application en mode maintenance ou dirigez-la vers un utilisateur en lecture seule, et laissez arriver les derniers changements.
• Vérifiez les séquences. Une colonne à incrémentation automatique ou d’identité repartirait de l’ancienne valeur chez Canner et provoquerait des collisions. Lisez les valeurs actuelles sur la source et appliquez-les chez Canner avec le script ci-dessous.
• Vérifiez les extensions et les déclencheurs : chaque extension est installée, et les fonctions de déclencheur utilisent des noms qualifiés par le schéma.
• Recréez les rôles. Les vidages ne portent ni propriétaires ni privilèges : créez les rôles en lecture seule ou en lecture et écriture dont vous avez besoin et réémettez les droits.
• Retirez l’abonnement. Cela retire le slot sur la source; si la source n’existe plus, utilisez --force.
• Dirigez l’application vers Canner. DATABASE_URL est injectée au prochain déploiement : redéployez, puis lancez vos tests de fumée.
• Activez les sauvegardes tout de suite, et envisagez la récupération à un instant précis et une copie hors site.

-- À exécuter sur la SOURCE. Affiche une instruction setval() par séquence.
SELECT format('SELECT setval(%L, %s, true);',
              quote_ident(schemaname) || '.' || quote_ident(sequencename),
              last_value)
FROM pg_sequences
WHERE last_value IS NOT NULL;
-- Exécutez les instructions affichées sur la base Canner.

Elles viennent de la documentation de chaque fournisseur. Les réglages et les menus changent : suivez le guide actuel du fournisseur pour les étapes exactes.