Skip to Content

Modifications pour le document Mettre à jour pgsql sur pgsql-prod

Modifié par Gaetan RETEL le 2025/10/05 00:22
Depuis la version 10.1
modifié par Gaetan RETEL
sur 2025/03/12 14:06
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
Commentaire de modification : Il n'y a aucun commentaire pour cette version

Résumé

Détails

Propriétés de la Page
Contenu
... ... @@ -1,13 +1,8 @@
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 celles de 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 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.
... ... @@ -26,14 +26,14 @@
26 26  (((
27 27  (% class="box" %)
28 28  (((
29 -su - postgres -c "pg_dumpall -U postgres -p <port>" > /var/backups/pgsql_<name>_backup.sql
24 +su - postgres -c "pg_dumpall -U postgres -p <port>" > /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.sql
26 +su - postgres -c "pg_dumpall ~-~-globals-only -U postgres -p <port>" > /var/backups/pgsql_main_globals_backup.sql
32 32  )))
33 33  )))
34 34  
35 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 :
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 :
37 37  {{/info}}
38 38  
39 39  (% class="box" %)
... ... @@ -44,11 +44,17 @@
44 44  )))
45 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 50  
43 +(% class="wikigeneratedid" %)
44 +Pour vérifier les packages installés, utiliser la commande
51 51  
46 +(% class="box" %)
47 +(((
48 +(% class="box" %)
49 +(((
50 +dpkg -l | grep postgresql
51 +)))
52 +)))
52 52  
53 53  
54 54  == Préparation des nouveaux clusters ==
... ... @@ -69,9 +69,9 @@
69 69  )))
70 70  )))
71 71  
72 -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
73 73  
74 -Ici, l'encodage est UTF-8 et le reste en C. Pour créer un cluster "main" utilisant pgsql 14 la commande est donc
75 +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
75 75  
76 76  (% class="box" %)
77 77  (((
... ... @@ -82,7 +82,6 @@
82 82  )))
83 83  
84 84  
85 -
86 86  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]].
87 87  
88 88  
... ... @@ -96,7 +96,7 @@
96 96  )))
97 97  )))
98 98  
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 :
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 :
100 100  
101 101  (% class="box" %)
102 102  (((
... ... @@ -115,20 +115,35 @@
115 115  
116 116  Si vous voyez une ligne avec une tâche lancée par postgres, il faut l'arrêter. Voilà quelques commandes utiles :
117 117  
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 :
118 118  
119 -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 +)))
120 120  
121 -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)
122 122  
130 +(% class="box" %)
131 +(((
132 +(% class="box" %)
133 +(((
134 +kill -9 <PID>
135 +)))
136 +)))
123 123  
124 -Une fois les processus stoppés, on peut lancer la commande.
125 125  
139 +Une fois les processus stoppé, on peut lancer la commande.
140 +
126 126  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.
127 127  
128 128  
129 -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.
130 130  
131 -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
132 132  
133 133  (% class="box" %)
134 134  (((
... ... @@ -144,14 +144,14 @@
144 144  )))
145 145  
146 146  
147 -
148 -
149 149  == Lancer l'upgrade ==
150 150  
151 -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.
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.
152 152  
153 -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.
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]]
154 154  
168 +Assurez vous qu'il y a suffisamment de place sur la VM, dans mon cas les nouveaux clusters ont pris 5G.
169 +
155 155  {{error}}
156 156  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.
157 157  {{/error}}
... ... @@ -176,13 +176,11 @@
176 176  {{/error}}
177 177  
178 178  
179 -
180 -
181 181  == Mise en place des nouveaux clusters ==
182 182  
183 183  Une fois les nouveaux clusters terminés et les données migrées, il va falloir terminer la configuration.
184 184  
185 -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
198 +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
186 186  
187 187  (% class="box" %)
188 188  (((
... ... @@ -189,7 +189,7 @@
189 189  # Database administrative login by Unix domain socket
190 190  )))
191 191  
192 -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}}.
193 193  
194 194  {{warning}}
195 195  N'oubliez pas de faire cette opérations pour chaque cluster
... ... @@ -196,17 +196,15 @@
196 196  {{/warning}}
197 197  
198 198  
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.
199 199  
200 -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.
201 201  
202 -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}}.
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}}.
203 203  
204 204  
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 :
205 205  
206 -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.
207 -
208 -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 :
209 -
210 210  (% class="box" %)
211 211  (((
212 212  port = 5433
... ... @@ -224,11 +224,9 @@
224 224  {{/warning}}
225 225  
226 226  
227 -
228 -
229 229  == Mises à jour et optimisations ==
230 230  
231 -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.
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.
232 232  
233 233  Il va donc falloir se rendre dans chaque cluster :
234 234  
... ... @@ -252,7 +252,7 @@
252 252  )))
253 253  )))
254 254  
255 -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 :
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 :
256 256  
257 257  (% class="box" %)
258 258  (((
... ... @@ -260,8 +260,6 @@
260 260  )))
261 261  
262 262  
263 -
264 -
265 265  == Redémarrer postgreSQL ==
266 266  
267 267  Une fois tout cela fait, il ne reste plus qu'à redémarrer postgreSQL :
... ... @@ -276,19 +276,32 @@
276 276  
277 277  On peut ensuite vérifier avec la commande {{code language="none"}}pg_lsclusters{{/code}} que les deux nouveaux clusters sont opérationnels.
278 278  
286 +Une commande utile pour le débogage est
279 279  
288 +(% class="box" %)
289 +(((
290 +(% class="box" %)
291 +(((
292 +lsof -i
293 +)))
294 +)))
280 280  
281 -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 :
296 +qui permet d'afficher les connections actuelles. Il devrait y avoir à minima quelque chose du genre
282 282  
283 283  (% class="box" %)
284 284  (((
285 -postgres  220900 postgres    5u  IPv4 4457404      0t0  TCP *:postgresql (LISTEN)  # pour le port par défaut (5432) de postgres
300 +postgres  220900 postgres    5u  IPv4 4457404      0t0  TCP *:postgresql (LISTEN)
286 286  postgres  220900 postgres    6u  IPv6 4457405      0t0  TCP *:postgresql (LISTEN)
287 287  
288 -postgres  220901 postgres    5u  IPv4 4457515      0t0  TCP *:5433 (LISTEN)  # pour le cluster gitlab au 5433
303 +postgres  220901 postgres    5u  IPv4 4457515      0t0  TCP *:5433 (LISTEN)
289 289  postgres  220901 postgres    6u  IPv6 4457516      0t0  TCP *:5433 (LISTEN)
305 +)))
290 290  
291 -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)
292 292  )))
293 293  
294 294  {{success}}
... ... @@ -296,7 +296,7 @@
296 296  {{/success}}
297 297  
298 298  {{info}}
299 -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.
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.
300 300  {{/info}}
301 301  
302 302  (% class="wikigeneratedid" %)