Au final, voici ce que j'ai fais :
Phase A: vérification de la faisabilité et tests 1/ sortir un slave de la prod 2/ promouvoir ce slave via la commande "pg_ctlcluster promote". Ceci ne provoque pas de bascule avec le vrai master, et même si ça peut paraître logique pour certains, ce n'est indiqué nulle part dans la doc et cette info est importante sur un environnement de production. Avec repmgr, un promote fait une bascule. 3/ tester l'upgrade en 11 en mode upgrade et avec hardlinks, avec la commande: "time pg_upgradecluster -m upgrade -j 8 --link 10 main /var/local/postgresql/11/main" 4/ ... qui plante ! Principalement à cause des extensions: une manquante (repack) et surtout postgis qui est bien foireux à mettre à jour: il faut installer postgis 2.5, copier les libs 2.5 en les nommant 2.4 (cd /usr/lib/postgresql/11/lib && cp postgis-2.5.so postgis-2.4.so) 5/ refaire l'upgrade 2x : le 1er plante parce que l'instance met trop de temps à s'arrêter, le 2ème lance l'instance qui s'était arrêtée, la stop de nouveau puis procède à l'upgrade, temps total <2min 6/ faire les ALTER EXTENSION mon_extension UPDATE de toutes les extensions utilisées, dans tous les db/schéma
Phase B: en prod 1/ répéter les étapes de la phase A mais sur le master et sans les erreurs (extensions...) 7/ setup des slaves: installer pg11, les extensions, et faire les clone standby.
Pour la petite histoire, les clones mettront 7h à se faire pour une db d'1To sur un RAID10 6 disques SAS 15krpm, pendant ce temps toute la charge se trouve sur le master. Le temps de coupure de l'app aura été inférieur à 5min ce qui est bien plus acceptable.
Bonne aprem ! Greg
Le mar. 11 juin 2019 à 23:29, SERRUT Arnaud qqqrno@gmail.com a écrit :
Salut, j'ai pas vraiment les billes pour aider sur ce cas, mais je tique sur le bas niveau de réplication Connais tu l'infra de stockage sur laquelle tu repose ? Si il y a de la virtualisation du stockage en jeu, tu peux peut-être utiliser la fonctionnalité de snapchot de Lun pour un retour arrière rapide. Je saurais a peu près le faire sur du Datacore, mais d'autres doivent le faire aussi.
Le mar. 11 juin 2019 à 11:59, Greg greg-frsag@duchatelet.net a écrit :
Simple question par pure curiosité, dans le premier mail tu disais que
les upgrade MySQL se faisait plutôt facilement en décrivant le process. Est-ce qu'il est possilbe de faire un rollback après avoir démarré MySQL?
Si la réponse est non, ça correspond grosso modo au pg_upgrade + hardlink. La seule différence que je vois est que MySQL supporte la réplication entre versions majeures différente, là où la réplication pg est plus bas niveau et ne permet pas ce genre de réplication.
Disons qu'après l'upgrade de 10 slaves MySQL, l'upgrade du master ne devrait pas poser de problèmes, la procédure d'upgrade étant validée. Les très rares cas où j'ai rencontré des problèmes, ils étaient soit inclus dans la procédures d'upgrade, soit (mieux) corrigés sur le master avant upgrade des slaves suivants.
-- Greg _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/