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 histoire.
Les commandes listées ci dessous seront celles de la version que j'ai installée.
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_<name>_backup.sql
su - postgres -c "pg_dumpall --globals-only -U postgres -p <port>" > /var/backups/pgsql_<name>_globals_backup.sql
scp -J root@atilla.org pgsql-prod.prod.infra:/var/backups/pgsql_main_backup.sql ./pgsql/
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 vous n'avez jamais touché à postgreSQL, la commande pour sortir du terminal est \q
Ici, 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 un cluster spécifique d'une version pgsql donnée : pg_ctlcluster <version> <cluster_name> stop (ou de démarrer avec start)
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) : kill -9 <PID>
Une fois les processus stoppés, 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érifiez une nouvelle fois que des tâches n'ont pas été redémarrées comme expliqué dans la précédente section.
Assurez-vous qu'il y ait suffisamment de place sur la VM, toujours avec df -h, les nouveaux clusters de la version 14 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é dans /etc/postgresql/<old_version>/<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/<new_version>/<cluster_name>/pg_hba.conf.
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.
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 d'ailleurs que la commande rm -rf '/var/lib/postgresql/<version>/<cluster_name>'.
Ouvrez ensuite le fichier /etc/postgresql/<new_version>/<cluster_name>/postgresql.conf de la nouvelle version. Il faut configurer les ports des clusters, et autoriser les connexions.
Dans ce cas, le cluster main est au 5432 et le gitlab au 5433, donc dans /etc/postgresql/<new_version>/gitlab/postgresql.conf je cherche et modifie 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 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.
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 généré par pg_upgrade 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 :
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. Cette commande permet d'afficher les connexions actuelles. Il devrait y avoir parmi les résultats quelque chose du genre :
postgres 220900 postgres 5u IPv4 4457404 0t0 TCP *:postgresql (LISTEN) # pour le port par défaut (5432) de postgres
postgres 220900 postgres 6u IPv6 4457405 0t0 TCP *:postgresql (LISTEN)
postgres 220901 postgres 5u IPv4 4457515 0t0 TCP *:5433 (LISTEN) # pour le cluster gitlab au 5433
postgres 220901 postgres 6u IPv6 4457516 0t0 TCP *:5433 (LISTEN)
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