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?

I'm using Postgres 9.2 with asynchronous streaming replication.


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.

More information:

  • 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 clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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