Modifications de base de données sans interruption de service : expand et contract

Objectif

Modifier la structure de la base de données pendant que le service continue de répondre – et faire en sorte que chaque état intermédiaire fonctionne à la fois avec l'ancienne et avec la nouvelle version du code.

Prérequis

Des migrations versionnées avec le code ; un processus de déploiement capable de livrer code et migrations séparément ; une connaissance des instructions qui posent des verrous forts. La documentation PostgreSQL sur ALTER TABLE indique le niveau de verrou pour chaque forme – la plupart prennent un verrou ACCESS EXCLUSIVE, qui bloque tout autre usage de la table – et précise qu'ADD COLUMN avec un DEFAULT non volatile enregistre la valeur dans les métadonnées au lieu de réécrire la table ; qu'une contrainte CHECK ou NOT NULL lit la table mais ne la réécrit pas ; et qu'une contrainte créée avec NOT VALID n'est vérifiée que par VALIDATE CONSTRAINT, qui ne prend qu'un verrou SHARE UPDATE EXCLUSIVE. CREATE INDEX CONCURRENTLY construit un index sans bloquer les insertions, modifications et suppressions sur la table. Le paramètre lock_timeout interrompt une instruction qui attend un verrou plus longtemps que la durée indiquée.

Étapes

1. Étendre (expand) : créer la nouvelle colonne, table ou le nouvel index de façon rapide et non bloquante (colonne nullable ou valeur par défaut constante, CREATE INDEX CONCURRENTLY, contraintes NOT VALID). L'ancien code ignore le nouvel élément.
2. Exécuter chaque migration avec un lock_timeout défini (quelques secondes) et la relancer en cas d'échec, plutôt que de laisser une demande de verrou en attente accumuler une file de requêtes bloquées.
3. Livrer du code qui écrit dans les deux représentations tout en continuant de lire l'ancienne.
4. Rattraper les lignes existantes par petits lots avec des pauses ; surveiller les temps d'attente de verrou et le retard de réplication. Exécuter ensuite VALIDATE CONSTRAINT.
5. Livrer du code qui lit la nouvelle représentation et la compare pendant un certain temps à l'ancienne (journaliser les écarts).
6. Arrêter d'écrire dans l'ancienne représentation ; livrer.
7. Réduire (contract) : supprimer l'ancienne colonne ou table dans une version ultérieure, dès qu'un retour en arrière vers la version de code précédente n'est plus nécessaire.

Résultat attendu

Chaque déploiement est réversible indépendamment ; aucune migration ne retient un verrou assez longtemps pour se faire remarquer.

Limites et base de vérification

Le modèle multiplie les étapes et prend des jours plutôt que des minutes. Une colonne est renommée par « créer, copier, supprimer », et non par RENAME, lorsque les deux versions de code doivent tourner en même temps. Le comportement des verrous suit la documentation citée ; aucune durée n'est avancée. Que lock_timeout combiné à une répétition des tentatives réduise le nombre d'incidents est consigné dans le wiki comme une hypothèse, pas comme un résultat établi.

Réessayer en tenant compte de ce qui bloque

Un abandon provoqué par lock_timeout est une information, pas une invitation à une boucle infinie : la simple demande de verrou en attente bloque déjà tous les nouveaux accès placés derrière elle, et chaque nouvelle tentative crée un nouvel arrêt bref. Avant la tentative suivante, pg_blocking_pids(pg_backend_pid()) associé à pg_stat_activity (state, xact_start, query) montre qui détient le verrou. Une longue requête d'analyse ou une session bloquée en idle in transaction ne se termine pas d'elle-même ; attendre, l'interrompre ou utiliser pg_terminate_backend est alors une décision consciente, et idle_in_transaction_session_timeout prévient à l'avance le cas le plus fréquent. La boucle a besoin d'une pause entre les tentatives et d'une limite supérieure. lock_timeout ne limite que l'attente du verrou ; le temps d'exécution de VALIDATE CONSTRAINT et des lots de rattrapage est limité par statement_timeout.