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.
- Do not enable autofailover by default.
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
stderrafter 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_statusview had the column
time_lagwhich 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
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_intervalvalue of 2 seconds – we could never hold that. The new implementation uses
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
CloseCOnnections()did not have a
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
NULLand checks for
NULLbefore calling functions on connection variables.
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.