Skip to Content
Modifié par Gaetan RETEL le 2025/03/28 20:16
Masquer les derniers auteurs
Gaetan RETEL 5.1 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.
Gaetan RETEL 2.1 2
Gaetan RETEL 5.1 3 Les commandes listées ci dessous seront celles de la version que j'ai installée.
Gaetan RETEL 2.1 4
Gaetan RETEL 9.1 5 {{toc/}}
Gaetan RETEL 6.1 6
7
Gaetan RETEL 10.1 8
9
Gaetan RETEL 3.1 10 == Précautions à prendre ==
Gaetan RETEL 2.1 11
Gaetan RETEL 11.1 12
Gaetan RETEL 3.1 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.
Gaetan RETEL 2.1 14
Gaetan RETEL 3.1 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}}
Gaetan RETEL 2.1 18
19 (% class="wikigeneratedid" %)
Gaetan RETEL 3.1 20 Pour voir les différents clusters présents, utilisez 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.
Gaetan RETEL 2.1 21
22 (% class="wikigeneratedid" %)
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.
24
25 (% class="box" %)
26 (((
27 (% class="box" %)
28 (((
Gaetan RETEL 5.1 29 su - postgres -c "pg_dumpall -U postgres -p <port>" > /var/backups/pgsql_<name>_backup.sql
Gaetan RETEL 2.1 30
Gaetan RETEL 5.1 31 su - postgres -c "pg_dumpall ~-~-globals-only -U postgres -p <port>" > /var/backups/pgsql_<name>_globals_backup.sql
Gaetan RETEL 2.1 32 )))
33 )))
34
Gaetan RETEL 3.1 35 {{info}}
Gaetan RETEL 5.1 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 :
Gaetan RETEL 3.1 37 {{/info}}
Gaetan RETEL 2.1 38
39 (% class="box" %)
40 (((
41 (% class="box" %)
42 (((
43 scp -J root@atilla.org pgsql-prod.prod.infra:/var/backups/pgsql_main_backup.sql ./pgsql/
44 )))
45 )))
46
Gaetan RETEL 10.1 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}}
Gaetan RETEL 2.1 50
51
52
53
Gaetan RETEL 3.1 54 == Préparation des nouveaux clusters ==
Gaetan RETEL 2.1 55
Gaetan RETEL 11.1 56
Gaetan RETEL 2.1 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
Gaetan RETEL 3.1 59 {{info}}
Gaetan RETEL 2.1 60 on peut trouver les informations nécessaires en affichant les BDDs de chaque clusters :
Gaetan RETEL 3.1 61 {{/info}}
Gaetan RETEL 2.1 62
63 (% class="box" %)
64 (((
65 (% class="box" %)
66 (((
Gaetan RETEL 3.1 67 sudo -u postgres psql -p <port>
Gaetan RETEL 2.1 68
69 \l
70 )))
71 )))
72
Gaetan RETEL 13.1 73 Si vous n'avez jamais touché à postgreSQL, la commande pour sortir du terminal est {{code language="none"}}\q{{/code}}
Gaetan RETEL 2.1 74
Gaetan RETEL 10.1 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
Gaetan RETEL 2.1 76
77 (% class="box" %)
78 (((
79 (% class="box" %)
80 (((
81 pg_createcluster ~-~-locale=C ~-~-encoding=UTF8 14 main
82 )))
83 )))
84
85
Gaetan RETEL 10.1 86
Gaetan RETEL 2.1 87 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]].
88
Gaetan RETEL 3.1 89
90 Afin de pouvoir lancer la commande, il va falloir stopper postgreSQL :
91
92 (% class="box" %)
93 (((
94 (% class="box" %)
95 (((
96 systemctl stop postgresql
97 )))
98 )))
99
Gaetan RETEL 10.1 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 :
Gaetan RETEL 3.1 101
102 (% class="box" %)
103 (((
104 (% class="box" %)
105 (((
106 ps -ef | grep postgres
107 )))
108 )))
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
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
Gaetan RETEL 15.1 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}})
Gaetan RETEL 3.1 121
Gaetan RETEL 10.1 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}}
Gaetan RETEL 3.1 123
124
Gaetan RETEL 14.1 125
Gaetan RETEL 5.1 126 Une fois les processus stoppés, on peut lancer la commande.
Gaetan RETEL 3.1 127
Gaetan RETEL 2.1 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
Gaetan RETEL 10.1 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.
Gaetan RETEL 2.1 132
Gaetan RETEL 5.1 133 Pour la version 13 à 14, il faut donc taper pour lancer les vérifications :
Gaetan RETEL 2.1 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 )))
141 )))
142
143 (% class="box infomessage" %)
144 (((
Gaetan RETEL 3.1 145 À ce stade là, s'il y a des problèmes, google est votre ami.
Gaetan RETEL 2.1 146 )))
147
148
Gaetan RETEL 10.1 149
150
Gaetan RETEL 3.1 151 == Lancer l'upgrade ==
Gaetan RETEL 2.1 152
Gaetan RETEL 11.1 153
Gaetan RETEL 10.1 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.
Gaetan RETEL 2.1 155
Gaetan RETEL 10.1 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.
Gaetan RETEL 3.1 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 (% class="box" %)
Gaetan RETEL 2.1 163 (((
Gaetan RETEL 3.1 164 (% class="box" %)
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'
Gaetan RETEL 2.1 167 )))
Gaetan RETEL 3.1 168 )))
Gaetan RETEL 2.1 169
Gaetan RETEL 3.1 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
172 {{warning}}
Gaetan RETEL 15.1 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.
Gaetan RETEL 3.1 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}}
176
177 {{error}}
178 Ne pas exécuter les fichiers générés par la commande immédiatement
179 {{/error}}
180
181
Gaetan RETEL 10.1 182
183
Gaetan RETEL 3.1 184 == Mise en place des nouveaux clusters ==
185
Gaetan RETEL 11.1 186
187
Gaetan RETEL 3.1 188 Une fois les nouveaux clusters terminés et les données migrées, il va falloir terminer la configuration.
189
Gaetan RETEL 10.1 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
Gaetan RETEL 3.1 191
Gaetan RETEL 2.1 192 (% class="box" %)
193 (((
Gaetan RETEL 3.1 194 # Database administrative login by Unix domain socket
195 )))
196
Gaetan RETEL 10.1 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}}.
Gaetan RETEL 3.1 198
199 {{warning}}
200 N'oubliez pas de faire cette opérations pour chaque cluster
201 {{/warning}}
202
203
204
Gaetan RETEL 10.1 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.
Gaetan RETEL 3.1 206
Gaetan RETEL 10.1 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}}.
Gaetan RETEL 3.1 208
209
Gaetan RETEL 5.1 210
Gaetan RETEL 10.1 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
Gaetan RETEL 2.1 215 (% class="box" %)
216 (((
Gaetan RETEL 3.1 217 port = 5433
Gaetan RETEL 2.1 218 )))
Gaetan RETEL 3.1 219
220 il faut également autoriser les connexions, cherchez et modifiez la ligne :
221
222 (% class="box" %)
223 (((
224 listen_addresses = '*'
Gaetan RETEL 2.1 225 )))
226
Gaetan RETEL 3.1 227 {{warning}}
228 N'oubliez pas de faire cette opérations pour chaque cluster
229 {{/warning}}
230
231
Gaetan RETEL 10.1 232
233
Gaetan RETEL 3.1 234 == Mises à jour et optimisations ==
235
Gaetan RETEL 11.1 236
237
Gaetan RETEL 5.1 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.
Gaetan RETEL 3.1 239
240 Il va donc falloir se rendre dans chaque cluster :
241
242 (% class="box" %)
243 (((
244 (% class="box" %)
245 (((
246 sudo -u postgres psql -p <port>
247 )))
248 )))
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
252 (% class="box" %)
253 (((
254 (% class="box" %)
255 (((
256 \c postgres
257
258 REINDEX DATABASE postgres;
259 )))
260 )))
261
Gaetan RETEL 16.1 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 :
Gaetan RETEL 3.1 263
264 (% class="box" %)
265 (((
266 ALTER EXTENSION "pg_trgm" UPDATE;
267 )))
268
269
Gaetan RETEL 10.1 270
271
Gaetan RETEL 3.1 272 == Redémarrer postgreSQL ==
273
Gaetan RETEL 11.1 274
275
Gaetan RETEL 3.1 276 Une fois tout cela fait, il ne reste plus qu'à redémarrer postgreSQL :
277
278 (% class="box" %)
279 (((
280 (% class="box" %)
281 (((
282 systemctl start postgresql
283 )))
284 )))
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
Gaetan RETEL 10.1 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 :
Gaetan RETEL 3.1 291
292 (% class="box" %)
293 (((
Gaetan RETEL 10.1 294 postgres  220900 postgres    5u  IPv4 4457404      0t0  TCP *:postgresql (LISTEN)  # pour le port par défaut (5432) de postgres
Gaetan RETEL 3.1 295 postgres  220900 postgres    6u  IPv6 4457405      0t0  TCP *:postgresql (LISTEN)
296
Gaetan RETEL 10.1 297 postgres  220901 postgres    5u  IPv4 4457515      0t0  TCP *:5433 (LISTEN)  # pour le cluster gitlab au 5433
Gaetan RETEL 3.1 298 postgres  220901 postgres    6u  IPv6 4457516      0t0  TCP *:5433 (LISTEN)
299
Gaetan RETEL 10.1 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
Gaetan RETEL 3.1 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}}
Gaetan RETEL 10.1 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.
Gaetan RETEL 3.1 309 {{/info}}
310
311 (% class="wikigeneratedid" %)
Gaetan RETEL 2.1 312