Re: How to Qualifying or quantify risk of loss in asynchronous replication

On Wed, Mar 16, 2016 at 11:51 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:

>
> I thought it was already clear:

Perhaps "Clarity is in the eye of the beholder". If you are very familiar
with the internals and operation of the software, the documentation is
clear. It's like hindsight; it's always "20/20".

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

That refers to *log shipping* not streaming.

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

Asynchronous to what? The next sentence indicates the delay is relevant to
*becoming visible in the standby*. Thus, a message could be received by the
standby, but before it is logged to disk, both it and the primary fail.
Meanwhile, the client thinks its transaction was committed, but in fact, it
was committed to only one side. Thus, it does NOT necessarily imply that
"asynchronous" means with respect to the client receiving "transaction
complete" acknowledgement.

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

Again, an asynchronous mode *could mean* that the WALs are sent before the
commit was acknowledge, and that would be consistent with the above
statements.