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

Résumé

• Propriétés de la Page (1 modifications, 0 ajouts, 0 suppressions)

Détails

Propriétés de la Page

Contenu

...	...	@@ -117,11 +117,12 @@
117	117	Si vous voyez une ligne avec une tâche lancée par postgres, il faut l'arrêter. Voilà quelques commandes utiles :
118	118
119	119
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}})
	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}})
121	121
122	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}}
123	123
124	124
	125	+
125	125	Une fois les processus stoppés, on peut lancer la commande.
126	126
127	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.
...	...	@@ -169,7 +169,7 @@
169	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	170
171	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	+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	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	174	{{/warning}}
175	175
...	...	@@ -234,7 +234,7 @@
234	234
235	235
236	236
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.
	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 manuellement. Si l'envie vous prend de créer un script et automatiser ça, faites-vous plaisir.
238	238
239	239	Il va donc falloir se rendre dans chaque cluster :
240	240
...	...	@@ -258,7 +258,7 @@
258	258	)))
259	259	)))
260	260
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 :
	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 :
262	262
263	263	(% class="box" %)
264	264	(((