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

Поиск
Список
Период
Сортировка
От otheus uibk
Тема Re: How to Qualifying or quantify risk of loss in asynchronous replication
Дата
Msg-id CALbQNd22RHWu39ZQBd9rdNy=Cdm+40qM9Jkg2nPaCvVso=XDzw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: How to Qualifying or quantify risk of loss in asynchronous replication  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: How to Qualifying or quantify risk of loss in asynchronous replication  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список 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).



 


--

В списке pgsql-general по дате отправления:

Предыдущее
От:
Дата:
Сообщение: Re: MongoDB 3.2 beating Postgres 9.5.1?
Следующее
От: otheus uibk
Дата:
Сообщение: Re: How to Qualifying or quantify risk of loss in asynchronous replication