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).