repmgr 3.3 introduces a number of additional options for setting up and managing replication clusters, with particular emphasis on cascading replication support. These changes will also make it easier to set up complex clusters using provisioning scripts.
Additionally there are changes to the repmgr command line utility's logging behaviour which you should take into consideration when running therepmgrd daemon.
repmgr is also tracking developments in the next major PostgreSQL release, 10.0, which will bring a lot of changes to the way PostgreSQL handles replication. At the time of writing, repmgr will work with the current PostgreSQL development code, but this combination is of course not suitable for use in production.
Changes to logging behaviour
Traditionally the repmgr command
repmgr 3.2 has recently been released with a number of enhancements, particularly support for 2ndQuadrant's Barman archive management server, additional cluster monitoring functionality and improvements to the standby cloning process.
One aim of this release is to remove the requirement to set up passwordless SSH between servers, which means when using repmgr's standard functionality to clone a standby, this is no longer a prerequisite. However, some advanced operations do require SSH access to be enabled.
repmgr 3.2 can now clone a standby directly from the Barman backup and recovery manager. In particular it is now possible to clone a standby from a Barman archive, rather than directly from a running database server. This means the server is not subjected to the I/O
The recently released repmgr 3.1.4 update incorporates several changes which improve usability and lay out the groundwork for enhanced compatibility with 2ndQuadrant's barman product.
New configuration option restore_command
It's now possible to specify a restore_command in repmgr.conf, which will be included in the recovery.conf file generated by repmgr standby clone, making it easier to configure a more robust replication setup by enabling PostgreSQL to fall back to a WAL archive source if streaming replication is interrupted. See Gabriele Bartolini's recent blog post "Speed up getting WAL files from Barman" for an example on how to do this.
CSV output for repmgr cluster show
The repmgr cluster show command now accepts the optional parameter --csv, which outputs the status of the
Greetings, honourable reader.
My name is Barwick of the 2ndQuadrant Company. With the onset of the Plum Rain, in my humble estimation it has become hot and humid recently. I trust all is well in your exalted undertakings?
No, I haven't flipped a bit - the above is actually pretty much how a Japanese business letter - or email - starts off, and there's a plethora of sites such as this one providing examples of various kinds of formal email. But fear not, this won't be a lesson in written Japanese business etiquette, but the first in an occasional series of posts from Japan, a country which embraced PostgreSQL very early on and has contributed much to its development.
A potted PostgreSQL history, Japanese style
Back in 2006, on a visit to Japan before I started living here, I
Japan has been an early and vigorous adopter of PostgreSQL (back in 2006, when PostgreSQL was still emerging from obscurity in the western hemisphere, I noted that in Tokyo bookstores, PostgreSQL books outweighed MySQL ones by about 5:3), and it's no surprise that by nationality, only the USA and Germany have more committers. The Japan PostgreSQL User Group (JPUG) has been around a while too and is one of the oldest and most active worldwide (and has been around long enough to have established a Japanese logo for PostgreSQL which is often used in place of Slonik [*]) . This year JPUG celebrates its 15th anniversary, and the 2014 conference - held in Tokyo on December 5th - was the largest yet with over 20 speakers, 5 (five!) parallel tracks and around 280 attendees.