Mettre à jour pgsql sur pgsql-prod
Après avoir galéré sur la mise à jour de postgreSQL sur pgsql-prod, 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
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 pg_dumpall. Il va falloir faire deux sauvegarde, une avec le flag --globals-only pour récupérer les users/roles/etc, et une autre pour récupérer les BDDs.
Pour voir les différents clusters présents, utilisez la commande pg_lsclusters. La sortie inclura plusieurs information importantes, comme la version pgsql utilisé par chaque cluster, et son port.
Pour vérifier qu'il y a de la place sur la VM on peut utiliser df -h et regarder la place sur ce qui est monté sur / , le dump des BDD du cluster main faisait 1.3G dans mon cas.
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 <port>" > /var/backups/pgsql_main_globals_backup.sql
scp -J root@atilla.org pgsql-prod.prod.infra:/var/backups/pgsql_main_backup.sql ./pgsql/
Pour vérifier les packages installés, utiliser la commande
dpkg -l | grep postgresql
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.
sudo -u postgres psql -p <port>
\l
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
pg_createcluster --locale=C --encoding=UTF8 14 main
On va utiliser la commande pg_upgrade pour migrer les données, il va falloir utiliser pas mal de flags avec des arguments, n'oubliez pas de lire la doc.
Afin de pouvoir lancer la commande, il va falloir stopper postgreSQL :
systemctl stop postgresql
vous pouvez vous assurer avec la commande suivante que tout est bien à l'arrêt, sinon pg_upgrade retournera des erreurs :
ps -ef | grep postgres
La seule tâche qui devrait apparaître est celle lancé par root, par exemple :
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 start) un cluster spécifique d'une version pgsql donnée :
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)
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.
Avant de lancer la commande, on notera l'existence du flag --check, dont on ne manquera pas de se servir.
Pour la version 13 à 14, il faut donc taper pour lancer les vérifications
/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
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.
Vérifier une nouvelle fois que des tâches n'ont pas été redémarré comme expliqué dans [label>Space.Page#HPréparationdesnouveauxclusters] ici
Assurez vous qu'il y a suffisamment de place sur la VM, dans mon cas les nouveaux clusters ont pris 5G.
/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.
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 pg_hba.conf de l'ancienne version, situé pour moi dans /etc/postgresql/13/<cluster_name>/. À la fin du fichier, copiez la partie sur le login pour les BDDs, dont le début est indiqué par la ligne
# Database administrative login by Unix domain socket
Collez ces informations au même endroit dans le fichier de la nouvelle version, /etc/postgresql/14/main/pg_hba.conf.
Ouvrez ensuite le fichier /etc/postgresql/14/main/postgresql.conf 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 delete_old_cluster.sh qui ont été générés par pg_upgrade. Ils ne contiennent que la commande rm -rf '/var/lib/postgresql/<version>/<cluster_name>'.
Dans mon cas, le cluster main est au 5432 et le gitlab au 5433, donc dans /etc/postgresql/14/gitlab/postgresql.conf cherchez et modifiez la ligne :
port = 5433
il faut également autoriser les connexions, cherchez et modifiez la ligne :
listen_addresses = '*'
Mises à jour et optimisations
Un fichier update_extensions.sql a été généré par chaque commande pg_upgrade 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 :
sudo -u postgres psql -p <port>
De là, on peut afficher les différente BDDs avec \l et se connecter à chaque BDD pour les réindexer. Exemple avec la BDD postgres :
\c postgres
REINDEX DATABASE postgres;
Si pour ce cluster le fichier update_extensions.sql indiquait une mise à jour d'extension, on peut en même temps copier coller la commande qui pourrait par exemple être :
ALTER EXTENSION "pg_trgm" UPDATE;
Redémarrer postgreSQL
Une fois tout cela fait, il ne reste plus qu'à redémarrer postgreSQL :
systemctl start postgresql
On peut ensuite vérifier avec la commande pg_lsclusters que les deux nouveaux clusters sont opérationnels.
Une commande utile pour le débogage est
lsof -i
qui permet d'afficher les connections actuelles. Il devrait y avoir à minima quelque chose du genre
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
postgres 414816 postgres 9u IPv4 7792005 0t0 TCP pgsql-prod.prod.infra.atilla.org->gitlab-prod.prod.infra.atilla.org (ESTABLISHED)