Vous n'êtes pas identifié(e).
Pages : 1
Merci pour votre éclairage sur mes questions. Je reviendrai sur ce topic si d'autres se posent lors de la mise en place, afin de ne pas perdre le contexte.
Tout d'abord, merci pour votre réponse.
Ensuite, le passage du maître en streaming replication asynchrone peut-il être scripté de façon à ce que toutes les connexions au maître deviennent asynchrone si l'esclave devient injoignable (ie ne répond plus au ping)?
Enfin, vous semblez dire que ce blocage n'intervient que si le seul esclave devient indisponible; cela signifie-t-il que, s'il y a plusieurs esclaves, tous doivent être indisponibles pour bloquer les modifications sur le maître?
Merci d'avance pour vos réponses.
Bonjour.
J'étudie actuellement le passage de notre serveur PgSQL 8.4 à un groupe de 2 serveurs PgSQL9.1 dont un maître et un esclave. La réplication des données se ferait en warm standby avec streaming replication synchrone (notre site étant un site d'annonces, la grande majorité de nos requêtes sont en lecture, et celles en écriture sont surtout effectuées par lot sans que l'utilisateur ne les attende; seules quelques annonces sont ponctuellement éditées manuellement par l'utilisateur, lequel ne devrait donc pas être impacté par l'attente de la réplication). Néanmoins, je me pose des questions auxquelles je n'ai pas pu trouver de réponse claire :
Que se passe-t-il en cas de perte de l'esclave? Le maître continue-t-il à stocker les transactions dans son journal en attendant que l'esclave se reconnecte pour lui transmettre le delta?
Si oui, lorsque l'esclave sera à nouveau opérationnel, doit-on remettre en contact les 2 serveurs ou rétablissent-il leur connexion et la base de l'esclave automatiquement?
Dans le premier cas, comment les remettre en contact?
Par ailleurs, si vous voyez une contre-indication ou des points à vérifier lors d'une telle mise à jour, pourriez-vous m'en faire part?
Merci d'avance.
Pages : 1
