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
Commentaire de modification : Il n'y a aucun commentaire pour cette version
À la version 9.1
modifié par Gaetan RETEL
sur 2025/03/12 04:26
Commentaire de modification : Il n'y a aucun commentaire pour cette version

Résumé

Détails

Propriétés de la Page
Contenu
... ... @@ -6,11 +6,8 @@
6 6  {{toc/}}
7 7  
8 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}}
... ... @@ -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  
46 +(% class="wikigeneratedid" %)
47 +Pour vérifier les packages installés, utilisez la commande
52 52  
49 +(% class="box" %)
50 +(((
51 +(% class="box" %)
52 +(((
53 +dpkg -l | grep postgresql
54 +)))
55 +)))
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
76 +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 donc
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
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 :
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 :
102 102  
103 103  (% class="box" %)
104 104  (((
... ... @@ -117,18 +117,33 @@
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  
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 :
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}})
123 +(% class="box" %)
124 +(((
125 +(% class="box" %)
126 +(((
127 +pg_ctlcluster 13 main stop
128 +)))
129 +)))
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}}
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 root donné plus tôt, le PID est 5860)
124 124  
133 +(% class="box" %)
134 +(((
135 +(% class="box" %)
136 +(((
137 +kill -9 <PID>
138 +)))
139 +)))
125 125  
141 +
126 126  Une fois les processus stoppés, on peut lancer la commande.
127 127  
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.
147 +Avant de lancer la commande, on notera l'existence du flag ~-~-check, dont on ne manquera pas de se servir.
132 132  
133 133  Pour la version 13 à 14, il faut donc taper pour lancer les vérifications :
134 134  
... ... @@ -146,14 +146,13 @@
146 146  )))
147 147  
148 148  
149 -
150 -
151 151  == Lancer l'upgrade ==
152 152  
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.
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érifiez une nouvelle fois que des tâches n'ont pas été redémarrées comme expliqué dans la précédente section.
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.
155 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.
171 +Assurez-vous qu'il y ait suffisamment de place sur la VM, toujours avec {{code language="none"}}df -h{{/code}}, 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 ligne
201 +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}}.
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}}.
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  
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.
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.
217 +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}}.
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'ailleurs que la commande {{code language="none"}}rm -rf '/var/lib/postgresql/<version>/<cluster_name>'{{/code}}.
208 208  
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.
209 209  
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 :
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,12 +229,8 @@
229 229  {{/warning}}
230 230  
231 231  
232 -
233 -
234 234  == Mises à jour et optimisations ==
235 235  
236 -
237 -
238 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 239  
240 240  Il va donc falloir se rendre dans chaque cluster :
... ... @@ -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 cluster indiquait une mise à jour d'extension, on peut en même temps copier coller la commande qui pourrait par exemple être :
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 :
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  
289 +Une commande utile pour le débogage est
288 288  
291 +(% class="box" %)
292 +(((
293 +(% class="box" %)
294 +(((
295 +lsof -i
296 +)))
297 +)))
289 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 :
299 +Cette commande permet d'afficher les connexions actuelles. Il devrait y avoir parmi les résultats 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 postgres
303 +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 5433
306 +postgres  220901 postgres    5u  IPv4 4457515      0t0  TCP *:5433 (LISTEN)
298 298  postgres  220901 postgres    6u  IPv6 4457516      0t0  TCP *:5433 (LISTEN)
308 +)))
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
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)
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 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.
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é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" %)