Monday, June 26

Tag: Barman

Kanban & devops culture at 2ndQuadrant – Part 2

DevOps
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.(more…)

repmgr 3.3

Ian's PlanetPostgreSQL
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 ...

Barman 2.1 and the new –archive option

Giulio's PlanetPostgreSQL
Barman 2.1 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. switch-xlog --archive 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...

repmgr 3.2 is here with Barman support and Brand New High Availability features

Ian's PlanetPostgreSQL, repmgr
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. Barman support 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 l...

Improvements in repmgr 3.1.4

Ian's PlanetPostgreSQL
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 rep...
Speed up getting WAL files from Barman

Speed up getting WAL files from Barman

Featured, Gabriele's PlanetPostgreSQL
Starting from Barman 1.6.1, PostgreSQL standby servers can rely on an "infinite" basin of WAL files and finally pre-fetch batches of WAL files in parallel from Barman, speeding up the restoration process as well as making the disaster recovery solution more resilient as a whole.The master, the backup and the standby Before we start, let's define our playground. We have our PostgreSQL primary server, called angus. A server with Barman, called barman and a third server with a reliable PostgreSQL standby, called chris - for different reasons, I had to rule out the following names bon, brian, malcolm, phil, cliff and obviously axl. ;)angus is a high workload server and is continuously backed up on barman, while chris is a hot standby server with streaming replication from angus ...