Vous n'êtes pas identifié(e).
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.
Hors ligne
Bonjour.
Premièrement, petit détail: le swarm standby implique que vous ne pouvez pas vous connecter à votre serveur esclave. Si vous voulez pouvoir faire des requêtes en lecture seule sur l'esclave il faut le configurer en hot standby.
Avec une réplication synchrone, s'il n'y a qu'un seul esclave et que celui-ci ne répond plus, plus aucune écriture ne pourra se faire sur le maître, car il attendra sans fin la validation de l'esclave.
Vous pouvez cependant modifier le comportement de la réplication soit dans la transaction avec un SET LOCAL synchronous_commit TO off pour ne plus répliquer les données lors de cette transaction ou le modifier dans le postgresql.conf du serveur maître en attendant le rétablissement de l'esclave. Vous pouvez également modifier le synchonous_standby_names pour cela.
La réplication avec postgresql 9.1 se fait normalement de 2 façons :
- les WAL, lorsqu'un delta à récupérer est important. Cela suppose que vous archiviez les wal et que ceux-ci sont récupérables par votre serveur esclave
- La streaming replication, une fois que le dernier WAL a été récupéré, les blocs modifiés sont envoyés au fur et à mesure pour ne pas attendre un fichier WAL entier.
Donc lors de la reprise de l'esclave, il commencera par récupérer tous les wals manquant, puis utilisera la streaming replication pour revenir à un delta nul, vous pourrez ensuite rebasculer en réplication synchrone.
Julien.
https://rjuju.github.io/
Hors ligne
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.
Hors ligne
SI vous avez un script qui détecte que l'esclave ne répond plus au ping, vous pouvez par exemple lui dire de remplacer un postgresql.conf par un de secours (qui ne fait plus de réplication synchrone) et ensuite faire un pg_ctl reload pour prendre en compte la modification.
Effectivement, le blocage n'intervient que si aucun serveur esclave synchrone ne répond, donc tant qu'il en reste au moins un il n'y a pas de blocage.
Julien.
https://rjuju.github.io/
Hors ligne
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.
Hors ligne
