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.
Last week I was invited by the Dutch PostgreSQL User Group in Amsterdam to speak on PostgreSQL Administration Recipes. It was the first session of 2016, and the third since they started meeting last year.
Using the simple format of a cooking recipe, I presented some techniques that a PostgreSQL DBA can use to solve recurring problems, for instance: change your password without leaving traces of the new password around; quickly estimate the number of rows in a table; see which parameters have a non-default setting; temporarily disable an index without dropping it. The last recipe was more philosophical: plan your backups, or better yet, plan your recovery!
After my talk I listened to the interesting presentation from Reiner Peterke who described pg_inside, his tool for collecting (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…)
Today version 1.4.0 of Barman has been officially released. The most important feature is incremental backup support, which relies on rsync and hard links and helps you reduce both backup time and disk space by 50-70%.
PostgreSQL 9.4 introduces a new statistic in the catalogue, called pg_stat_archiver.
Thanks to the SQL language it is now possible, in an instant, to check the state of the archiving process of transactional logs (WALs), crucial component of a PostgreSQL disaster recovery system.