Re: vacuum full et hot standby WAL stream: FATAL
Michael Paquier <[email protected]>
| Newsgroups | gmane.comp.db.postgresql.french |
|---|---|
| Message-ID | <CAB7nPqQSS7mD2HPvk+EsVQ2rjLiXXvcqZ2D1PToRcoxb4xO7Sw@mail.gmail.com> |
2016-05-28 2:20 GMT+09:00 Guillaume Lelarge <[email protected]>: > Le 27 mai 2016 6:04 PM, "Daniel Verite" <[email protected]> a écrit : >> 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). Avec synchrounous_standby_names = 'N (standby1, standby2 ... standbyM)', il me semblait que l'on attendait le message de confirmation des N premiers esclaves listés ici. Sinon quel est l'intérêt de pouvoir en utiliser plusieurs? On doit être sûr que le WAL de la transaction est présente dans ces N esclaves selon synchronous_commit bien sûr. Y a-t-il des erreurs dans des formulations de cet article? -- Michael -- Envoi via la liste pgsql-fr-generale ([email protected])