In Part 2 of this series, we will continue our journey within the developmental dynamics of the Barman open source project for PostgreSQL database backup and disaster recovery. After providing a small introduction to devops and Kanban in Part 1, let's focus on the basic element of our daily management: The Boards.
We very often hear about devops culture, lean and agile methodologies, kanban, pair programming, peer review, testing, and many more; but how many of us could effectively put these things into practice?
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 (more…)
Version 2.1 of Barman, backup and recovery manager for PostgreSQL, was released Thursday, Jan. 5.
The new release, along with several bugfixes, introduces preliminary support for the upcoming PostgreSQL 10, and adds the --archive option to the switch-xlog command.
The new --archive option is especially useful when setting up a new server.
Until now, the switch-xlog command used to force the PostgreSQL server to switch to a different transaction log file. Now, Barman also gives the --archive option, which triggers WAL archiving after the xlog switch, and forces Barman to wait for the archival of the closed WAL file.
By default Barman expects to receive the WAL in 30 seconds, the amount of seconds to wait can be changed using the --archive-timeout (more…)
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 (more…)
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 (more…)