Vous n'êtes pas identifié(e).
Bonjour,
J'ai lu une documentation provenant de DALIBO ("Les nouveautés de PostgreSQL 9.3") qui évoque le changement de MASTER dans une configuration avec plusieurs secours pointant sur le même master. (Je ne parle pas du cas d'un "cascading" de serveurs de secours).
Le mode de réplication n'étant pas précisé, j'en ai déduit qu'on parlait de log shipping et/ou de réplication par flux.
A l'époque de ce document, la version PostgreSQL était encore en version 9.3 beta 1.
En effet, voici l'exemple cité dans ce document :
Avant 9.3 : Un clone ne peut pas changer de source
Avec 9.3
• P1 réplique vers R1, R2 et R3.
• P1 est arrêté pour maintenance
• R1 devient le serveur principal
• R2 et R3 se “raccrochent” à R1
Est ce que ceci est possible avec la 9.3 actuelle ou est ce que c'était une amélioration de la réplication qui était prévue pour la 9.3 à l'origine et qui a été repoussé pour une version future?
Si cela est possible, est ce automatique (avec une configuration du recovery.conf) ou faut il raccrocher les autres secours au nouveau maitre à la main?
Toujours, dans le cas où c'est possible, existe il une documentation sur la mise en œuvre d'une telle configuration (plus précisément le rattachement des secours restant sur le nouveau maître) ?
En effet, j'ai parcouru le chapitre "Haute disponibilité" dans la documentation officielle 9.3.4 mais je n'ai rien trouvé sur ce sujet. (A part le paramètre recovery_target_timeline = 'latest' dans le cas d'un cascading de serveurs).
Merci d'avance pour les réponses que vous pourrez m'apporter.
Cordialement
Dernière modification par Kore (25/03/2014 16:27:57)
Hors ligne
Bonjour,
je pense qu'il s'agit de l'amélioration faisant que le changement de timeline peut maintenant (depuis la 9.3) se faire avec uniquement le protocole de streaming replication. http://www.postgresql.org/docs/9.3/stat … e-9-3.html :
Allow a streaming replication standby to follow a timeline switch (Heikki Linnakangas)
This allows streaming standby servers to receive WAL data from a slave newly promoted to master status. Previously, other standbys would require a resync to begin following the new master.
Julien.
https://rjuju.github.io/
Hors ligne
Merci pour votre réponse.
En effet, c'était bien de cette amélioration que je parlais.
Je viens de tester.
J'avais oublié de changer le numéro de port d'écoute dans le recovery.conf de mon second standby dans primary_conninfo lors de mes tests de failover.
Cette amélioration très intéressante est bien présente en 9.3.
Pour l'info : il a juste suffit de positionner recovery_target_timeline = 'latest' et de reconfigurer le primary_conninfo pour le faire pointer vers le nouveau maitre sur le secours restant.
Merci pour votre réactivité!
Hors ligne
