Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For starters, I do not have any sort of automated failover in place.

After two scenarios, I'm unsure of the state of the database and any required actions, if any, to take:

  1. My master server disappears off the face of the planet and I touch my_trigger_file, converting my standby into a master server.
  2. My master server crashes, then restarts in recovery mode

My assumption is that the server in question in each of those scenarios will first be in recovery mode, will then finish recovering, and will finally be ready as a master server. In scenario 2 my assumption means things are back to normal, while in scenario 1 my assumption means the standby has no idea it was ever a standby and is now simply a master. Are these assumptions correct, or are there other actions that need to take place in either or both scenarios after recovery finishes (aside from creating a new slave in the case of scenario 1)?

Also, is there a notable technical difference between the state of a slave server after becoming a master vs a master server undergoing recovery after a crash, or as far as Postgres is concerned, are they both essentially master servers that just recovered from something?

Note: I'm using Postgres 9.2 with asynchronous streaming replication.

share|improve this question
up vote 3 down vote accepted

@orokusaki, are you still experiencing difficulties? May I suggest upgrading to PostgreSQL 9.3 (freshly out!)? Some write that the new Streaming-Only Remastering capability turns a replica in a set of replicas into the new master for all of the other replicas. Apparently, it's even more useful in combination with the cascading replication you are using in 9.2

In PostgreSQL 9.2, cascading replication really requires file-based WAL archiving to work in case of disaster recovery. PostgreSQL 9.3 will not require that: you can set up large replication clusters of whatever length you want without any WAL archiving.

See more here: and here:

share|improve this answer
Thanks so much. I actually ended using Heroku (with their Postgres offering). I just didn't feel comfortable enough trying to run everything on my own, and felt irresponsible for trying (since it's a real company of mine, not a personal project). Also, I ran into a 6 hour downtime at Rackspace, and the Rackspace people A) weren't even aware that my server was down due to a hardware failure, and B) took 4.5 hours to fix the single disk failure after I reported my server was down. My reason for using them in the first place was to avoid the (rumored) downtime hours that Heroku has each month... – orokusaki Oct 29 '13 at 16:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.