Re: Wierd quirk of HS/SR, probably not fixable
От | Heikki Linnakangas |
---|---|
Тема | Re: Wierd quirk of HS/SR, probably not fixable |
Дата | |
Msg-id | 4BD68FFD.5060603@enterprisedb.com обсуждение исходный текст |
Ответ на | Wierd quirk of HS/SR, probably not fixable (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Wierd quirk of HS/SR, probably not fixable
Re: Wierd quirk of HS/SR, probably not fixable |
Список | 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
В списке pgsql-hackers по дате отправления: