Take the 2-minute tour ×
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. It's 100% free, no registration required.

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.

share|improve this question
add comment

1 Answer 1

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.

share|improve this answer
    
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 '13 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 '13 at 13:56
    
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 '13 at 9:09
add comment

Your Answer

 
discard

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.