Version imprimable
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
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
Arrêt de la base de la nouvelle version de postgresqlCitation:
pg_lsclusters
Arrêt de postgresqlCitation:
pg_dropcluster nv_nb_version main --stop
Mise à jourCitation:
systemctl stop postgresql
Relancer postgresqlCitation:
pg_upgradecluster -m upgrade an_nb_version main
Lister les bases en cours de fonctionnementCitation:
systemctl start postgresql
Citation:
pg_lsclusters
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
en effet :oops:Citation:
Envoyé par Jon Shannow
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.Citation:
Envoyé par Jon Shannow
OK,
Merci pour ces explications,
Je m'y colle demain.
JS
Bonjour,
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.Citation:
Envoyé par Jon Shannow
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
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
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 :P).
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
Merci de toutes ces explications.
JS
Heu, j'ai un souci.Citation:
Envoyé par gabriel21
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. :oops:
JS
Effectivement...
Ces commandes ne sont disponibles que sous Linux, et encore pour les distributions basées sur Debian.
ced
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
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
Merci pour ce lien