Thread: Why PostgreSQL doesn't implement a semi sync replication?

Why PostgreSQL doesn't implement a semi sync replication?

From
余森彬
Date:
Hi all:

    As we know, the synchronous commit process is blocked while 
receives from acknowledgement from standby in

PostgreSQL.This is good for data consistence in master and standby, and 
application can get important data from standby.But

when the standby crash or network goes wrong, the master could be 
hang.Is there a feature plan for a semi sync like MySQL

InnoDB(set a timer, and become asynchronous when timeout)?




Re: Why PostgreSQL doesn't implement a semi sync replication?

From
Francisco Olarte
Date:
On Fri, Nov 11, 2016 at 4:40 AM, 余森彬 <justdoit920823@gmail.com> wrote:
>     As we know, the synchronous commit process is blocked while receives
> from acknowledgement from standby in
> PostgreSQL.This is good for data consistence in master and standby, and
> application can get important data from standby.But
> when the standby crash or network goes wrong, the master could be hang.Is
> there a feature plan for a semi sync like MySQL
> InnoDB(set a timer, and become asynchronous when timeout)?

JMO, but it seems this basically means any process should be dessigned
to cope with the posibility of not having replicated data after
commit, so, why bother with synchronous replication in the first
place?

Francisco Olarte.



Re: Why PostgreSQL doesn't implement a semi sync replication?

From
Petr Jelinek
Date:
On 11/11/16 16:03, Francisco Olarte wrote:
> On Fri, Nov 11, 2016 at 4:40 AM, 余森彬 <justdoit920823@gmail.com> wrote:
>>     As we know, the synchronous commit process is blocked while receives
>> from acknowledgement from standby in
>> PostgreSQL.This is good for data consistence in master and standby, and
>> application can get important data from standby.But
>> when the standby crash or network goes wrong, the master could be hang.Is
>> there a feature plan for a semi sync like MySQL
>> InnoDB(set a timer, and become asynchronous when timeout)?
> 
> JMO, but it seems this basically means any process should be dessigned
> to cope with the posibility of not having replicated data after
> commit, so, why bother with synchronous replication in the first
> place?

It's often more acceptable to say "we lose data when 2 servers die (or
are in problems)" than "we lose data when 1 server dies" and it's also
more acceptable to say "we stop answering when we lose 2 servers" but
not "we stop answering when we lose 1 server", and semisync replication
works for combination of these two.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



Re: Why PostgreSQL doesn't implement a semi sync replication?

From
Craig Ringer
Date:
On 12 November 2016 at 02:12, Petr Jelinek <petr@2ndquadrant.com> wrote:
> On 11/11/16 16:03, Francisco Olarte wrote:
>> On Fri, Nov 11, 2016 at 4:40 AM, 余森彬 <justdoit920823@gmail.com> wrote:
>>>     As we know, the synchronous commit process is blocked while receives
>>> from acknowledgement from standby in
>>> PostgreSQL.This is good for data consistence in master and standby, and
>>> application can get important data from standby.But
>>> when the standby crash or network goes wrong, the master could be hang.Is
>>> there a feature plan for a semi sync like MySQL
>>> InnoDB(set a timer, and become asynchronous when timeout)?
>>
>> JMO, but it seems this basically means any process should be dessigned
>> to cope with the posibility of not having replicated data after
>> commit, so, why bother with synchronous replication in the first
>> place?
>
> It's often more acceptable to say "we lose data when 2 servers die (or
> are in problems)" than "we lose data when 1 server dies" and it's also
> more acceptable to say "we stop answering when we lose 2 servers" but
> not "we stop answering when we lose 1 server", and semisync replication
> works for combination of these two.

Yep. Also, monitoring. sync with a short timeout means you can usually
rely on sync rep, and if it times out and falls back to async your
monitoring system can start screaming at you.

I think k= replication will help quite a bit with this though.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



Re: Why PostgreSQL doesn't implement a semi sync replication?

From
余森彬
Date:
<p><br /><br /><div class="moz-cite-prefix">在 2016/11/12 上午11:27, Craig Ringer 写道:<br /></div><blockquote
cite="mid:CAMsr+YFw1L8bSMz62yNGc-qk9=KVq27HEEw-=69hD9bP9ZCZgw@mail.gmail.com"type="cite"><pre wrap="">On 12 November
2016at 02:12, Petr Jelinek <a class="moz-txt-link-rfc2396E"
href="mailto:petr@2ndquadrant.com"><petr@2ndquadrant.com></a>wrote:
 
</pre><blockquote type="cite"><pre wrap="">On 11/11/16 16:03, Francisco Olarte wrote:
</pre><blockquote type="cite"><pre wrap="">On Fri, Nov 11, 2016 at 4:40 AM, 余森彬 <a class="moz-txt-link-rfc2396E"
href="mailto:justdoit920823@gmail.com"><justdoit920823@gmail.com></a>wrote:
 
</pre><blockquote type="cite"><pre wrap="">    As we know, the synchronous commit process is blocked while receives
from acknowledgement from standby in
PostgreSQL.This is good for data consistence in master and standby, and
application can get important data from standby.But
when the standby crash or network goes wrong, the master could be hang.Is
there a feature plan for a semi sync like MySQL
InnoDB(set a timer, and become asynchronous when timeout)?
</pre></blockquote><pre wrap="">
JMO, but it seems this basically means any process should be dessigned
to cope with the posibility of not having replicated data after
commit, so, why bother with synchronous replication in the first
place?
</pre></blockquote><pre wrap="">
It's often more acceptable to say "we lose data when 2 servers die (or
are in problems)" than "we lose data when 1 server dies" and it's also
more acceptable to say "we stop answering when we lose 2 servers" but
not "we stop answering when we lose 1 server", and semisync replication
works for combination of these two.
</pre></blockquote><pre wrap="">
Yep. Also, monitoring. sync with a short timeout means you can usually
rely on sync rep, and if it times out and falls back to async your
monitoring system can start screaming at you.

I think k= replication will help quite a bit with this though.

</pre></blockquote><br /> In my opinion, the semantic of synchronous commit design is to handle sync replication and
providehigh data consistence and availablity. Meanwhile a time limit is also vaulable within this synchronous commit
process,which may protect things from getting wrose when some problems occur bewteen master and sync standbys.<br /><br
/>Like option ' <tt class="VARNAME">idle_in_transaction_session_timeout</tt>' in PostgreSQL 9.6, with a timeout, making
transactioncommit failed at bad condition rather than hanging untill things gets beteer.This doesn't break the
synchronouscommit semantic while becoming less unpredictable.<br /><br /><br />