Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Est-ce qu'il y a un lien pour faire un download de postgresql 12.7 dans redhat 7 ainsi que le guide.
Merci pour votre reponse
Maryse
Hors ligne
Bonjour,
Pour le guide :
https://docs.postgresql.fr/
https://www.postgresql.fr/
pour l'installation redhat :
https://www.postgresql.org/download/linux/redhat/
Cordialement,
Sébastien.
Hors ligne
Bonjour,
J'aimerai bien rebondir sur ce sujet pour demander est ce qu'il y a un retour d'expérience pour une réplication PostgreSQL en streaming entre deux serveurs en RedHat l'un en version 7.1 et Noyau 3.10.0-514 et l'autre en 7.4 et Noyau 3.10.0-693.
Par avance merci
Hors ligne
Ça peut marcher comme ça peut corrompre silencieusement le serveur secondaire (au moins en cas de changement de glibc). Si vous savez ce que vous faites, pourquoi pas, sinon c'est une très mauvaise idée.
Julien.
https://rjuju.github.io/
Hors ligne
Merci Julien pour ta réponse et ta disponibilité.
L'idée est de faire une migration Matériel en douceur.
* Les deux serveurs actuels en streaming réplication doivent être remplacés.
* On compte brancher un NOUVEAU troisième puis un quatrième "Standby".
* Débrancher les anciens UN par UN après un FailOver sur un des des nouveaux.
==> Une idée pour limiter le temps d'indisponibilité applicatif.
Je vais poser la question autrement. Faut il prendre des mesures particulières (pendant cette période; deux trois jours) permettant de réussir au maximum cette opération.
S'il y a un retour d'expérience je suis preneur (par avance merci) et surtout si l'opération est trop risquée c.à.d. une chance sur deux de tout casser me le dire. La base est volumineuse puis une restauration en PITR pourra prendre 5h application arrêtée.
En attente de vous lire, merci
Hors ligne
La seule précaution à prendre est de s'assurer une compatibilité matérielle (postgres vous préciendra si ce n'était pas le cas), et logicielle (même OS, même version etc notamment pour la glibc). En cas de non compatibilité des librairies sous jacentes, le temps de transition ne changera rien, les données pourront être immédiatement et constamment corrompues. Si vous n'utilisez pas les nouveaux serveurs en lecture seule, vous pouvez vous content d'un REINDEX global sur chacune des bases avant d'autoriser les connexions suite à la bascule sur les nouveaux serveurs.
Julien.
https://rjuju.github.io/
Hors ligne
Merci Julien
* Pour la compatibilité logicielle, j'ai compris en revanche pour éviter une éventuelle confusion, qu'est ce que tu entends dire par "compatibilité matérielle" (entre anciens et nouveaux serveurs?)
* il faut bien la même version glibc et librairies sur l'ensemble des serveurs? (ancien et nouveaux)?
Par avance merci
Hors ligne
Pour la compatibilité matérielle, c'est par exemple 32bits/64 bits, big endian / little endian etc.
Pour la partie logicielle, glibc est critique oui, tout comme libicu si vous l'utilisez. Pour le reste, je ne crois pas qu'il y ait beaucoup de dépendances, du moment que vous avez un noyau linux suffisamment récent pour gérer les problèmes IO remontés par postgres il y a quelques années.
Julien.
https://rjuju.github.io/
Hors ligne
La vérification de compatibilité glibc est justifiée par l'utilisation des locales dans les index, comme expliqué notamment ici:
https://wiki.postgresql.org/wiki/Locale_data_changes
Mais RH 7.4 est une version de maintenance de RH 7.1 et il ne doit pas y avoir de problème car toute la lignée RH7.x doit utiliser la même version de glibc (la 2.17 en l'occurrence d'après distrowatch):
https://distrowatch.com/table.php?distribution=redhat
Ce qui serait à proscrire, c'est un serveur secondaire en RH8 avec un primaire en RH7.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Merci beacoups à vous pour ces informations précieuses.
Hors ligne
Pages : 1
