Que se passe-t-il après une migration de base de données réussie

Une migration de base de données se termine sans erreur. Le pipeline est vert. L'équipe souffle. Mais une heure plus tard, les utilisateurs commencent à signaler que les pages chargent lentement. Certaines requêtes expirent. Quelques appels API renvoient des erreurs 500. La migration a techniquement réussi, mais quelque chose s'est mal passé en dessous.

Ce scénario est plus courant que la plupart des équipes ne le pensent. Une migration qui se termine sans lever d'exception n'est pas la même chose qu'une migration qui a laissé le système dans un état sain. La différence entre ces deux résultats est ce que la vérification post-migration est censée détecter.

Pourquoi les codes de succès ne suffisent pas

La plupart des outils de migration renvoient un code de sortie zéro lorsqu'ils se terminent sans erreur. Cela vous indique que le SQL a été exécuté et que la table de suivi interne de l'outil a été mise à jour. Cela ne vous dit pas si le nouveau schéma fonctionne bien avec l'application, si les performances des requêtes ont changé, ou si la migration a laissé des verrous derrière elle.

Une migration peut techniquement réussir et pourtant causer des dégâts réels. Ajouter une colonne avec une valeur par défaut peut verrouiller une grande table pendant des minutes. Changer le type d'une colonne peut forcer la base de données à réécrire des lignes, ce qui ralentit les requêtes concurrentes. Ajouter un index peut aider une requête mais casser le plan d'exécution d'une autre. Aucun de ces problèmes n'apparaît dans le code de sortie de l'outil de migration.

La vérification post-migration est la pratique qui consiste à vérifier l'état réel de la base de données et de l'application après l'exécution d'une migration. Elle transforme un déploiement aveugle en un déploiement éclairé.

Vérifier correctement l'état de la migration

La première chose à vérifier est de savoir si la migration s'est réellement terminée ou si elle s'est arrêtée en cours de route. Certains outils appliquent les migrations par lots. Si une migration échoue sur le troisième lot, les deux premiers lots ont déjà modifié la base de données. Le code de sortie peut être non nul, mais les dégâts sont déjà partiels.

Consultez la table de suivi de l'outil de migration ou ses journaux détaillés. Découvrez exactement quelles instructions ont été appliquées et où le processus s'est arrêté. Ces informations vous indiquent si la base de données est dans un état cohérent ou si un nettoyage manuel est nécessaire avant de réessayer.

Ne vous fiez pas uniquement au code de sortie. Certaines migrations produisent des avertissements qui ne sont pas fatals mais indiquent des problèmes potentiels, comme une syntaxe obsolète ou des conversions de type implicites. Consignez ces avertissements et incluez-les dans le rapport du pipeline.

Comparer la latence des requêtes avant et après

Les modifications de schéma peuvent altérer la façon dont la base de données exécute les requêtes. Une colonne ajoutée à une table peut amener l'optimiseur de requêtes à choisir un index différent ou un parcours de table complet. Un changement de type de données peut désactiver l'utilisation d'un index pour certaines comparaisons.

Le pipeline doit exécuter un ensemble de requêtes représentatives sur la base de données avant et après la migration. Comparez la latence de chaque requête. Si une requête montre une augmentation significative, c'est le signe que la migration a modifié le plan d'exécution d'une manière qui nuit aux performances.

Concentrez-vous sur les requêtes que l'application utilise le plus fréquemment ou qui sont connues pour être sensibles aux performances. N'exécutez pas de requêtes analytiques lourdes pour cette vérification. Gardez les requêtes de vérification légères afin de ne pas ajouter de charge à la base de données pendant la fenêtre de déploiement.

Vérifier les verrous qui ne se sont pas libérés

Les migrations qui modifient le schéma doivent souvent acquérir des verrous sur des tables ou des lignes. La plupart des verrous sont libérés lorsque la migration se termine, mais pas toujours. Une transaction de longue durée, une connexion qui n'a pas été correctement fermée, ou une migration qui a expiré peuvent laisser des verrous en place.

Après la fin de la migration, vérifiez la présence de verrous actifs dans la base de données. Si des verrous sont toujours maintenus, l'application rencontrera des timeouts ou une accumulation de files d'attente lorsqu'elle tentera d'accéder aux tables concernées. Le pipeline doit également enregistrer la durée pendant laquelle les verrous ont été maintenus pendant la migration. Si un verrou a été maintenu pendant plus de quelques secondes sur une table de production, cela mérite une enquête même s'il a finalement été libéré.

Exécutez cette requête pour voir si des verrous sont toujours maintenus sur la table que vous avez migrée :

SELECT
    pg_locks.pid,
    pg_locks.mode,
    pg_locks.granted,
    pg_class.relname,
    pg_stat_activity.query,
    pg_stat_activity.state,
    pg_stat_activity.wait_event_type || ': ' || pg_stat_activity.wait_event AS wait
FROM pg_locks
JOIN pg_class ON pg_locks.relation = pg_class.oid
JOIN pg_stat_activity ON pg_locks.pid = pg_stat_activity.pid
WHERE pg_class.relname = 'your_table_name'
  AND pg_locks.granted = true;

Si des lignes sont renvoyées, la migration a laissé des verrous derrière elle. Examinez les colonnes query et state pour comprendre pourquoi.

Vérifier les comptages de lignes pour les migrations modifiant les données

Certaines migrations font plus que modifier le schéma. Elles remplissent de nouvelles colonnes avec des valeurs par défaut, déplacent des données entre des tables, ou nettoient des doublons. Ces opérations peuvent silencieusement manquer des lignes si la logique de migration a des cas limites ou si les données ne correspondent pas au format attendu.

Après de telles migrations, comparez le nombre réel de lignes avec le nombre attendu. Par exemple, si la migration était censée remplir une nouvelle colonne pour toutes les lignes existantes, vérifiez que le nombre de lignes avec une valeur non nulle dans cette colonne correspond au nombre total de lignes. S'il y a une différence, la migration ne s'est pas appliquée à toutes les lignes.

Effectuez ces vérifications avec des requêtes de comptage simples. Évitez les jointures ou les agrégations qui pourraient mettre une charge inutile sur la base de données.

Surveiller les journaux d'application pour les erreurs de base de données

L'étape de vérification la plus importante consiste à vérifier si l'application peut toujours fonctionner avec la base de données après la migration. Le code d'application en cours d'exécution a été écrit pour l'ancien schéma. Si la migration a modifié le schéma d'une manière qui casse le code en cours d'exécution, des erreurs apparaîtront dans les journaux d'application.

Recherchez les erreurs qui mentionnent des colonnes manquantes, des incompatibilités de type ou des requêtes échouées. Ces erreurs signifient que l'application et la base de données ne sont plus synchronisées. L'équipe doit décider rapidement s'il faut annuler la migration ou déployer un correctif de code qui correspond au nouveau schéma.

N'attendez pas que les utilisateurs signalent ces erreurs. Le pipeline doit extraire les journaux d'application du système de surveillance et les analyser automatiquement à la recherche d'erreurs liées à la base de données.

Une checklist pratique post-migration

Si vous mettez en place une vérification post-migration pour la première fois, commencez par ces vérifications dans votre pipeline :

Le diagramme suivant illustre la séquence recommandée des étapes de vérification :

flowchart TD A[Migration terminée avec succès] --> B[Vérifier l'état de la migration] B --> C[Comparer la latence des requêtes] C --> D[Vérifier les verrous] D --> E[Vérifier les comptages de lignes] E --> F[Surveiller les journaux d'application] F --> G{Toutes les vérifications réussies ?} G -- Oui --> H[Sûr de conserver] G -- Non --> I[Alerter l'équipe]
  • État de la migration : S'est-elle terminée complètement, et où s'est-elle arrêtée en cas d'échec ?
  • Latence des requêtes : Les cinq requêtes critiques sont-elles toujours dans une plage acceptable ?
  • Verrous : Reste-t-il des verrous actifs après la migration ?
  • Comptages de lignes : Les nombres correspondent-ils aux attentes pour les migrations modifiant les données ?
  • Erreurs d'application : Y a-t-il de nouvelles erreurs liées à la base de données dans les journaux ?

Exécutez ces vérifications automatiquement après chaque migration. Envoyez les résultats à l'équipe sous forme de rapport. Si toutes les vérifications réussissent, la migration peut être conservée en toute sécurité. Si une vérification échoue, l'équipe dispose de suffisamment d'informations pour décider de la prochaine étape.

Ce qu'il faut retenir

Un statut de migration vert n'est pas une garantie de sécurité. Le véritable test est de savoir si la base de données et l'application fonctionnent toujours bien ensemble après le changement. La vérification post-migration comble le fossé entre "la migration a été exécutée" et "le système est sain". Sans elle, vous déployez à l'aveugle en espérant que tout va bien.