Code source wiki de Mettre à jour pgsql sur pgsql-prod

Version 12.1 par Gaetan RETEL le 2025/03/12 14:08

version	line-number	content
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.
2.1	2
5.1	3	Les commandes listées ci dessous seront celles de la version que j'ai installée.
2.1	4
9.1	5	{{toc/}}
6.1	6
	7
10.1	8
	9
3.1	10	== Précautions à prendre ==
2.1	11
11.1	12
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.
2.1	14
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}}
2.1	18
	19	(% class="wikigeneratedid" %)
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.
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	(((
5.1	29	su - postgres -c "pg_dumpall -U postgres -p <port>" > /var/backups/pgsql_<name>_backup.sql
2.1	30
5.1	31	su - postgres -c "pg_dumpall ~-~-globals-only -U postgres -p <port>" > /var/backups/pgsql_<name>_globals_backup.sql
2.1	32	)))
	33	)))
	34
3.1	35	{{info}}
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 :
3.1	37	{{/info}}
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
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}}
2.1	50
	51
	52
	53
3.1	54	== Préparation des nouveaux clusters ==
2.1	55
11.1	56
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
3.1	59	{{info}}
2.1	60	on peut trouver les informations nécessaires en affichant les BDDs de chaque clusters :
3.1	61	{{/info}}
2.1	62
	63	(% class="box" %)
	64	(((
	65	(% class="box" %)
	66	(((
3.1	67	sudo -u postgres psql -p <port>
2.1	68
	69	\l
	70	)))
	71	)))
	72
10.1	73	Si vous n'avez jamais touché à postgreSQL, la commande pour sortir du terminal est \q
2.1	74
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
2.1	76
	77	(% class="box" %)
	78	(((
	79	(% class="box" %)
	80	(((
	81	pg_createcluster ~-~-locale=C ~-~-encoding=UTF8 14 main
	82	)))
	83	)))
	84
	85
10.1	86
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
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
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 :
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
10.1	120	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}})
3.1	121
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}}
3.1	123
	124
5.1	125	Une fois les processus stoppés, on peut lancer la commande.
3.1	126
2.1	127	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.
	128
	129
10.1	130	Avant de lancer la commande, on notera l'existence du flag {{code language="none"}}--check{{/code}}, dont on ne manquera pas de se servir.
2.1	131
5.1	132	Pour la version 13 à 14, il faut donc taper pour lancer les vérifications :
2.1	133
	134	(% class="box" %)
	135	(((
	136	(% class="box" %)
	137	(((
	138	/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
	139	)))
	140	)))
	141
	142	(% class="box infomessage" %)
	143	(((
3.1	144	À ce stade là, s'il y a des problèmes, google est votre ami.
2.1	145	)))
	146
	147
10.1	148
	149
3.1	150	== Lancer l'upgrade ==
2.1	151
11.1	152
10.1	153	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.
2.1	154
10.1	155	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.
3.1	156
	157	{{error}}
	158	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.
	159	{{/error}}
	160
	161	(% class="box" %)
2.1	162	(((
3.1	163	(% class="box" %)
	164	(((
	165	/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'
2.1	166	)))
3.1	167	)))
2.1	168
3.1	169	Il va donc falloir upgrader chaque cluster comme fait ci dessus, en remplaçant évidemment par le nom des clusters qui vous concernent.
	170
	171	{{warning}}
	172	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.
	173	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.
	174	{{/warning}}
	175
	176	{{error}}
	177	Ne pas exécuter les fichiers générés par la commande immédiatement
	178	{{/error}}
	179
	180
10.1	181
	182
3.1	183	== Mise en place des nouveaux clusters ==
	184
11.1	185
	186
3.1	187	Une fois les nouveaux clusters terminés et les données migrées, il va falloir terminer la configuration.
	188
10.1	189	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
3.1	190
2.1	191	(% class="box" %)
	192	(((
3.1	193	# Database administrative login by Unix domain socket
	194	)))
	195
10.1	196	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}}.
3.1	197
	198	{{warning}}
	199	N'oubliez pas de faire cette opérations pour chaque cluster
	200	{{/warning}}
	201
	202
	203
10.1	204	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.
3.1	205
10.1	206	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}}.
3.1	207
	208
5.1	209
10.1	210	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.
	211
	212	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 :
	213
2.1	214	(% class="box" %)
	215	(((
3.1	216	port = 5433
2.1	217	)))
3.1	218
	219	il faut également autoriser les connexions, cherchez et modifiez la ligne :
	220
	221	(% class="box" %)
	222	(((
	223	listen_addresses = '*'
2.1	224	)))
	225
3.1	226	{{warning}}
	227	N'oubliez pas de faire cette opérations pour chaque cluster
	228	{{/warning}}
	229
	230
10.1	231
	232
3.1	233	== Mises à jour et optimisations ==
	234
11.1	235
	236
5.1	237	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.
3.1	238
	239	Il va donc falloir se rendre dans chaque cluster :
	240
	241	(% class="box" %)
	242	(((
	243	(% class="box" %)
	244	(((
	245	sudo -u postgres psql -p <port>
	246	)))
	247	)))
	248
	249	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 :
	250
	251	(% class="box" %)
	252	(((
	253	(% class="box" %)
	254	(((
	255	\c postgres
	256
	257	REINDEX DATABASE postgres;
	258	)))
	259	)))
	260
10.1	261	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 :
3.1	262
	263	(% class="box" %)
	264	(((
	265	ALTER EXTENSION "pg_trgm" UPDATE;
	266	)))
	267
	268
10.1	269
	270
3.1	271	== Redémarrer postgreSQL ==
	272
11.1	273
	274
3.1	275	Une fois tout cela fait, il ne reste plus qu'à redémarrer postgreSQL :
	276
	277	(% class="box" %)
	278	(((
	279	(% class="box" %)
	280	(((
	281	systemctl start postgresql
	282	)))
	283	)))
	284
	285	On peut ensuite vérifier avec la commande {{code language="none"}}pg_lsclusters{{/code}} que les deux nouveaux clusters sont opérationnels.
	286
	287
	288
10.1	289	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 :
3.1	290
	291	(% class="box" %)
	292	(((
10.1	293	postgres 220900 postgres 5u IPv4 4457404 0t0 TCP *:postgresql (LISTEN) # pour le port par défaut (5432) de postgres
3.1	294	postgres 220900 postgres 6u IPv6 4457405 0t0 TCP *:postgresql (LISTEN)
	295
10.1	296	postgres 220901 postgres 5u IPv4 4457515 0t0 TCP *:5433 (LISTEN) # pour le cluster gitlab au 5433
3.1	297	postgres 220901 postgres 6u IPv6 4457516 0t0 TCP *:5433 (LISTEN)
	298
10.1	299	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
3.1	300	)))
	301
	302	{{success}}
	303	Il ne reste plus qu'a vérifier si les services ayant leur BDDs sur pgsql-prod sont repartis normalement.
	304	{{/success}}
	305
	306	{{info}}
10.1	307	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.
3.1	308	{{/info}}
	309
	310	(% class="wikigeneratedid" %)
2.1	311

Code source wiki de Mettre à jour pgsql sur pgsql-prod

Applications

Navigation