Managing useful clusters with repmgr

August 29, 2012

To create a standby in PostgreSQL is relatively easy, and because of the hot standby feature, that alone is certainly very useful.

But creating a useful cluster that gives us real HA that’s another story. The complexities added by failure detection, STONITH rules and choosing a new master could be overwhelming. But still, it is an important part of maintaining a healthy PostgreSQL environment.

Repmgr 2.0 gives you the opportunity to configure a more streamlined failover process for when you need it.

Repmgr 2.0 was released as a beta about a month ago, and we incorporated many feature requests received from the community. If you requested something of the tool which didn’t make it into this release, keep on us, as we’ve been working hard to insure we a had release out prior to 9.2 launch.

For those of you familiar with our initial version, repmgr 2.0 contains some functionality updates to make the tool more useful.

Because of the auto failover functionality,we no longer have the need for history logging to choose the best candidate to promote as new master saving precious IO bandwidth. The script accomplishes this by auto detecting which node is most up to date and failing over to that one. We also added a node_name in repl_nodes table, so we can identify servers better, because this name is used as application_name in the replication connection to the server, when we see pg_stat_replication we can better identify every connection.

Subsequent to that there is also CLUSTER SHOW command (thanks to our friends in Italy), allowing the user to query and see what nodes are part of our cluster if it’s working (we can connect to it) and its role on the cluster: primary, standby or witness.

The CLUSTER_CLEANUP command (we heard from many users on this) is also important as it negates the task of manually cleaning up repl_monitor table, saving time and accidental deletion of a live node from the table.

My personal favorite segment of the tool update is the autofailover. It’s so flexible that we allow the user to supply a customized script to execute several commands at failover time. For example it could be combined with pgbouncer to make a simple failover setup that did not require root privileges. 

Share this