Discussion :

[Jon Shannow]

Et bientôt la version 13 ?

Bonjour à toutes et tous,

tout est dans le titre.

J'aimerais upgrader mon serveur Postgres de la version 11 vers la version 12 sans que ça perturbe les accès aux bases de données.

Comment est-ce que l'on fait ça ?

Merci d'avance

JS

[gabriel21]

Voila la méthode que j'utilise depuis un certains nombre d'années et sans problème.
Elle demande l'arrêt des bases pendant la mise à jour. La durée de l'arrêt dépend de la taille des bases.
Bien entendu, je fais toujours une sauvegarde avant. Cela ne couvre pas l'installation. La variable nv_nb_version correspond à la version de la nouvelle installation.
Lister les bases en cours de fonctionnement

pg_lsclusters

Arrêt de la base de la nouvelle version de postgresql

pg_dropcluster nv_nb_version main --stop

Arrêt de postgresql

systemctl stop postgresql

Mise à jour

pg_upgradecluster -m upgrade an_nb_version main

Relancer postgresql

systemctl start postgresql

Lister les bases en cours de fonctionnement

pg_lsclusters

[Jon Shannow]

Merci de ta réponse,

Je suppose que "an_nb_version" représente l'ancienne version ...

Une question subsidiaire, lors de l'installation de la nouvelle version, quel port indiquer ? Le même que pour la version précédente ? Et l'ancienne version doit être désinstallée une fois l'upgrade effectué ?

Encore merci

JS

[gabriel21]

Je suppose que "an_nb_version" représente l'ancienne version ...

en effet

Une question subsidiaire, lors de l'installation de la nouvelle version, quel port indiquer ? Le même que pour la version précédente ? Et l'ancienne version doit être désinstallée une fois l'upgrade effectué ?

Personnellement, je ne personnalise pas le port, toute mes bases sont dans la base main. Par défaut, quand apt (mes serveurs sont sous Debian ou Ubuntu) installe la nouvelle version, il cré une nouvelle base et lui attribut un nouveau port. D'où sa suppression en début. pg_dropcluster supprime la base. L'option stop lui ordonne de l'arrêter avant. Du coup quand tu migres la base, elle garde sa configuration au niveau des ports. La désinstallation n'est pas en soit obligatoire. Tu peux avoir plusieurs versions de PostgreSQL en fonctionnement. Seul la base doit être de l'un ou l'autre.

[Jon Shannow]

OK,
Merci pour ces explications,
Je m'y colle demain.
JS

[ced]

Bonjour,

J'aimerais upgrader mon serveur Postgres de la version 11 vers la version 12 sans que ça perturbe les accès aux bases de données.

La solution qui vous a été proposée est basée sur pg_upgrade, qui diminue le temps d'indisponibilité par rapport à la méthode classique s'appuyant sur une sauvegarde de l'ancienne version et restauration sur la nouvelle version.
Mais le temps d'indisponibilité n'est pas nul et dépend pour beaucoup de la volumétrie de l'instance que vous migrez. En effet, les deux versions doivent être coupées pendant la migration des fichiers de données.

Si vous voulez diminuer drastiquement le temps d'indisponibilité, comme vous voulez passer de la v11 à la v12, vous pouvez utiliser le mécanisme de réplication logique apparu avec la v10.
Pour ça, vous installez la v12, vous répliquez les bases de la v11 vers la v12 (pendant ce temps, vous pouvez continuer de travailler normalement sur la v11, à la fois en lecture et en écriture), et vous coupez les accès juste le temps de faire la bascule entre v11 et v12.

Ça nécessite quelques opérations supplémentaires d'administration, mais ça fonctionne très bien.

ced

[Jon Shannow]

Merci de cette seconde solution.

Pour le moment, je dirais que couper le service ne me gène pas. Mais à l'avenir, cela pourrait être très intéressant.

Comment fait-on une réplication logique ?

JS

[ced]

Il faut au préalable prendre quelques précautions. Par exemple, toutes les tables doivent avoir une clé primaire (mais c'est, bien sûr, toujours le cas ).
Ensuite, il faut modifier le paramètre WAL_LEVEL du serveur à répliquer, pour le passer à la valeur logical, si ce n'est pas déjà le cas (et redémarrer l'instance pour prendre en compte le changement).

Ensuite, on recopie la structure de la (ou des) base(s) à répliquer (avec l'option -s de pg_dump pour ne sauvegarder que la structure, sauvegarde qu'on restaure sur le serveur secondaire).
Après, la réplication logique fonctionne sur un système de publication côté serveur principale et abonnement sur le serveur secondaire. Tout est bien décrit dans la documentation de PostgreSQL et c'est un mécanisme simple à mettre en œuvre.

ced

[Jon Shannow]

Merci de toutes ces explications.

JS

[Jon Shannow]

Voila la méthode que j'utilise depuis un certains nombre d'années et sans problème...

Heu, j'ai un souci.

Je ne trouve pas les commandes pg_lsclusters, pg_dropcluster, systemctl et pg_upgradecluster.

J'aurais peut-être du préciser que le serveur est sous Windows.

JS

[ced]

Effectivement...
Ces commandes ne sont disponibles que sous Linux, et encore pour les distributions basées sur Debian.

ced

[Jon Shannow]

Merci à vous deux.

Je vais regarder la réplication logique pour voir.

Sinon, sous Windows il y a pg_upgrade. Je vais regarder tout ça.

Encore merci

JS

[ced]

Il y a une procédure pour pg_upgrade sous Windows décrite dans ce billet blog : https://www.arencambre.com/2014/12/2...-misses-a-lot/
Pas testé (Postgres, c'est mieux sous Linux ), mais la commande ressemble à celle lancée sous Linux (il manque peut-être les options -p et -P pour indiquer les ports de l'ancienne et de la nouvelle instance).

ced

[Jon Shannow]

Merci pour ce lien