Re: Wierd quirk of HS/SR, probably not fixable

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

In response to

Responses

Browse pgsql-hackers by date

  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