From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
Cc: | Francisco Olarte <folarte(at)peoplecall(dot)com>, 余森彬 <justdoit920823(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why PostgreSQL doesn't implement a semi sync replication? |
Date: | 2016-11-12 03:27:46 |
Message-ID: | CAMsr+YFw1L8bSMz62yNGc-qk9=KVq27HEEw-=69hD9bP9ZCZgw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12 November 2016 at 02:12, Petr Jelinek <petr(at)2ndquadrant(dot)com> wrote:
> On 11/11/16 16:03, Francisco Olarte wrote:
>> On Fri, Nov 11, 2016 at 4:40 AM, 余森彬 <justdoit920823(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-11-12 04:46:08 | Re: pg_dump, pg_dumpall and data durability |
Previous Message | Andreas Karlsson | 2016-11-12 03:06:33 | Re: pg_sequence catalog |