On 12 November 2016 at 02:12, Petr Jelinek <p...@2ndquadrant.com> wrote: > On 11/11/16 16:03, Francisco Olarte wrote: >> On Fri, Nov 11, 2016 at 4:40 AM, 余森彬 <justdoit920...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
