<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 />