From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hot standby, recent changes |
Date: | 2009-12-06 22:26:15 |
Message-ID: | 603c8f070912061426h5301b6e5jfa5cd03ea39cb88e@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Dec 6, 2009 at 3:06 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Sun, 2009-12-06 at 20:32 +0200, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>> > On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote:
>> >> 4. Need to handle the case where master is started up with
>> >> wal_standby_info=true, shut down, and restarted with
>> >> wal_standby_info=false, while the standby server runs continuously. And
>> >> the code in StartupXLog() to initialize recovery snapshot from a
>> >> shutdown checkpoint needs to check that too.
>> >
>> > I don't really understand the use case for shutting down the server and
>> > then using it as a HS base backup. Why would anyone do that? Why would
>> > they have their server down for potentially hours, when they can take
>> > the backup while the server is up? If the server is idle, it can be
>> > up-and-idle just as easily as down-and-idle, in which case we wouldn't
>> > need to support this at all. Adding yards of code for this capability
>> > isn't important to me. I'd rather strip the whole lot out than keep
>> > fiddling with a low priority area. Please justify this as a real world
>> > solution before we continue trying to support it.
>>
>> This affects using a shutdown checkpoint as a recovery start point
>> (restore point) in general, not just a fresh backup taken from a shut
>> down database.
>>
>> Consider this scenario:
>>
>> 0. You have a master and a standby configured properly, and up and running.
>> 1. You shut down master for some reason.
>> 2. You restart standby. For some reason. Maybe by accident, or you want
>> to upgrade minor version or whatever.
>> 3. Standby won't accept connections until the master is started too.
>> Admin says "WTF?"
>
> OK, I accept that as a possible scenario.
>
> I'm concerned that the number of possible scenarios we are trying to
> support in the first version is too high, increasing the likelihood that
> some of them do not work correctly because the test scenarios didn't
> re-create them exactly.
>
> In the above scenario, if it is of serious concern the admin can
> failover to the standby and then access the standby for queries. If the
> master was down for any length of time that's exactly what we'd expect
> to happen anyway.
>
> So I don't see the scenario as very likely; I'm sure it will happen to
> somebody. In any case, it is in the opposite direction to the main
> feature, which is a High Availability server, so any admin that argued
> that he wanted to have his HA standby stay as a standby in this case
> would likely be in a minority.
>
> I would rather document it as a known caveat and be done.
For what it's worth, this doesn't seem particularly unlikely or
unusual to me. But on the other hand, I do really want to get this
committed soon, and I don't have time to help at the moment, so maybe
I should keep my mouth shut.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2009-12-06 22:39:04 | Re: Hot standby, recent changes |
Previous Message | Simon Riggs | 2009-12-06 20:06:47 | Re: Hot standby, recent changes |