3

We're setting up a PostgreSQL cluster, and we're looking at using repmgr to handle standby promotion and so on.

Our cluster has one master and a hot standby, and uses the streaming replication features of PostgreSQL 9.1.

Since we're using streaming replication, writes to the master will no longer go through when the standby fails. So we would like to use repmgr to not only promote the hot standby when the master fails, but also to use repmgr to disable streaming replication when the standby fails.

Are there any suggestions on how to do this? All the documentation seems centred around a failure with the master.

Improve this question

1 Answer 1

Reset to default
3

Since we're using streaming replication, writes to the master will no longer go through when the standby fails.

Not necessarily the case. This is only the case when you are setting up synchronous streaming replication. Normally the master will return immediately after it writes its own log files to disk and not wait for the slave. It is then replicated out when the slave requests.

See the synchronous_commit parameter.

I don't see why you need to futz with repmgr for this.

Improve this answer
3
  • We actually are using synchronous replication. I see that wasn't mentioned in my question though :-/ We landed up not using repmgr, and wrote a little tool to notice if nodes have gone down, to promote a standby as needed, or to turn off synchronous replication.
    – River
    Apr 23, 2013 at 13:48
  • If you only have one backup, you are getting very little out of synchronous replication. I would recommend either having a second backup server or going async.
    – Chris Travers
    Apr 23, 2013 at 13:56
  • 1
    Just to clarify that.... The only difference between synchronous_commit being on or off is that it waits for the standby to say it has committed before returning this to the client. If your answer to "the slave went down" is to turn replication off, you are getting nothing out of the additional guarantee that synchronous commit gives you, which is that once the commit is finished the data exists on at least x number of servers. You will have far fewer issues by simply not offering the guarantee in the first place than by offering it except when you don't.
    – Chris Travers
    Apr 24, 2013 at 9:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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