From: | 余森彬 <justdoit920823(at)gmail(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com> |
Cc: | Francisco Olarte <folarte(at)peoplecall(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 06:56:56 |
Message-ID: | ebcb266c-ee31-d823-7ba8-b2934718c985@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
在 2016/11/12 上午11:27, Craig Ringer 写道:
> 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.
>
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2016-11-12 11:12:41 | Re: Patch: Write Amplification Reduction Method (WARM) |
Previous Message | Amit Kapila | 2016-11-12 05:49:38 | Re: Hash Indexes |