Cartographiez chaque lecteur et écrivain
Travaillez sur un schéma isolé avec des données représentatives assainies. Vous avez besoin des versions actuelle et suivante de l'application, de la connaissance de votre framework de migration, d'une stratégie de sauvegarde révisée et d'une visibilité sur les transactions longues. Incluez les workers, les tâches planifiées, les rapports et les anciennes instances d'application. Une API peut se mettre à jour rapidement tandis qu'un worker de longue durée écrit encore dans l'ancienne colonne.
Notre service de reporting illustratif stocke une étiquette d'export dans label et souhaite display_name. Ceci est un exemple de conception, pas du SQL exécutable universel. Confirmez votre version exacte de PostgreSQL et votre framework avant de choisir la syntaxe de migration ou les paramètres de verrouillage.
Étendez sans retirer l'ancienne représentation
Introduisez d'abord le nouveau champ nullable. Déployez une version de compatibilité qui écrit les deux valeurs dans une seule transaction et lit avec le repli requis tant que les données sont incomplètes. Définissez ce qui se passe lorsqu'un client modifie un enregistrement pendant le remplissage. Une nouvelle tentative ne doit pas créer un second export logique.
PostgreSQL ALTER TABLE les opérations acquièrent des verrous, le niveau dépendant de la sous-commande. Un petit changement peut attendre derrière une transaction longue puis bloquer d'autres travaux. Examinez l'opération spécifique et observez les attentes pendant la répétition ; additif ne signifie pas sans verrou.
Référence technique : PostgreSQL ALTER TABLE · Verrouillage explicite PostgreSQL.
Rendez visible la frontière de compatibilité
| Schéma et écrivains | Comportement du lecteur | Décision de récupération |
|---|---|---|
| Seule l'étiquette existe | Ancien code pris en charge | Ajouter d'abord le nouveau champ |
| Les deux champs ; les écrivains anciens uniquement subsistent | Lire l'étiquette comme faisant autorité | Ne pas encore basculer les lecteurs |
| Tous les écrivains en double écriture ; remplissage vérifié | Le nouveau champ peut devenir faisant autorité | Retour arrière uniquement vers un code compatible à double écriture |
| Ancien champ supprimé | Aucun code ne doit référencer l'étiquette | L'ancien artefact est incompatible |
Un repli pour les valeurs manquantes ne peut pas détecter une nouvelle valeur non nulle mais obsolète. Avant de basculer les lecteurs, retirez les écrivains anciens uniquement et vérifiez la cohérence. Un retour arrière vers un code ancien uniquement après le basculement des lecteurs pourrait recréer une divergence. Conservez plutôt la version de compatibilité comme artefact de récupération révisé.
Remplissez par lots bornés et redémarrables
Trouvez les lignes à copier sans écraser une modification plus récente du client. Utilisez un ordre stable, une condition de mise à jour sûre en concurrence et des lots choisis pour la charge de travail. Persistez la progression afin qu'une défaillance puisse reprendre à une frontière connue. Surveillez le volume d'écriture, les attentes de verrou, la latence des requêtes et la réplication le cas échéant.
Aucune taille de lot n'est sûre pour toutes les applications. En répétition, comparez un petit lot avec le trafic ordinaire, puis choisissez une règle de pause ou d'arrêt. Si un lot échoue, inspectez ce qui a été validé avant de réessayer. Une boucle de nouvelle tentative illimitée peut transformer une incohérence récupérable en pression soutenue sur la base de données.
Vérifiez la sémantique, pas seulement les lignes remplies
Vérifiez les valeurs manquantes, les étiquettes représentatives, les nouveaux enregistrements et les mises à jour des exports existants. Compter les lignes non nulles peut sembler correct alors que les valeurs ont été copiées depuis la mauvaise source. Testez l'artefact de compatibilité avec des données partiellement remplies et exercez un worker démarré avant le déploiement.
Enregistrez la version du schéma, la révision de migration, les critères d'achèvement et les combinaisons incompatibles. Inspectez l'utilisation du repli et la cohérence avant de supprimer l'un ou l'autre. Si les vérifications échouent, arrêtez le remplissage ou la promotion, conservez les preuves et choisissez un artefact compatible ou une réparation prospective révisée. Ne prétendez pas qu'un retour arrière d'application reconstruit les données validées.
Retirez l'ancien champ dans une autre version révisée
Supprimez les lectures et écritures anciennes après que le remplissage et la période d'observation répondent à vos critères. Vérifiez les tâches peu fréquentes ainsi que les routes interactives. La suppression de l'ancien champ appartient à une modification ultérieure avec sa propre décision de récupération, afin qu'un problème de version ne vous oblige pas à combiner réparation du code et reconstruction des données.
Si des données erronées apparaissent après le retrait, arrêtez tout dommage supplémentaire et utilisez le plan de récupération ou une réparation approuvée. N'appliquez pas de migration descendante destructive simplement parce que l'outillage expose un bouton de retour arrière. Joignez la matrice au fiche de version et répétez récupération de données avant de modifier la production. Le résultat utile est une frontière de compatibilité explicite, pas une garantie de zéro interruption.
Références officielles
La documentation a été révisée pour cet article. Les exemples sont des exercices de planification, pas des commandes testées sur un serveur PrivacyNodes. Vérifiez la documentation de votre version installée.