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