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

Modifié par Gaetan RETEL le 2025/03/28 20:16

From 1.2 to 2.1 From 3.1 to 4.1

Depuis la version 2.1

modifié par Gaetan RETEL
sur 2025/03/12 01:58

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

Source
Rendu

Résumé

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

Détails

Propriétés de la Page

Contenu

@@ -1,19 +1,18 @@
--Après avoir galéré sur la mise à jour de postgreSQL sur [[pgsql-prod>>doc:Services.PostgreSQL.WebHome]], j'ai décidé de noter ici les étapes à suivre pour une upgrade sans histoire.
++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.
  Les commandes listées ci dessous seront celle de la version que j'ai installé.
--=== Précautions à prendre ===
++== Précautions à prendre ==
--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}}. Pour cela on va 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.
++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.
--(% class="box warningmessage" %)
--(((
--Attention, 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
--)))
++{{warning}}
++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.
++{{/warning}}
  (% class="wikigeneratedid" %)
--Pour voir les différents clusters présents, utiliser 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.
++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.
  (% class="wikigeneratedid" %)
  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.
@@ -22,16 +22,15 @@
  (((
  (% class="box" %)
  (((
--su - postgres -c "pg_dumpall -U postgres -p 5432" > /var/backups/pgsql_main_backup.sql
++su - postgres -c "pg_dumpall -U postgres -p <port>" > /var/backups/pgsql_main_backup.sql
--su - postgres -c "pg_dumpall ~-~-globals-only -U postgres -p 5432" > /var/backups/pgsql_main_globals_backup.sql
++su - postgres -c "pg_dumpall ~-~-globals-only -U postgres -p <port>" > /var/backups/pgsql_main_globals_backup.sql
  )))
  )))
--(% class="box warningmessage" %)
--(((
--Penser à 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 :
--)))
++{{info}}
++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 :
++{{/info}}
  (% class="box" %)
  (((
@@ -54,26 +54,25 @@
  )))
--=== Préparation des nouveaux clusters ===
++== Préparation des nouveaux clusters ==
  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.
--(% class="box infomessage" %)
--(((
++{{info}}
  on peut trouver les informations nécessaires en affichant les BDDs de chaque clusters :
--)))
++{{/info}}
  (% class="box" %)
  (((
  (% class="box" %)
  (((
--sudo -u postgres psql -p 5432
++sudo -u postgres psql -p <port>
  \l
  )))
  )))
--Si comme moi vous n'avez jamais touché à postgreSQL, la commande pour sortir du terminal est \q
++Si comme moi, vous n'avez jamais touché à postgreSQL, la commande pour sortir du terminal est \q
  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
@@ -88,6 +88,59 @@
  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]].
++
++Afin de pouvoir lancer la commande, il va falloir stopper postgreSQL :
++
++(% class="box" %)
++(((
++(% class="box" %)
++(((
++systemctl stop postgresql
++)))
++)))
++
++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 :
++
++(% class="box" %)
++(((
++(% class="box" %)
++(((
++ps -ef | grep postgres
++)))
++)))
++
++La seule tâche qui devrait apparaître est celle lancé par root, par exemple :
++
++(% class="box" %)
++(((
++root        5860  0.0  0.1   6356  2172 pts/0    S+   15:42   0:00 grep ~-~-color=auto postgres
++)))
++
++Si vous voyez une ligne avec une tâche lancée par postgres, il faut l'arrêter. Voilà quelques commandes utiles :
++
++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 :
++
++(% class="box" %)
++(((
++(% class="box" %)
++(((
++pg_ctlcluster 13 main stop
++)))
++)))
++
++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)
++
++(% class="box" %)
++(((
++(% class="box" %)
++(((
++kill -9 <PID>
++)))
++)))
++
++
++Une fois les processus stoppé, on peut lancer la commande.
++
  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.
@@ -105,25 +105,169 @@
  (% class="box infomessage" %)
  (((
--À ce stade là s'il y a des problèmes, google est votre ami.
++À ce stade là, s'il y a des problèmes, google est votre ami.
  )))
--=== Lancer l'upgrade ===
++== Lancer l'upgrade ==
  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.
--(% class="box errormessage" %)
++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]]
++
++Assurez vous qu'il y a suffisamment de place sur la VM, dans mon cas les nouveaux clusters ont pris 5G.
++
++{{error}}
++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.
++{{/error}}
++
++(% class="box" %)
  (((
--Pour la suite, lisez bien TOUTES les infos avant de vous lancer dans les commandes des différents clusters, sinon vous risquez de devoir recommencer.
++(% class="box" %)
++(((
++/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'
  )))
++)))
++Il va donc falloir upgrader chaque cluster comme fait ci dessus, en remplaçant évidemment par le nom des clusters qui vous concernent.
++
++{{warning}}
++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.
++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.
++{{/warning}}
++
++{{error}}
++Ne pas exécuter les fichiers générés par la commande immédiatement
++{{/error}}
++
++
++== Mise en place des nouveaux clusters ==
++
++Une fois les nouveaux clusters terminés et les données migrées, il va falloir terminer la configuration.
++
++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
++
  (% class="box" %)
  (((
++# Database administrative login by Unix domain socket
++)))
++
++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}}.
++
++{{warning}}
++N'oubliez pas de faire cette opérations pour chaque cluster
++{{/warning}}
++
++
++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.
++
++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.
++
++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}}.
++
++
++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 :
++
  (% class="box" %)
  (((
--/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'
++port = 5433
  )))
++
++il faut également autoriser les connexions, cherchez et modifiez la ligne :
++
++(% class="box" %)
++(((
++listen_addresses = '*'
  )))
++{{warning}}
++N'oubliez pas de faire cette opérations pour chaque cluster
++{{/warning}}
++
++
++== Mises à jour et optimisations ==
++
++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.
++
++Il va donc falloir se rendre dans chaque cluster :
++
++(% class="box" %)
++(((
++(% class="box" %)
++(((
++sudo -u postgres psql -p <port>
++)))
++)))
++
++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 :
++
++(% class="box" %)
++(((
++(% class="box" %)
++(((
++\c postgres
++
++REINDEX DATABASE postgres;
++)))
++)))
++
++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 :
++
++(% class="box" %)
++(((
++ALTER EXTENSION "pg_trgm" UPDATE;
++)))
++
++
++== Redémarrer postgreSQL ==
++
++Une fois tout cela fait, il ne reste plus qu'à redémarrer postgreSQL :
++
++(% class="box" %)
++(((
++(% class="box" %)
++(((
++systemctl start postgresql
++)))
++)))
++
++On peut ensuite vérifier avec la commande {{code language="none"}}pg_lsclusters{{/code}} que les deux nouveaux clusters sont opérationnels.
++
++Une commande utile pour le débogage est
++
++(% class="box" %)
++(((
++(% class="box" %)
++(((
++lsof -i
++)))
++)))
++
++qui permet d'afficher les connections actuelles. Il devrait y avoir à minima quelque chose du genre
++
++(% class="box" %)
++(((
++postgres  220900 postgres    5u  IPv4 4457404      0t0  TCP *:postgresql (LISTEN)
++postgres  220900 postgres    6u  IPv6 4457405      0t0  TCP *:postgresql (LISTEN)
++
++postgres  220901 postgres    5u  IPv4 4457515      0t0  TCP *:5433 (LISTEN)
++postgres  220901 postgres    6u  IPv6 4457516      0t0  TCP *:5433 (LISTEN)
++)))
++
++et également les machines et VM connectés, par exemple
++
++(% class="box" %)
++(((
++postgres  414816 postgres    9u  IPv4 7792005      0t0  TCP pgsql-prod.prod.infra.atilla.org->gitlab-prod.prod.infra.atilla.org (ESTABLISHED)
++)))
++
++{{success}}
++Il ne reste plus qu'a vérifier si les services ayant leur BDDs sur pgsql-prod sont repartis normalement.
++{{/success}}
++
++{{info}}
++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.
++{{/info}}
++
++(% class="wikigeneratedid" %)