在 2016/11/12 上午11:27, Craig Ringer 写道:
On 12 November 2016 at 02:12, Petr Jelinek wrote:
On 11/11/16 16:03, Francisco Olarte wrote:
On Fri, Nov 11, 2016 at 4:40 AM, 余森彬 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.
In my opinion, the semantic of synchronous commit design is to handle
sync replication and provide high 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.
Like option ' idle_in_transaction_session_timeout' in PostgreSQL 9.6,
with a timeout, making transaction commit failed at bad condition rather
than hanging untill things gets beteer.This doesn't break the
synchronous commit semantic while becoming less unpredictable.
