Modifications pour le document Mettre à jour pgsql sur pgsql-prod
Modifié par Gaetan RETEL le 2025/03/28 20:16
Depuis la version 9.1
modifié par Gaetan RETEL
sur 2025/03/12 04:26
sur 2025/03/12 04:26
Commentaire de modification :
Il n'y a aucun commentaire pour cette version
À 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
Résumé
-
Propriétés de la Page (1 modifications, 0 ajouts, 0 suppressions)
Détails
- Propriétés de la Page
-
- Contenu
-
... ... @@ -6,8 +6,11 @@ 6 6 {{toc/}} 7 7 8 8 9 + 10 + 9 9 == Précautions à prendre == 10 10 13 + 11 11 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. 12 12 13 13 {{warning}} ... ... @@ -42,21 +42,16 @@ 42 42 ))) 43 43 ))) 44 44 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}} 45 45 46 -(% class="wikigeneratedid" %) 47 -Pour vérifier les packages installés, utilisez la commande 48 48 49 -(% class="box" %) 50 -((( 51 -(% class="box" %) 52 -((( 53 -dpkg -l | grep postgresql 54 -))) 55 -))) 56 56 57 57 58 58 == Préparation des nouveaux clusters == 59 59 57 + 60 60 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. 61 61 62 62 {{info}} ... ... @@ -73,9 +73,9 @@ 73 73 ))) 74 74 ))) 75 75 76 -Si comme moi,vous n'avez jamais touché à postgreSQL, la commande pour sortir du terminal est \q74 +Si vous n'avez jamais touché à postgreSQL, la commande pour sortir du terminal est \q 77 77 78 - Dans moncas, l'encodage est UTF-8 et le reste en C. Pour créer un cluster "main" utilisant pgsql 14 la commande est donc76 +Ici, l'encodage est UTF-8 et le reste en C. Pour créer un cluster "main" utilisant pgsql 14 la commande est donc 79 79 80 80 (% class="box" %) 81 81 ((( ... ... @@ -86,6 +86,7 @@ 86 86 ))) 87 87 88 88 87 + 89 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]]. 90 90 91 91 ... ... @@ -99,7 +99,7 @@ 99 99 ))) 100 100 ))) 101 101 102 - 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 +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 : 103 103 104 104 (% class="box" %) 105 105 ((( ... ... @@ -118,33 +118,18 @@ 118 118 119 119 Si vous voyez une ligne avec une tâche lancée par postgres, il faut l'arrêter. Voilà quelques commandes utiles : 120 120 121 -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 : 122 122 123 -(% class="box" %) 124 -((( 125 -(% class="box" %) 126 -((( 127 -pg_ctlcluster 13 main stop 128 -))) 129 -))) 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}}) 130 130 131 -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 rootdonnéplus tôt, le PID est 5860)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}} 132 132 133 -(% class="box" %) 134 -((( 135 -(% class="box" %) 136 -((( 137 -kill -9 <PID> 138 -))) 139 -))) 140 140 141 - 142 142 Une fois les processus stoppés, on peut lancer la commande. 143 143 144 144 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. 145 145 146 146 147 -Avant de lancer la commande, on notera l'existence du flag ~-~-check, dont on ne manquera pas de se servir.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. 148 148 149 149 Pour la version 13 à 14, il faut donc taper pour lancer les vérifications : 150 150 ... ... @@ -162,13 +162,14 @@ 162 162 ))) 163 163 164 164 149 + 150 + 165 165 == Lancer l'upgrade == 166 166 167 -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. 168 168 169 -Vérifiez une nouvelle fois que des tâches n'ont pas été redémarrées comme expliqué dans la précédente section. 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. 170 170 171 -Assurez-vous qu'il y ait suffisamment de place sur la VM, toujours avec {{code language="none"}}df -h{{/code}}, dans mon casles nouveaux clusters ont pris ~~5G.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. 172 172 173 173 {{error}} 174 174 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. ... ... @@ -194,11 +194,15 @@ 194 194 {{/error}} 195 195 196 196 182 + 183 + 197 197 == Mise en place des nouveaux clusters == 198 198 186 + 187 + 199 199 Une fois les nouveaux clusters terminés et les données migrées, il va falloir terminer la configuration. 200 200 201 -Ouvrez le fichier de configuration {{code language="none"}}pg_hba.conf{{/code}} de l'ancienne version, situé pour moidans {{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 ligne190 +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 202 202 203 203 (% class="box" %) 204 204 ((( ... ... @@ -205,7 +205,7 @@ 205 205 # Database administrative login by Unix domain socket 206 206 ))) 207 207 208 -Collez ces informations au même endroit dans le fichier de la nouvelle version, {{code language="none"}}/etc/postgresql/ 14/<cluster_name>/pg_hba.conf{{/code}}.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}}. 209 209 210 210 {{warning}} 211 211 N'oubliez pas de faire cette opérations pour chaque cluster ... ... @@ -212,15 +212,17 @@ 212 212 {{/warning}} 213 213 214 214 215 -Si vous souhaitez garder les anciens clusters pour l'instant en cas de besoin, attribuez leurs des ports non utilisés. Parametrez 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. 216 216 217 -Si vous souhaitez supprimer les anciens clusters,vouspouvezmaintenantlefaire enexécutant lesfichiers{{codelanguage="none"}}delete_old_cluster.sh{{/code}}qui ont été générésar {{codelanguage="none"}}pg_upgrade{{/code}}. Ils necontiennentquela commande{{code language="none"}}rm-rf '/var/lib/postgresql/<version>/<cluster_name>'{{/code}}.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. 218 218 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}}. 219 219 220 -Ouvrez ensuite le fichier {{code language="none"}}/etc/postgresql/14/<cluster_name>/postgresql.conf{{/code}} de la nouvelle version. Il faut configurer les ports des clusters, et autoriser les connexions. 221 221 222 -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}} je cherche et modifie la ligne : 223 223 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 + 224 224 (% class="box" %) 225 225 ((( 226 226 port = 5433 ... ... @@ -238,8 +238,12 @@ 238 238 {{/warning}} 239 239 240 240 232 + 233 + 241 241 == Mises à jour et optimisations == 242 242 236 + 237 + 243 243 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. 244 244 245 245 Il va donc falloir se rendre dans chaque cluster : ... ... @@ -264,7 +264,7 @@ 264 264 ))) 265 265 ))) 266 266 267 -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 : 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 cluster indiquait une mise à jour d'extension, on peut en même temps copier coller la commande qui pourrait par exemple être : 268 268 269 269 (% class="box" %) 270 270 ((( ... ... @@ -272,8 +272,12 @@ 272 272 ))) 273 273 274 274 270 + 271 + 275 275 == Redémarrer postgreSQL == 276 276 274 + 275 + 277 277 Une fois tout cela fait, il ne reste plus qu'à redémarrer postgreSQL : 278 278 279 279 (% class="box" %) ... ... @@ -286,32 +286,19 @@ 286 286 287 287 On peut ensuite vérifier avec la commande {{code language="none"}}pg_lsclusters{{/code}} que les deux nouveaux clusters sont opérationnels. 288 288 289 -Une commande utile pour le débogage est 290 290 291 -(% class="box" %) 292 -((( 293 -(% class="box" %) 294 -((( 295 -lsof -i 296 -))) 297 -))) 298 298 299 -Cette commande permet d'afficher les connexions actuelles. Il devrait y avoir parmi les résultats quelque chose du genre : 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 : 300 300 301 301 (% class="box" %) 302 302 ((( 303 -postgres 220900 postgres 5u IPv4 4457404 0t0 TCP *:postgresql (LISTEN) 294 +postgres 220900 postgres 5u IPv4 4457404 0t0 TCP *:postgresql (LISTEN) # pour le port par défaut (5432) de postgres 304 304 postgres 220900 postgres 6u IPv6 4457405 0t0 TCP *:postgresql (LISTEN) 305 305 306 -postgres 220901 postgres 5u IPv4 4457515 0t0 TCP *:5433 (LISTEN) 297 +postgres 220901 postgres 5u IPv4 4457515 0t0 TCP *:5433 (LISTEN) # pour le cluster gitlab au 5433 307 307 postgres 220901 postgres 6u IPv6 4457516 0t0 TCP *:5433 (LISTEN) 308 -))) 309 309 310 -et également les machines et VM connectés, par exemple 311 - 312 -(% class="box" %) 313 -((( 314 -postgres 414816 postgres 9u IPv4 7792005 0t0 TCP pgsql-prod.prod.infra.atilla.org->gitlab-prod.prod.infra.atilla.org (ESTABLISHED) 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 315 315 ))) 316 316 317 317 {{success}} ... ... @@ -319,7 +319,7 @@ 319 319 {{/success}} 320 320 321 321 {{info}} 322 -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 éfautdesuperadmin, 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.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. 323 323 {{/info}} 324 324 325 325 (% class="wikigeneratedid" %)