| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| 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>, Daniel Farina <daniel(at)heroku(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Sync Rep v17 |
| Date: | 2011-03-03 04:24:16 |
| Message-ID: | AANLkTik6n3=ZFWDzAo5f7Ha+ne01afJGt8NBf6bmVSbd@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 3, 2011 at 6:33 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I don't understand how synchronous replication with
> allow_standalone_primary=on gives you ANY extra nines.
When you start the primary (or when there is one connected standby and
it crashes), allow_standalone_primary = on allows the database service
to proceed. OTOH, setting the parameter to off keeps the service stopping
until new standby has connected and has caught up with the primary. This
would cause long service down time, and decrease the availability.
Of course, running the primary alone has the risk. If its disk gets corrupted
before new standby appears, some committed transactions are lost. But
we can decrease this risk to a certain extent by using RAID or something
to the storage. So I think that some systems can accept the risk and prefer
the availability of the database service. Josh explained clearly before why
allow_standalone_primary = off is required for his case.
http://archives.postgresql.org/message-id/4CAE2488.9020207%40agliodbs.com
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2011-03-03 04:35:47 | Re: Sync Rep v17 |
| Previous Message | Fujii Masao | 2011-03-03 03:07:48 | Re: Sync Rep v17 |