Modifications pour le document Mettre à jour pgsql sur pgsql-prod
Modifié par Gaetan RETEL le 2025/10/05 00:22
Depuis la version 11.1
modifié par Gaetan RETEL
sur 2025/03/12 14:07
sur 2025/03/12 14:07
Commentaire de modification :
Il n'y a aucun commentaire pour cette version
À la version 3.1
modifié par Gaetan RETEL
sur 2025/03/12 03:57
sur 2025/03/12 03:57
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,16 +1,10 @@ 1 -Après avoir galéré sur la mise à jour de postgreSQL sur [[pgsql-prod>>doc:Services.PostgreSQL.WebHome]], j'ai pris le parti de 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 pris le parti de noter ici les étapes à suivre pour une upgrade sans histoires. 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 5 6 -{{toc/}} 7 - 8 - 9 - 10 - 11 11 == Précautions à prendre == 12 12 13 - 14 14 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. 15 15 16 16 {{warning}} ... ... @@ -27,14 +27,14 @@ 27 27 ((( 28 28 (% class="box" %) 29 29 ((( 30 -su - postgres -c "pg_dumpall -U postgres -p <port>" > /var/backups/pgsql_ <name>_backup.sql24 +su - postgres -c "pg_dumpall -U postgres -p <port>" > /var/backups/pgsql_main_backup.sql 31 31 32 -su - postgres -c "pg_dumpall ~-~-globals-only -U postgres -p <port>" > /var/backups/pgsql_ <name>_globals_backup.sql26 +su - postgres -c "pg_dumpall ~-~-globals-only -U postgres -p <port>" > /var/backups/pgsql_main_globals_backup.sql 33 33 ))) 34 34 ))) 35 35 36 36 {{info}} 37 -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/ utilisezpar exemple :31 +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/ utiliser par exemple : 38 38 {{/info}} 39 39 40 40 (% class="box" %) ... ... @@ -45,16 +45,21 @@ 45 45 ))) 46 46 ))) 47 47 48 -{{info}} 49 -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}} 50 -{{/info}} 51 51 43 +(% class="wikigeneratedid" %) 44 +Pour vérifier les packages installés, utiliser la commande 52 52 46 +(% class="box" %) 47 +((( 48 +(% class="box" %) 49 +((( 50 +dpkg -l | grep postgresql 51 +))) 52 +))) 53 53 54 54 55 55 == Préparation des nouveaux clusters == 56 56 57 - 58 58 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. 59 59 60 60 {{info}} ... ... @@ -71,9 +71,9 @@ 71 71 ))) 72 72 ))) 73 73 74 -Si vous n'avez jamais touché à postgreSQL, la commande pour sortir du terminal est \q 73 +Si comme moi, vous n'avez jamais touché à postgreSQL, la commande pour sortir du terminal est \q 75 75 76 - Ici, l'encodage est UTF-8 et le reste en C. Pour créer un cluster "main" utilisant pgsql 14 la commande est donc75 +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 77 77 78 78 (% class="box" %) 79 79 ((( ... ... @@ -84,7 +84,6 @@ 84 84 ))) 85 85 86 86 87 - 88 88 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]]. 89 89 90 90 ... ... @@ -98,7 +98,7 @@ 98 98 ))) 99 99 ))) 100 100 101 - 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 :99 +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 : 102 102 103 103 (% class="box" %) 104 104 ((( ... ... @@ -117,20 +117,35 @@ 117 117 118 118 Si vous voyez une ligne avec une tâche lancée par postgres, il faut l'arrêter. Voilà quelques commandes utiles : 119 119 118 +La commande suivante permet de stopper (ou de démarrer avec {{code language="none"}}start{{/code}}) un cluster spécifique d'une version pgsql donnée : 120 120 121 -La commande suivante permet de stopper un cluster spécifique d'une version pgsql donnée : {{code language="none"}}pg_ctlcluster 13 main stop{{/code}} (% id="cke_bm_63735S" style="display:none" %) (%%)(ou de démarrer avec {{code language="none"}}start{{/code}}) 120 +(% class="box" %) 121 +((( 122 +(% class="box" %) 123 +((( 124 +pg_ctlcluster 13 main stop 125 +))) 126 +))) 122 122 123 -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}}128 +Si pour une raison qui vous échappe 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 donné plus tôt, le PID est 5860) 124 124 130 +(% class="box" %) 131 +((( 132 +(% class="box" %) 133 +((( 134 +kill -9 <PID> 135 +))) 136 +))) 125 125 126 -Une fois les processus stoppés, on peut lancer la commande. 127 127 139 +Une fois les processus stoppé, on peut lancer la commande. 140 + 128 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 129 130 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.144 +Avant de lancer la commande, on notera l'existence du flag ~-~-check, dont on ne manquera pas de se servir. 132 132 133 -Pour la version 13 à 14, il faut donc taper pour lancer les vérifications :146 +Pour la version 13 à 14, il faut donc taper pour lancer les vérifications 134 134 135 135 (% class="box" %) 136 136 ((( ... ... @@ -146,14 +146,13 @@ 146 146 ))) 147 147 148 148 149 - 150 - 151 151 == Lancer l'upgrade == 152 152 164 +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. 153 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érifiezune nouvelle fois que des tâches n'ont pas été redémarréescomme expliqué danscédente.166 +Vérifier une nouvelle fois que des tâches n'ont pas été redémarré comme expliqué dans [label>Space.Page#HPréparationdesnouveauxclusters] [[ici>>#Préparationdesnouveauxclusters]] 155 155 156 -Assurez -vous qu'il y aitsuffisamment de place sur la VM,toujours avec {{code language="none"}}df-h{{/code}},les nouveaux clustersde la version14 ont pris~~5G.168 +Assurez vous qu'il y a suffisamment de place sur la VM, dans mon cas les nouveaux clusters ont pris 5G. 157 157 158 158 {{error}} 159 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. ... ... @@ -179,15 +179,11 @@ 179 179 {{/error}} 180 180 181 181 182 - 183 - 184 184 == Mise en place des nouveaux clusters == 185 185 186 - 187 - 188 188 Une fois les nouveaux clusters terminés et les données migrées, il va falloir terminer la configuration. 189 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 ligne198 +Ouvrez le fichier de configuration {{code language="none"}}pg_hba.conf{{/code}} de l'ancienne version, situé pour moi dans {{code language="none"}}/etc/postgresql/13/<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 191 192 192 (% class="box" %) 193 193 ((( ... ... @@ -194,7 +194,7 @@ 194 194 # Database administrative login by Unix domain socket 195 195 ))) 196 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}}.205 +Collez ces informations au même endroit dans le fichier de la nouvelle version, {{code language="none"}}/etc/postgresql/14/main/pg_hba.conf{{/code}}. 198 198 199 199 {{warning}} 200 200 N'oubliez pas de faire cette opérations pour chaque cluster ... ... @@ -201,17 +201,15 @@ 201 201 {{/warning}} 202 202 203 203 212 +Ouvrez ensuite le fichier {{code language="none"}}/etc/postgresql/14/main/postgresql.conf{{/code}} de la nouvelle version. Il faut configurer les ports des clusters, ainsi qu'autoriser les connexions. 204 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.214 +Si vous souhaitez garder les anciens clusters pour l'instant en cas de besoin, attribuez leurs des ports non utilisés. Mettez les ports de nouveaux clusters pour qu'il correspondent aux ports des anciens. 206 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'ailleursque la commande {{code language="none"}}rm -rf '/var/lib/postgresql/<version>/<cluster_name>'{{/code}}.216 +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 que la commande {{code language="none"}}rm -rf '/var/lib/postgresql/<version>/<cluster_name>'{{/code}}. 208 208 209 209 219 +Dans mon cas, le cluster main est au 5432 et le gitlab au 5433, donc dans {{code language="none"}}/etc/postgresql/14/gitlab/postgresql.conf{{/code}} cherchez et modifiez la ligne : 210 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 217 port = 5433 ... ... @@ -229,14 +229,10 @@ 229 229 {{/warning}} 230 230 231 231 232 - 233 - 234 234 == Mises à jour et optimisations == 235 235 240 +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 la 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. 236 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 240 Il va donc falloir se rendre dans chaque cluster : 241 241 242 242 (% class="box" %) ... ... @@ -259,7 +259,7 @@ 259 259 ))) 260 260 ))) 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}} pour ce clusterindiquait une mise à jour d'extension, on peut en même temps copier coller la commande qui pourrait par exemple être :264 +Si pour ce cluster le fichier {{code language="none"}}update_extensions.sql{{/code}} indiquait une mise à jour d'extension, on peut en même temps copier coller la commande qui pourrait par exemple être : 263 263 264 264 (% class="box" %) 265 265 ((( ... ... @@ -267,12 +267,8 @@ 267 267 ))) 268 268 269 269 270 - 271 - 272 272 == Redémarrer postgreSQL == 273 273 274 - 275 - 276 276 Une fois tout cela fait, il ne reste plus qu'à redémarrer postgreSQL : 277 277 278 278 (% class="box" %) ... ... @@ -285,19 +285,32 @@ 285 285 286 286 On peut ensuite vérifier avec la commande {{code language="none"}}pg_lsclusters{{/code}} que les deux nouveaux clusters sont opérationnels. 287 287 286 +Une commande utile pour le débogage est 288 288 288 +(% class="box" %) 289 +((( 290 +(% class="box" %) 291 +((( 292 +lsof -i 293 +))) 294 +))) 289 289 290 - Une commandeutilepour ledébogage est {{code language="none"}}lsof -i{{/code}}. Cette commande permet d'afficher les connexions actuelles. Il devrait y avoirparmiles résultatsquelque chose du genre:296 +qui permet d'afficher les connections actuelles. Il devrait y avoir à minima quelque chose du genre 291 291 292 292 (% class="box" %) 293 293 ((( 294 -postgres 220900 postgres 5u IPv4 4457404 0t0 TCP *:postgresql (LISTEN) # pour le port par défaut (5432) de postgres300 +postgres 220900 postgres 5u IPv4 4457404 0t0 TCP *:postgresql (LISTEN) 295 295 postgres 220900 postgres 6u IPv6 4457405 0t0 TCP *:postgresql (LISTEN) 296 296 297 -postgres 220901 postgres 5u IPv4 4457515 0t0 TCP *:5433 (LISTEN) # pour le cluster gitlab au 5433303 +postgres 220901 postgres 5u IPv4 4457515 0t0 TCP *:5433 (LISTEN) 298 298 postgres 220901 postgres 6u IPv6 4457516 0t0 TCP *:5433 (LISTEN) 305 +))) 299 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 307 +et également les machines et VM connectés, par exemple 308 + 309 +(% class="box" %) 310 +((( 311 +postgres 414816 postgres 9u IPv4 7792005 0t0 TCP pgsql-prod.prod.infra.atilla.org->gitlab-prod.prod.infra.atilla.org (ESTABLISHED) 301 301 ))) 302 302 303 303 {{success}} ... ... @@ -305,7 +305,7 @@ 305 305 {{/success}} 306 306 307 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 compteadmin (cfleteampass), 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.319 +Dans le cas de ce wiki, il y a eu des problèmes avec la macro children. Après un redémarrage de tomcat9 sur xwiki-prod et une mise à jour via une connexion avec le compte défaut de superadmin, 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 309 {{/info}} 310 310 311 311 (% class="wikigeneratedid" %)