Définir le résultat attendu

Avant de choisir l’outil, connaître le moteur et sa version, les extensions, le volume, les écritures par seconde, les fenêtres de maintenance et les dépendances de l’application. Une copie réussie ne garantit pas que les données seront cohérentes, que les identifiants fonctionneront ou que le service reprendra correctement.

Une préparation en cinq temps

  1. Inventorier. Relever schéma, extensions, rôles, encodages, tâches planifiées et connexions.
  2. Sauvegarder. Produire une sauvegarde vérifiable et tester sa restauration avant la migration.
  3. Répéter. Faire un essai sur une copie représentative, mesurer la durée et relever les écarts.
  4. Choisir le basculement. Selon le moteur, le volume et la tolérance d’arrêt, prévoir une fenêtre de maintenance ou une réplication suivie d’un arrêt des écritures et d’un rattrapage final.
  5. Vérifier et décider. Comparer des comptes et requêtes métier, tester l’application sur la cible et ne supprimer la source qu’après validation.

Pour PostgreSQL, la réplication logique peut aider à transférer les modifications pendant qu’une nouvelle instance est préparée. La documentation signale toutefois des limites : les changements de schéma ne sont pas répliqués et les séquences ne le sont pas non plus. Ce comportement est propre à cette méthode PostgreSQL ; les autres moteurs ont leurs propres prérequis.

Garder un retour arrière praticable

Établir à l’avance qui peut arrêter les écritures, comment l’ancienne base sera conservée et quels critères déclenchent un retour. Après basculement, surveiller erreurs, latence, connexions, tâches planifiées et sauvegardes de la cible.

La migration peut être déclenchée en une action, mais la décision de bascule exige un plan relu et des contrôles adaptés aux données. La simplicité du geste ne remplace pas la préparation.

Source technique

À lire aussi