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 (more…)
PostgreSQL 9.6 has extended the traditional framework available for physical backups by allowing users to take backups concurrently. Barman will transparently support this new set of functions without requiring the pgespresso extension.
The upcoming version 1.6.1 of Barman will introduce a few interesting
new features which consolidate its central role in business continuity
installations of PostgreSQL databases. Discover why.
During the last October's Italian PGDay and European PostgreSQL conference, my friend Marco Nenciarini and I had the pleasure to talk about a new open source plugin for PostgreSQL, called redislog.
In that presentation ("Integrating PostgreSQL with Logstash for real-time monitoring") we provided an example of our exploration/experimentation approach, with extensive and thorough coverage of testing and benchmarking activities. If you are curious to know more about that process, please refer to the slides of that talk, which are publicly available on Prezi.
For the impatient: redislog taps into PostgreSQL's logging facility and allows DBAs to ship log events into a Redis queue, directly in JSON format, and to enter the ELK stack through the first class lane.
Devops and the (more…)
Barman 1.5.0 enhances the robustness and business continuity capabilities of PostgreSQL clusters, integrating the get-wal command with any standby server's restore_command.
In this blog article I will go over the reasons behind this feature and briefly describe it.
One of the initial ideas we had in mind when conceiving Barman was to make it, one day, a very large basin of WAL files, collected from one or more PostgreSQL servers within the same organisation.
The internal codename of this feature was "WAL hub" and, in our mind, its main purpose was to allow any application (e.g. standby) to easily request and receive any WAL file for a given server, by enhancing Barman's command line interface and, ultimately, by implementing server support for PostgreSQL's streaming (more…)