Modifications pour le document Mettre à jour pgsql sur pgsql-prod
Modifié par Gaetan RETEL le 2025/10/05 00:22
Depuis la version 16.1
modifié par Gaetan RETEL
sur 2025/03/28 20:16
sur 2025/03/28 20:16
Commentaire de modification :
Il n'y a aucun commentaire pour cette version
À la version 2.1
modifié par Gaetan RETEL
sur 2025/03/12 01:58
sur 2025/03/12 01:58
Commentaire de modification :
Il n'y a aucun commentaire pour cette version
Résumé
-
Propriétés de la Page (1 modifications, 0 ajouts, 0 suppressions)
Détails
- Propriétés de la Page
-
- Contenu
-
... ... @@ -1,23 +1,19 @@ 1 -Après avoir galéré sur la mise à jour de postgreSQL sur [[pgsql-prod>>doc:Services.PostgreSQL.WebHome]], j'ai prisle partide noter ici les étapes à suivre pour une upgrade sans histoire.1 +Après avoir galéré sur la mise à jour de postgreSQL sur [[pgsql-prod>>doc:Services.PostgreSQL.WebHome]], j'ai décidé de noter ici les étapes à suivre pour une upgrade sans histoire. 2 2 3 -Les commandes listées ci dessous seront celle sde la version que j'ai installée.3 +Les commandes listées ci dessous seront celle de la version que j'ai installé. 4 4 5 -{{toc/}} 6 6 6 +=== Précautions à prendre === 7 7 8 +Avant de toucher à la BDD on va évidemment faire une sauvegarde, pour pouvoir remettre en état en cas de pépin. Pour cela on peut utiliser {{code language="none"}}pg_dumpall{{/code}}. Pour cela on va faire deux sauvegarde, une avec le flag {{code language="none"}}--globals-only{{/code}} pour récupérer les users/roles/etc, et une autre pour récupérer les BDDs. 8 8 10 +(% class="box warningmessage" %) 11 +((( 12 +Attention, la commande pg_dumpall ne fait qu'un dump du cluster par défaut (port 5432), il va donc falloir l'exécuter pour chaque cluster 13 +))) 9 9 10 -== Précautions à prendre == 11 - 12 - 13 -Avant de toucher à la BDD on va évidemment faire une sauvegarde, pour pouvoir remettre en état en cas de pépin. Pour cela on peut utiliser {{code language="none"}}pg_dumpall{{/code}}. Il va falloir faire deux sauvegarde, une avec le flag {{code language="none"}}--globals-only{{/code}} pour récupérer les users/roles/etc, et une autre pour récupérer les BDDs. 14 - 15 -{{warning}} 16 -La commande pg_dumpall ne fait qu'un dump du cluster par défaut (port 5432), il va donc falloir l'exécuter pour chaque cluster. 17 -{{/warning}} 18 - 19 19 (% class="wikigeneratedid" %) 20 -Pour voir les différents clusters présents, utilise zla commande {{code language="none"}}pg_lsclusters{{/code}}. La sortie inclura plusieurs information importantes, comme la version pgsql utilisé par chaque cluster, et son port.16 +Pour voir les différents clusters présents, utiliser la commande {{code language="none"}}pg_lsclusters{{/code}}. La sortie inclura plusieurs information importantes, comme la version pgsql utilisé par chaque cluster, et son port. 21 21 22 22 (% class="wikigeneratedid" %) 23 23 Pour vérifier qu'il y a de la place sur la VM on peut utiliser {{code language="none"}}df -h{{/code}} et regarder la place sur ce qui est monté sur / , le dump des BDD du cluster main faisait 1.3G dans mon cas. ... ... @@ -26,287 +26,108 @@ 26 26 ((( 27 27 (% class="box" %) 28 28 ((( 29 -su - postgres -c "pg_dumpall -U postgres -p <port>" > /var/backups/pgsql_<name>_backup.sql25 +su - postgres -c "pg_dumpall -U postgres -p 5432" > /var/backups/pgsql_main_backup.sql 30 30 31 -su - postgres -c "pg_dumpall ~-~-globals-only -U postgres -p <port>" > /var/backups/pgsql_<name>_globals_backup.sql27 +su - postgres -c "pg_dumpall ~-~-globals-only -U postgres -p 5432" > /var/backups/pgsql_main_globals_backup.sql 32 32 ))) 33 33 ))) 34 34 35 -{{info}} 36 -Pensez à copier les sauvegardes sur une autre machine en cas de problème sur la VM, on ne sait jamais. Pour la copier sur votre machine dans ./pgsql/ utilisez par exemple : 37 -{{/info}} 38 - 39 -(% class="box" %) 31 +(% class="box warningmessage" %) 40 40 ((( 41 -(% class="box" %) 42 -((( 43 -scp -J root@atilla.org pgsql-prod.prod.infra:/var/backups/pgsql_main_backup.sql ./pgsql/ 33 +Penser à copier les sauvegardes sur une autre machine en cas de problème sur la VM, on ne sait jamais. Pour la copier sur votre machine dans pgsql/ utiliser par exemple : 44 44 ))) 45 -))) 46 46 47 -{{info}} 48 -Vous pouvez voir s'il est nécessaire d'installer de nouveaux packages pour la version que vous voulez installer en tapant {{code language="none"}}dpkg -l | grep postgresql{{/code}} 49 -{{/info}} 50 - 51 - 52 - 53 - 54 -== Préparation des nouveaux clusters == 55 - 56 - 57 -pour créer les nouveaux clusters, il faut commencer par regarder comment sont faits les anciens, pour qu'ils soient compatibles entre eux. L'encodage et le collationnement/type de caractères doivent être identiques. 58 - 59 -{{info}} 60 -on peut trouver les informations nécessaires en affichant les BDDs de chaque clusters : 61 -{{/info}} 62 - 63 63 (% class="box" %) 64 64 ((( 65 65 (% class="box" %) 66 66 ((( 67 -sudo -u postgres psql -p <port> 68 - 69 -\l 40 +scp -J root@atilla.org pgsql-prod.prod.infra:/var/backups/pgsql_main_backup.sql ./pgsql/ 70 70 ))) 71 71 ))) 72 72 73 -Si vous n'avez jamais touché à postgreSQL, la commande pour sortir du terminal est {{code language="none"}}\q{{/code}} 74 74 75 -Ici, l'encodage est UTF-8 et le reste en C. Pour créer un cluster "main" utilisant pgsql 14 la commande est donc 45 +(% class="wikigeneratedid" %) 46 +Pour vérifier les packages installés, utiliser la commande 76 76 77 77 (% class="box" %) 78 78 ((( 79 79 (% class="box" %) 80 80 ((( 81 -pg _createcluster~-~-locale=C~-~-encoding=UTF8 14 main52 +dpkg -l | grep postgresql 82 82 ))) 83 83 ))) 84 84 85 85 57 +=== Préparation des nouveaux clusters === 86 86 87 - Onvatiliser la commande{{codelanguage="none"}}pg_upgrade{{/code}} pourmigrerlesdonnées,il va falloir utiliserpas maldeflagsavecdesarguments,n'oubliezpasde[[lire ladoc>>https://www.postgresql.org/docs/15/pgupgrade.html]].59 +pour créer les nouveaux clusters, il faut commencer par regarder comment sont faits les anciens, pour qu'ils soient compatibles entre eux. L'encodage et le collationnement/type de caractères doivent être identiques. 88 88 89 - 90 -Afin de pouvoir lancer la commande, il va falloir stopper postgreSQL : 91 - 92 -(% class="box" %) 61 +(% class="box infomessage" %) 93 93 ((( 94 -(% class="box" %) 95 -((( 96 -systemctl stop postgresql 63 +on peut trouver les informations nécessaires en affichant les BDDs de chaque clusters : 97 97 ))) 98 -))) 99 99 100 -Vous pouvez vous assurer avec la commande suivante que tout est bien à l'arrêt, sinon {{code language="none"}}pg_upgrade{{/code}} retournera des erreurs : 101 - 102 102 (% class="box" %) 103 103 ((( 104 104 (% class="box" %) 105 105 ((( 106 -ps -ef | grep postgres 107 -))) 108 -))) 70 +sudo -u postgres psql -p 5432 109 109 110 -La seule tâche qui devrait apparaître est celle lancé par root, par exemple : 111 - 112 -(% class="box" %) 113 -((( 114 -root 5860 0.0 0.1 6356 2172 pts/0 S+ 15:42 0:00 grep ~-~-color=auto postgres 72 +\l 115 115 ))) 116 - 117 -Si vous voyez une ligne avec une tâche lancée par postgres, il faut l'arrêter. Voilà quelques commandes utiles : 118 - 119 - 120 -La commande suivante permet de stopper un cluster spécifique d'une version pgsql donnée : {{code language="none"}}pg_ctlcluster <version> <cluster_name> stop{{/code}} (% id="cke_bm_63735S" style="display:none" %) (%%)(ou de démarrer avec {{code language="none"}}start{{/code}}) 121 - 122 -S'il y a toujours des tâches liés à postgres/des clusters qui tournent, vous pouvez forcer leur arrêt avec cette commande en indiquant leur PID (dans l'exemple avec root plus tôt, le PID est 5860) : {{code language="none"}}kill -9 <PID>{{/code}} 123 - 124 - 125 - 126 -Une fois les processus stoppés, on peut lancer la commande. 127 - 128 -Pour passer de la version x à la version y, il faut le path des dossiers des exécutables et de data des version x et y, ainsi que le path du fichier .conf de postgres de chaque version. 129 - 130 - 131 -Avant de lancer la commande, on notera l'existence du flag {{code language="none"}}--check{{/code}}, dont on ne manquera pas de se servir. 132 - 133 -Pour la version 13 à 14, il faut donc taper pour lancer les vérifications : 134 - 135 -(% class="box" %) 136 -((( 137 -(% class="box" %) 138 -((( 139 -/usr/lib/postgresql/14/bin/pg_upgrade -b /usr/lib/postgresql/13/bin -B /usr/lib/postgresql/14/bin -d /var/lib/postgresql/13/main -D /var/lib/postgresql/14/main -o '-c config_file=/etc/postgresql/13/main/postgresql.conf' -O '-c config_file=/etc/postgresql/14/main/postgresql.conf' ~-~-check 140 140 ))) 141 -))) 142 142 143 -(% class="box infomessage" %) 144 -((( 145 -À ce stade là, s'il y a des problèmes, google est votre ami. 146 -))) 76 +Si comme moi vous n'avez jamais touché à postgreSQL, la commande pour sortir du terminal est \q 147 147 78 +Dans mon cas, l'encodage est UTF-8 et le reste en C. Pour créer un cluster "main" utilisant pgsql 14 la commande est donc 148 148 149 - 150 - 151 -== Lancer l'upgrade == 152 - 153 - 154 -Si la commande avec le flag {{code language="none"}}--check{{/code}} à réussi, il n'y a plus qu'à la lancer sans. Pour autant, une erreur peut toujours survenir. Vérifiez une nouvelle fois que des tâches n'ont pas été redémarrées comme expliqué dans la précédente section. 155 - 156 -Assurez-vous qu'il y ait suffisamment de place sur la VM, toujours avec {{code language="none"}}df -h{{/code}}, les nouveaux clusters de la version 14 ont pris ~~5G. 157 - 158 -{{error}} 159 -Pour la suite, lisez bien TOUTES les infos avant de vous lancer dans les commandes des différents clusters, au risque de perdre des informations. 160 -{{/error}} 161 - 162 162 (% class="box" %) 163 163 ((( 164 164 (% class="box" %) 165 165 ((( 166 - /usr/lib/postgresql/14/bin/pg_upgrade-b /usr/lib/postgresql/13/bin -B /usr/lib/postgresql/14/bin-d /var/lib/postgresql/13/main -D /var/lib/postgresql/14/main-o '-c config_file=/etc/postgresql/13/main/postgresql.conf' -O '-c config_file=/etc/postgresql/14/main/postgresql.conf'84 +pg_createcluster ~-~-locale=C ~-~-encoding=UTF8 14 main 167 167 ))) 168 168 ))) 169 169 170 -Il va donc falloir upgrader chaque cluster comme fait ci dessus, en remplaçant évidemment par le nom des clusters qui vous concernent. 171 171 172 -{{warning}} 173 -Attention, à la fin de l'upgrade d'un cluster, des fichiers vont être générés dans /var/lib/postgresql/, comme vous en informera la sortie de la commande. 174 -Si vous lancez l'upgrade de plusieurs clusters d'affilé, les fichiers du 2è clusters écraseront ceux du premier. Veillez à les récupérer avant, et à noter quel fichier correspond à quel cluster. 175 -{{/warning}} 89 +On va utiliser la commande {{code language="none"}}pg_upgrade{{/code}} pour migrer les données, il va falloir utiliser pas mal de flags avec des arguments, n'oubliez pas de [[lire la doc>>https://www.postgresql.org/docs/15/pgupgrade.html]]. 176 176 177 -{{error}} 178 -Ne pas exécuter les fichiers générés par la commande immédiatement 179 -{{/error}} 91 +Pour passer de la version x à la version y, il faut le path des dossiers des exécutables et de data des version x et y, ainsi que le path du fichier .conf de postgres de chaque version. 180 180 181 181 94 +Avant de lancer la commande, on notera l'existence du flag ~-~-check, dont on ne manquera pas de se servir. 182 182 96 +Pour la version 13 à 14, il faut donc taper pour lancer les vérifications 183 183 184 -== Mise en place des nouveaux clusters == 185 - 186 - 187 - 188 -Une fois les nouveaux clusters terminés et les données migrées, il va falloir terminer la configuration. 189 - 190 -Ouvrez le fichier de configuration {{code language="none"}}pg_hba.conf{{/code}} de l'ancienne version, situé dans {{code language="none"}}/etc/postgresql/<old_version>/<cluster_name>/{{/code}}. À la fin du fichier, copiez la partie sur le login pour les BDDs, dont le début est indiqué par la ligne 191 - 192 192 (% class="box" %) 193 193 ((( 194 -# Database administrative login by Unix domain socket 195 -))) 196 - 197 -Collez ces informations au même endroit dans le fichier de la nouvelle version, {{code language="none"}}/etc/postgresql/<new_version>/<cluster_name>/pg_hba.conf{{/code}}. 198 - 199 -{{warning}} 200 -N'oubliez pas de faire cette opérations pour chaque cluster 201 -{{/warning}} 202 - 203 - 204 - 205 -Si vous souhaitez garder les anciens clusters pour l'instant en cas de besoin, attribuez leurs des ports non utilisés. Paramétrez les ports de nouveaux clusters pour qu'il correspondent aux ports des anciens, sinon les services utilisant pgsql-prod ne pourront plus se connecter à leur BDD. 206 - 207 -Si vous souhaitez supprimer les anciens clusters, vous pouvez maintenant le faire en exécutant les fichiers {{code language="none"}}delete_old_cluster.sh{{/code}} qui ont été générés par {{code language="none"}}pg_upgrade{{/code}}. Ils ne contiennent d'ailleurs que la commande {{code language="none"}}rm -rf '/var/lib/postgresql/<version>/<cluster_name>'{{/code}}. 208 - 209 - 210 - 211 -Ouvrez ensuite le fichier {{code language="none"}}/etc/postgresql/<new_version>/<cluster_name>/postgresql.conf{{/code}} de la nouvelle version. Il faut configurer les ports des clusters, et autoriser les connexions. 212 - 213 -Dans ce cas, le cluster main est au 5432 et le gitlab au 5433, donc dans {{code language="none"}}/etc/postgresql/<new_version>/gitlab/postgresql.conf{{/code}} je cherche et modifie la ligne : 214 - 215 215 (% class="box" %) 216 216 ((( 217 -port =5433102 +/usr/lib/postgresql/14/bin/pg_upgrade -b /usr/lib/postgresql/13/bin -B /usr/lib/postgresql/14/bin -d /var/lib/postgresql/13/main -D /var/lib/postgresql/14/main -o '-c config_file=/etc/postgresql/13/main/postgresql.conf' -O '-c config_file=/etc/postgresql/14/main/postgresql.conf' ~-~-check 218 218 ))) 219 - 220 -il faut également autoriser les connexions, cherchez et modifiez la ligne : 221 - 222 -(% class="box" %) 223 -((( 224 -listen_addresses = '*' 225 225 ))) 226 226 227 -{{warning}} 228 -N'oubliez pas de faire cette opérations pour chaque cluster 229 -{{/warning}} 230 - 231 - 232 - 233 - 234 -== Mises à jour et optimisations == 235 - 236 - 237 - 238 -Un fichier {{code language="none"}}update_extensions.sql{{/code}} a été généré par chaque commande {{code language="none"}}pg_upgrade{{/code}} lancée, on va maintenant pouvoir l'exécuter, ou lancer les commandes à la main. Pourquoi à la main ? Car de toute façon il est également fortement conseillé de ré-indexer les différentes BDDs de chaque clusters, ce qui demande d'accéder à toute les BDDs. Si l'envie vous prend de créer un script et automatiser ça, faites-vous plaisir. 239 - 240 -Il va donc falloir se rendre dans chaque cluster : 241 - 242 -(% class="box" %) 106 +(% class="box infomessage" %) 243 243 ((( 244 -(% class="box" %) 245 -((( 246 -sudo -u postgres psql -p <port> 108 +À ce stade là s'il y a des problèmes, google est votre ami. 247 247 ))) 248 -))) 249 249 250 -De là, on peut afficher les différente BDDs avec {{code language="none"}}\l{{/code}} et se connecter à chaque BDD pour les réindexer. Exemple avec la BDD postgres : 251 251 252 -(% class="box" %) 253 -((( 254 -(% class="box" %) 255 -((( 256 -\c postgres 112 +=== Lancer l'upgrade === 257 257 258 -REINDEX DATABASE postgres; 259 -))) 260 -))) 114 +Si la commande avec le flag ~-~-check à réussi, il n'y a plus qu'à la lancer sans. Pour autant, une erreur peut toujours survenir. 261 261 262 -Si pour ce cluster le fichier {{code language="none"}}update_extensions.sql{{/code}} généré par {{code language="none"}}pg_upgrade{{/code}} indiquait une mise à jour d'extension pour la BDD postgres, on peut en même temps copier coller la commande qui pourrait par exemple être : 263 - 264 -(% class="box" %) 116 +(% class="box errormessage" %) 265 265 ((( 266 - ALTEREXTENSION"pg_trgm"UPDATE;118 +Pour la suite, lisez bien TOUTES les infos avant de vous lancer dans les commandes des différents clusters, sinon vous risquez de devoir recommencer. 267 267 ))) 268 268 269 - 270 - 271 - 272 -== Redémarrer postgreSQL == 273 - 274 - 275 - 276 -Une fois tout cela fait, il ne reste plus qu'à redémarrer postgreSQL : 277 - 278 278 (% class="box" %) 279 279 ((( 280 280 (% class="box" %) 281 281 ((( 282 -s ystemctl start postgresql125 +/usr/lib/postgresql/14/bin/pg_upgrade -b /usr/lib/postgresql/13/bin -B /usr/lib/postgresql/14/bin -d /var/lib/postgresql/13/main -D /var/lib/postgresql/14/main -o '-c config_file=/etc/postgresql/13/main/postgresql.conf' -O '-c config_file=/etc/postgresql/14/main/postgresql.conf' 283 283 ))) 284 284 ))) 285 285 286 -On peut ensuite vérifier avec la commande {{code language="none"}}pg_lsclusters{{/code}} que les deux nouveaux clusters sont opérationnels. 287 - 288 - 289 - 290 -Une commande utile pour le débogage est {{code language="none"}}lsof -i{{/code}}. Cette commande permet d'afficher les connexions actuelles. Il devrait y avoir parmi les résultats quelque chose du genre : 291 - 292 -(% class="box" %) 293 -((( 294 -postgres 220900 postgres 5u IPv4 4457404 0t0 TCP *:postgresql (LISTEN) # pour le port par défaut (5432) de postgres 295 -postgres 220900 postgres 6u IPv6 4457405 0t0 TCP *:postgresql (LISTEN) 296 - 297 -postgres 220901 postgres 5u IPv4 4457515 0t0 TCP *:5433 (LISTEN) # pour le cluster gitlab au 5433 298 -postgres 220901 postgres 6u IPv6 4457516 0t0 TCP *:5433 (LISTEN) 299 - 300 -postgres 414816 postgres 9u IPv4 7792005 0t0 TCP pgsql-prod.prod.infra.atilla.org->gitlab-prod.prod.infra.atilla.org (ESTABLISHED) # pour les machines et VM connectés, exemple avec le gitlab 301 -))) 302 - 303 -{{success}} 304 -Il ne reste plus qu'a vérifier si les services ayant leur BDDs sur pgsql-prod sont repartis normalement. 305 -{{/success}} 306 - 307 -{{info}} 308 -Dans le cas de ce wiki, il y a eu des problèmes avec la macro children après passage sur pgsql 14. Après un redémarrage de tomcat9 sur xwiki-prod et une mise à jour via une connexion avec le compte admin (cf le teampass), le problème s'est résolu. Impossible de savoir laquelle des deux actions a résolu ledit problème, elles ont été faite en même temps. 309 -{{/info}} 310 - 311 -(% class="wikigeneratedid" %) 312 312