repmgr Replication Manager for PostgreSQL clusters

repmgr 2.0 RC2 released

What is repmgr?

repmgr is a set of open source tools that helps DBAs and System administrators manage a cluster of PostgreSQL databases.

By taking advantage of the Hot Standby capability introduced in PostgreSQL 9, repmgr greatly simplifies the process of setting up and managing database with high availability and scalability requirements.

repmgr simplifies administration and daily management, enhances productivity and reduces the overall costs of a PostgreSQL cluster by:

• monitoring the replication process;
• allowing DBAs to issue high availability operations such as switch-overs and fail-overs

repmgr is production quality software and used widely across the world with PostgreSQL. Many users rely on repmgr to maintain their replication setups and as such we take new releases seriously and mark the level of maturity as a guide for users. As repmgr 2.0 moves towards production we continue to regard the autofailover feature as currently in beta; we expect that to fully mature in the 2.1 release.

This release is mainly a bugfix release.

Bugfixes

• Do not enable autofailover by default.
• Fixed PQexec() calls: fixed several calls where we did not check the result status but only the return value of PQexec(); the query may have failed nonetheless
• Flush stderr after a log message appears: We had the problem that the log file appeared empty for a long time due to file buffers. Thus we call fflush() after every log message so the log file gets written out to disk quickly
• Fixed repmgr repl_status columns: repmgr repl_status view had the column time_lag which was documented to be the time a standby is behind master. In fact it only works like this when viewed on the standby and not on the master: there it only was the time of the last status update. We dropped that column and replaced it by a new column „communication_time_lag“ which is the content of the repl_status column on the master. On the standby we contain the time of the last update in shared mem though refer always to the correct time nonetheless where repl_status is queried. We also added a new column, „replication_time_lag“, which refers to the apply delay.
• Set connections to NULL when calling PQfinish() on them.
• Performance improvements: the old implementation took round about 8 seconds per monitoring interval because it got caught in a sleep call and had to wait for timeouts. MUCH too long, especially when you look at the default monitor_interval value of 2 seconds – we could never hold that. The new implementation uses PQgetResult() and select() to avoid the sleep and thus the monitoring routine now only uses a fraction of the time before (<1s).
• Leak and memory fixes: Fixed some leaks and an overlapping strcpy() call.
• Overhauled CloseConnections(): CloseCOnnections() did not have a NULL check for PQisBusy() call and was a macro. It also didn't set the connections to NULL. Now it is a function and sets the connections to NULL and checks for NULL before calling functions on connection variables.

Upcoming

Features we are working on in the near future:

• timeline increase when a standby gets promoted
• A better check which standby did receive most of the data
• Make the fact that a standby may be delayed a factor in the voting algorithm
• include support for delayed standbys

For more information take a look at http://repmgr.org/.

Community and development

repmgr is free and open source software and is licensed under the GPLv3.

Contributions to repmgr are welcome. See the README.rst file for information about how to contribute.

All repmgr code and documentation is Copyright © 2011-2020, 2ndQuadrant Limited. See the files COPYRIGHT and LICENSE for details.