Thread: Why PostgreSQL doesn't implement a semi sync replication?
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)?
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.
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
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
<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 />