From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Wierd quirk of HS/SR, probably not fixable |
Date: | 2010-04-27 07:19:25 |
Message-ID: | 4BD68FFD.5060603@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus wrote:
> Here's a way to trap yourself:
>
> (1) Set up an HS/SR master
> (2) pg_start_backup on the master
> (3) clone the master to 1 or more slaves
> (4) Fast shutdown the master (without pg_stop_backup)
> (5) Restart the master
> (6) Bring up the slaves
>
> Result: the slaves will come up fine in recovery mode. However, they
> will never switch over to HS mode or start SR. You will not be able to
> pg_stop_backup() on the master. At this point, you have no option but
> to shut down the slaves and re-clone.
>
> The only reason why this is somewhat problematic for users is that you
> will not get any messages from the master or the slaves to indicate why
> they won't switch modes. So I can imagine someone wasting a lot of time
> troubleshooting the wrong problems.
>
> Suggested resolution: I don't think there's and logical "fix" for this
> case; it should just be added to the docs as a failure/troubleshooting
> condition.
Hmm, we could throw an error in the standby, when we see a shutdown
checkpoint while we're waiting for an end-backup record. If the database
was shut down before pg_stop_backup(), we know that the backup was
cancelled and the end-backup record we're waiting for will never arrive.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2010-04-27 08:07:11 | Re: recovery_connections cannot start |
Previous Message | Tom Lane | 2010-04-27 02:37:18 | Re: testing HS/SR - 1 vs 2 performance |