Comprendre les interruptions de service lors des mises en production.

Les modifications des schémas des bases relationnelles peuvent être compliquées si l'on veut garder un service avec du traffic et sans interruption.
La présentation a pour but d'expliquer ce qui peut causer des interruptions de service et ce que l'on peut mettre en place pour les éviter.

Transcript

1. Comment modifier sa base de données sans interruption de service Comprendre les interruptions de service lors des mises en production. Xavier ORDOQUY - 2026
2. Sujet De quoi on parle • Technique PostgreSQL • Pourquoi ! • Comprendre certaines inaccessibilités lors de mise en production • On va parler transactions et verrous (lock) • Comment ? • Corentin Normant / Damien Ramelet, Pyconfr 2024 • Loïc Simon, Pyconfr 2026
3. Qui suis-je ? Xavier Ordoquy • Python (2000) • Django (2009) • Ex mainteneur Django REST framework / ex contributeur Sentry • A mon compte (Linovia - 2004) • https://www.linkedin.com/in/xordoquy/
4. Ce n’est pas pour tout le monde ! Mise en garde • C’est top, mais… • En avez-vous besoin ? • Coût • Temps de développeurs • Temps des déploiements • Compétences
5. Le contexte • Projet Web Python avec un ORM et des taches asynchrones longues • Des déploiements sans interruption • L’équipe a déjà regardé les bonnes pratiques. Elle connait les modi cations qui sont problématiques. fi fi • Mise en production avec une modi cation qui est sans risque.
6. Edouard HR Gluck/AP La mise en production Le projet a pris l’eau
7. Les contraintes ACID Les bases • Atomicité: tout ou rien • Cohérence: les données doivent être valides • Isolation: les transactions sont indépendantes • Durabilité: conservations des données en cas de crash
8. Comment gérer ce cas: • Export d’une table volumineuse • Ajout d’une colonne (nullable) à la table • Que se passe-t-il pour les autres transactions ? • export de la table: N ou N+1 colonnes ?
9. Les verrous (lock) • ACCESS SHARE • SELECT • ROW EXCLUSIVE • UPDATE / DELETE, … • ACCESS EXCLUSIVE • ALTER / DROP, …
10. Comment gérer ce cas: • Export d’une table volumineuse (ACCESS SHARE) • Ajout d’une colonne nullable à la table (ACCESS EXCLUSIVE)
11. Le traffic • Des utilisateurs • Un export • La mise en production
12. Attendu
13. Réalité
14. Et pour couronner le tout • Les verrous ne sautent qu’en n de transaction • L’identi cation des utilisateurs pose un verrou sur cette table fi fi • Attention aux transactions qui durent
15. # SELECT … FROM pg_locks WHERE relation='user'::regclass; locktype | virtualtransaction | pid | granted | waitstart ----------+--------------------+------+---------------------+------------------------------relation | 4/6 | 4737 | AccessShareLock | relation | 5/10 | 5144 | AccessExclusiveLock | 2026-11-01 00:01:32.001971+00 (2 rows)
16. Comment faire ? • Il y aura toujours une interruption • L’objectif est de la minimiser
17. Ajouter un lock timeout • Rend la main au bout d’un temps • Débloque les requêtes en attente • Ajouter du retry au déploiements MAIS • Les modi cations risquent de ne plus passer • Mise en production plus compliquées fi • Si c’est ajouté partout, ça peut impacter le metier
18. Effet du lock timeout
19. Effet du lock timeout
20. Limiter la durée des transactions • Pensez à fermer (COMMIT ou ROLLBACK) TOUTES les transactions • Attention aux transactions implicites (identi cation par ex) • Requêtes HTTP (surtout s’il y a des pools de connexions) • Taches périodiques ou asynchrones • statement_timeout (même s’il y a un HTTP timeout) fi • transaction_timeout (depuis PostgreSQL 17)
21. Questions ?
22. Merci !