Re: Sync Rep v17

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Daniel Farina <daniel(at)heroku(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Sync Rep v17
Date: 2011-03-03 08:58:14
Message-ID: m2hbbk1syh.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I don't understand how synchronous replication with
> allow_standalone_primary=on gives you ANY extra nines. AFAICS, the
> only point of having synchronous replication is that you wait to
> acknowledge the commit to the client until the commit record has been
> replicated. Doing that only when the standby happens to be connected
> doesn't seem like it helps much.

Because you're still thinking in terms of data availability, rather than
in terms of service availability. With the later in mind, what you want
is to be able to continue servicing from the standby should the primary
crash, and you want a good guarantee about the standby's data.

Of course in such a situation you will have some monitoring to ensure
that the standby remains in sync, and you want to know that at failover
time. But a standby failure, when you want service availability, should
never bring the service down. It's what happens, though, if you've been
setting up *data* availability, because there there's no choice.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2011-03-03 10:27:45 Re: Quick Extensions Question
Previous Message Simon Riggs 2011-03-03 08:25:30 Re: Sync Rep v17