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

From: otheus uibk <otheus(dot)uibk(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: How to Qualifying or quantify risk of loss in asynchronous replication
Date: 2016-03-16 08:59:59
Message-ID: CALbQNd22RHWu39ZQBd9rdNy=Cdm+40qM9Jkg2nPaCvVso=XDzw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thomas, thanks for your input... But I'm not quite getting the answer I
need....

> But what precisely is the algorithm and timing involved with streaming
> WALs?
> >
> > Is it:
> > * client issues COMMIT
> > * master receives commit
> > * master processes transaction internally
> > * master creates WAL record
> > | master appends WAL to local WAL file, flushes disk
> > | master sends WAL record to all streaming clients
> > * master sends OK to client
> > * master applies WAL
> >
> > So is this correct? Is it correct to say: PG async guarantees that the
> WAL
> > is *sent* to the receivers, but not that they are received, before the
> > client receives acknowledgement?
>
> Async replication doesn't guarantee anything at all about receivers,
> or even that there is one right at this moment. Did you mean to write
> "synchronous" instead of "asynchronous"?

I'm only concerned with async (for this thread).

In asynchronous replication,
> the primary writes to the WAL and flushes the disk. Then, for any
> standbys that happen to be connected, a WAL sender process trundles
> along behind feeding new WAL doesn the socket as soon as it can, but
> it can be running arbitrarily far behind or not running at all (the
> network could be down or saturated, the standby could be temporarily
> down or up but not reading the stream fast enough, etc etc).

This is the *process* I want more detail about. The question is the same as
above:
> (is it true that) PG async guarantees that the WAL
> is *sent* to the receivers, but not that they are received, before the
> client receives acknowledgement?

But I will refine what I mean by "sent"... does PostgreSQL write the WAL to
the socket and flush the socket before acknowledging the transaction to
the client? Does it *always* do this? Or does it make a best effort? Or
does the write to the socket and return to client happen asynchronously?

I realize that the data might not be *seen* at the client, i realize
network buffers may take time to reach the network, I realize various
levels of synchronous replication provide higher guarantees. But For the
purposes of this topic, I'm interest to know what PG actually does. I can't
tell that from the documentation (because it is not clearly stated and
because it is self contradictory).

--
Otheus
otheus(dot)uibk(at)gmail(dot)com
otheus(dot)shelling(at)uibk(dot)ac(dot)at

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message otheus uibk 2016-03-16 09:21:41 Re: How to Qualifying or quantify risk of loss in asynchronous replication
Previous Message CHENG Yuk-Pong, Daniel 2016-03-16 08:53:36 UPSERT and HOT-update