Re: How to Qualifying or quantify risk of loss in asynchronous replication
От | Adrian Klaver |
---|---|
Тема | Re: How to Qualifying or quantify risk of loss in asynchronous replication |
Дата | |
Msg-id | 56E9E361.1030409@aklaver.com обсуждение исходный текст |
Ответ на | Re: How to Qualifying or quantify risk of loss in asynchronous replication (otheus uibk <otheus.uibk@gmail.com>) |
Ответы |
Re: How to Qualifying or quantify risk of loss in
asynchronous replication
|
Список | pgsql-general |
On 03/16/2016 02:40 PM, otheus uibk wrote: > On Wednesday, March 16, 2016, Thomas Munro > > Somehow, the documentation misleads (me) to believe the async > replication algorithm at least guarantees WAL records are *sent* before > responding "committed" to the client. I now know this is not the case. > *grumble*. > > How can I help make the documentation clearer on this point? I thought it was already clear: http://www.postgresql.org/docs/9.4/interactive/warm-standby.html "It should be noted that log shipping is asynchronous, i.e., the WAL records are shipped after transaction commit. As a result, there is a window for data loss should the primary server suffer a catastrophic failure; transactions not yet shipped will be lost. ..." http://www.postgresql.org/docs/9.4/interactive/warm-standby.html#STREAMING-REPLICATION "Streaming replication is asynchronous by default (see Section 25.2.8), in which case there is a small delay between committing a transaction in the primary and the changes becoming visible in the standby. This delay is however much smaller than with file-based log shipping, typically under one second assuming the standby is powerful enough to keep up with the load. ..." http://www.postgresql.org/docs/9.4/interactive/warm-standby.html#SYNCHRONOUS-REPLICATION "PostgreSQL streaming replication is asynchronous by default. If the primary server crashes then some transactions that were committed may not have been replicated to the standby server, causing data loss. The amount of data loss is proportional to the replication delay at the time of failover. Synchronous replication offers the ability to confirm that all changes made by a transaction have been transferred to one synchronous standby server. This extends the standard level of durability offered by a transaction commit. This level of protection is referred to as 2-safe replication in computer science theory. " > > -- > Otheus > otheus.uibk@gmail.com <mailto:otheus.uibk@gmail.com> > otheus.shelling@uibk.ac.at <mailto:otheus.shelling@uibk.ac.at> > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: