Migration Postgres 14 -> 18 #5007
Description
Je commence à collecter les éléments ici :
- On veut disposer de versions claires sur les 3 parties importantes (Postgres, PostGIS, TimescaleDB), pour que notre suite de tests, et notre travail local (avec ou sans backup) soit suffisamment proche de la production.
- Ce point n'est pas "que théorique", un incident qui casse quelque part peut arriver (et est déjà arrivé, voir Robustifier le processus d'upgrade de Postgres et PostGIS #2145)
Étapes
- Vérifier où on va atterrir côté CleverCloud :
- Quelle version précise de PG 18 ?
- Quelle édition (Community versus Apache 2 de TimescaleDB ?
- Quelle version de PostGIS ?
- Préparer une branche de travail (non mergée) avec ce qu'il faut en CI et en local
- Documenter les tweaks faits sur la réplique Postgres #5008 (et les remettre en place)
- Bonus @thbar : en profiter pour avoir des restores complètement propre en local
- Les hypertables doivent être restaurées sans erreur
- Documenter (selon effort) comment faire un setup propre en local (j'ai une branche Docker pour ça en cours, mais sinon au minimum documenter simplement les possibilités)
- Déployer sur la recette, tester
- Déployer sur la production
- Vérifier la réplique
- Vérifier le prix de la réplique / le plan appliqué
- (à finaliser)
Echanges en cours
Message à CleverCloud
Bonjour,
on étudie une upgrade Postgres de 14 vers 18, et j'ai quelques questions (car on utilise PostGIS + TimescaleDB).
1/ on est actuellement sur les versions suivantes:
Postgres : PostgreSQL 14.18 on x86_64-pc-linux-gnu, compiled by x86_64-pc-linux-gnu-gcc (GCC) 14.2.0, 64-bit
PostGIS : 3.5 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
TimescaleDB : 2.17.2Si on upgrade à v18, que va-t-il se passer sur PostGIS et TimescaleDB au niveau des versions? Comment est-ce que ces versions sont fixées actuellement?
2/ La réplica est sur les mêmes versions actuellement, comment se gèrera l’upgrade ?
On a plusieurs tweaks (qu'il faudrait qu'on documente de notre côté : ex le user qui a accès à la réplication ne peut pas accéder à la production etc), faudra-t-il tout reconstruire ?
3/ On envisage de gonfler un peu le disque (passer de L SML à L MID peut-être), car on voit encore des erreurs OOM couplées à des "out of disk".
Est-ce que ce bout d'upgrade est faisable de façon transparente à part si on décide de le faire, ou vaut-il mieux le faire en même temps?
merci !
-- Thibaut
Réponse de CleverCloud
Bonjour Thibaut,
Dans le cas de TimescaleDB notamment, il y a un sujet en cours de notre côté, car il y a 2 versions la version Community et la version Entreprise.
Selon votre version sur l'add-on, le chemin ser aassez différent.
Si on modifie la version du leader, il faudra très probablement faire de même pour le follower du replica,, et donc reconstruire.
Je vais vérifier ça.
Je pense que, concernant l'upgrade de taille, ce serait potentiellement le meilleur moment de le faire, en mettant de votre côté une "maintenance" (puisque dans tous les cas, il y aura une interruption de service, car la base passe en read-only le temps de l'upgrade).
Je vais vérifier tout ça avec un collègue côté bases et vous reviens.