Re: vacuum full et hot standby WAL stream: FATAL

Guillaume Lelarge <[email protected]>
Newsgroups gmane.comp.db.postgresql.french
Message-ID <CAECtzeV-oLhYb=ZajLUE-b0MqW1_6sTnDUxp5BpeXCgU3uhpxA@mail.gmail.com>
Le 27 mai 2016 6:04 PM, "Daniel Verite" <[email protected]> a écrit :
>
>   CRUMEYROLLE Pierre wrote:
>
> > La deuxième particularité concerne le côté synchrone ou non de la
> > réplication. Une réplication synchrone fonctionne de la façon suivante
> > : une transaction n'est pas considérée validée (pas de COMMIT) tant
> > que tous les serveurs n'ont pas validé cette transaction. Il y a
> > plusieurs intérêts à ça :
> >
> > il n'y a pas de risque de perte de données au moment d'une
> > bascule du maître ;
> > le résultat d'une requête est cohérent quelque soit le serveur
> > interrogé dans le cadre d'un cluster en répartition de charge.
>
> Sur le dernier point, non il n'y pas de cohérence systématique,
> c'est d'ailleurs une nouveauté de la 9.6 actuellement en beta:
> synchronous_commit = 'remote_apply'
>
> Voir (en anglais):
> https://www.postgresql.org/docs/9.6/static/runtime-config-wal.html
>
> ainsi que:
>
http://michael.otacoo.com/postgresql-2/postgres-9-6-feature-highlight-remote-apply/
>

Ce n'est malheureusement pas la seule erreur dans cet article. Dans le cas
d'une réplication synchrone, même si on a configuré plusieurs serveurs
synchrones, le maître n'attend que la réponse du premier (et non pas de
tous comme je le dis dans l'article).
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.