Migrer vers Postgres Canner.

Quelle voie choisir

Vidage et restauration (migration entrante) est la voie la plus simple et fonctionne avec toute base 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.

Suivre 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. Les détails sur l’instance sont dans Bases de données Postgres.

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

Avant de commencer

• Provisionnez d’abord la base Canner, avec la version de Postgres voulue (17 ou 18). Elle se choisit à la création.
• Vérifiez le stockage groupé : la copie compte dans la limite de votre organisation (forfaits et limites). Les sauvegardes et téléversements s’arrêtent à 100 %, et les écritures dans les bases se verrouillent à 10 % de dépassement.
• Dressez la liste des 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.

Voie 1 : vidage et restauration avec la migration entrante

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

Canner transfère la base depuis la source en continu, sans fichier local : c’est pourquoi cela convient aux bases trop grosses à télécharger. La base cible doit être vide, sauf si vous choisissez de la remplacer, auquel cas Canner prend d’abord un instantané du contenu précédent. La restauration est atomique : en cas d’échec, la base Canner reste exactement comme avant. Si vous avez déjà un vidage, canner db import backup.dump accepte un fichier pg_dump au format personnalisé (créez-le avec pg_dump --format=custom --no-owner).

Les valeurs de séquences, les index, les contraintes et les données viennent avec un vidage. Les propriétaires et les privilèges, non : les objets appartiennent au rôle de votre base Canner, et vous configurez les autres rôles ensuite.

Voie 2 : suivre l’ancien serveur en direct

1. Préparer 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; voyez la documentation du fournisseur). Publiez ensuite les tables :

   -- On the source (needs wal_level = logical and a user with the REPLICATION attribute)
   CREATE PUBLICATION app_pub FOR ALL TABLES;

2. Créer les tables chez Canner. La réplication logique copie des lignes, pas le schéma. Restaurez d’abord le schéma, avec les mêmes noms de tables et de colonnes :

   # Copier le schéma seulement : les tables doivent exister ici, avec les mêmes noms et colonnes
   pg_dump --schema-only --no-owner --no-privileges "$SRC_URL" | psql "$CANNER_URL"

   Activez l’accès externe de la base cible pour vous y connecter depuis votre poste (TLS uniquement, liste d’adresses autorisées).
3. Installer les extensions dont votre schéma a besoin avant le début de l’abonnement, sur l’instance dédiée.
4. Ajouter l’abonnement avec l’URL de connexion lue depuis une variable d’environnement, pour que le mot de passe ne soit jamais affiché :

   export SRC_URL='postgres://repl_user:mdp@source.exemple.com:5432/appdb'
   canner db subscriptions appdb add ancien --from-env SRC_URL --publication app_pub

   Canner copie les lignes existantes, puis diffuse les changements. La base indique combien de tables sont à jour et quand le dernier changement est arrivé. Jusqu’à cinq abonnements par base. Si un changement ne peut pas être appliqué (table manquante, ligne en conflit), l’abonnement affiche En échec, vous recevez une alerte, et il réessaie de lui-même une fois la cause corrigée.

Deux comportements à prévoir. Les changements sont appliqués avec les droits du propriétaire de vos tables, jamais en superutilisateur : les déclencheurs de vos tables s’exécutent donc avec vos seuls droits. Et ils s’exécutent avec un search_path vide : une fonction de déclencheur doit utiliser des noms qualifiés par le schéma (public.audit, pas audit). Pour le raisonnement, voir Exploiter la réplication logique en toute sécurité.

Liste de vérification de la bascule

1. Attendez que l’abonnement soit à jour : toutes les tables rattrapées et l’heure du dernier changement récente.
2. Arrêtez les écritures sur la source. Mettez l’application en mode maintenance ou pointez-la vers un utilisateur en lecture seule, et laissez arriver les derniers changements.
3. Corrigez les séquences. La réplication logique ne transporte pas les valeurs de séquences : une colonne à incrément 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 ici :

   -- À 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.

4. Vérifiez extensions et déclencheurs. Chaque extension est installée; les fonctions de déclencheur utilisent des noms qualifiés par le schéma.
5. 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 vos analystes et services ont besoin (canner db roles <nom> create bi --read-only) et réémettez les droits.
6. Retirez l’abonnement. Cela supprime le slot sur la source. Si la source n’existe déjà plus, utilisez --force.
7. Pointez l’application vers Canner. DATABASE_URL est injectée au prochain déploiement; redéployez, puis lancez vos essais de fumée.
8. Activez les sauvegardes. Définissez tout de suite une politique de sauvegarde (canner db backup-policy <nom> --enable --every 24 --keep 7) et envisagez la récupération à un instant précis et une copie hors site.

Revenir en arrière

• Avant la bascule, rien à défaire. Retirez l’abonnement : la source n’est pas touchée; la base Canner peut être supprimée ou remplacée.
• Juste après la bascule, l’ancien serveur a encore les données au moment où vous avez arrêté les écritures. Repointez l’application vers lui et vous ne perdez que ce qui a été écrit chez Canner entre-temps.
• Si vous avez besoin de ces écritures, renvoyez-les avec la migration sortante (canner db migrate-out), qui envoie une base Canner vers un serveur que vous indiquez, ou exportez un pg_dump et chargez les différences à la main.

Gardez l’ancien serveur, en lecture seule, quelques jours avant de le supprimer. Rappelez-vous que Canner fonctionne dans une seule région (Montréal), sans basculement automatique : votre première sauvegarde et votre copie hors site comptent dès le premier jour.