Hacker News Reader

Comment by pgr0ss | Hacker News Reader

To be safe, we always rebuild the old master after we fail over to a synchronous standby server. We have capistrano tasks to automate it, so it's not too bad. The async servers merely follow the new server after the IP moves, so we don't need to do anything there.

Edit: We also don't increment the timeline on failover. Instead, we stop PostgreSQL, remove the recovery.conf, and restart.

View on HN

I've got a 3 level setup, with a primary/secondary pair that are big machines, and a tertiary that's enough for an emergency, but not much more. They're all running hot spare.

I didn't feel safe blatting the new primary back to the secondary till we had the third level in there, since once you've failed over, you're at the mercy of that one machine and your latest backup is on the one that you're overwriting.

The third level one will follow the change in the recovery timeline if it's incremented in recovery.conf, and you make sure that it gets the appropriate history file.

Ah I see. We use a keepalived pair to shoot the old node in the head and promote a synchronous slave to a master in case of failure.

There is a patch to go into 9.3 I believe which allows you to handle timeline shifts through walsender instead of the archive. We're using gluster for the shared archive at the moment and it will be nice to reduce reliance upon it.

Thanks for the useful answer.

Reply on news.ycombinator.com