Back from PGDay Belgium
For the first PGDay organized in Belgium by the PgBE PostgreSQL Users Group Belgium, this event regrouped around 40 PostgreSQL fans on 17 May 2019 in Leuven. It was for me a really nice day and I’d like to share it with you.
For the first PGDay organized in Belgium by the PgBE PostgreSQL Users Group Belgium, this event regrouped around 40 PostgreSQL fans on 17 May 2019 in Leuven. It was for me a really nice day and I’d like to share it with you.
As of 15 April 2019, there is only one repository RPM per distro, and it includes repository information for all available PostgreSQL releases.
This change, announced by Devrim on the pgsql-pkg-yum
mailing list, has some
impacts.
pgBackRest is a well-known powerful backup and restore tool.
While the documentation describes all the parameters, it’s not always that simple to imagine what you can really do with it.
In this post, I will introduce the asynchronous archiving and the possibility to avoid PostgreSQL to go down in case of archiving problems.
With its “info” command, for performance reasons, pgBackRest doesn’t check that all the needed WAL segments are still present. check_pgbackrest is clearly built for that. The two tricks mentioned above can produce gaps in the archived WAL segments. The new 1.5 release of check_pgbackrest provides ways to handle that, we’ll also see how.
pgBackRest is a well-known powerful backup and restore tool.
While it works with a really simple configuration, a major version upgrade of PostgreSQL has some impact on it.
Immediately after upgrading PostgreSQL to a newer major version, the pg-path
for all pgBackRest configurations must be set to the new database location and
the stanza-upgrade
command must be run.
That command updates the stanza information to reflect the new cluster information and, for example, allows to archiving process to work.
pgBackRest is a well-known powerful backup and restore tool.
Relying on the status information given by the “info” command, we’ve build a specific plugin for Nagios : check_pgbackrest.
This post will help you discover this plugin and assume you already know pgBackRest and Nagios.
pgBackRest is a well-known powerful backup and restore tool. It offers a lot of possibilities.
While pg_basebackup is commonly used to setup the initial database copy for the Streaming Replication, it could be interesting to reuse a previous database backup (eg. taken with pgBackRest) to perform this initial copy.
Furthermore, the --delta
option provided by pgBackRest can help us to
re-synchronize an old secondary server without having to rebuild it from
scratch.
To reduce the load on the primary server during a backup, pgBackRest even allows to take backups from a standby server.
We’ll see in this blog post how to do that.
PostgreSQL needs some infrastructure changes to have a more dynamic reconfiguration around recovery, eg. to change the primary_conninfo at runtime.
The first step, mostly to avoid having to duplicate the GUC logic, results on the following patch.
PGDay Amsterdam regrouped more than 90 PostgreSQL fans (according to Devrim) on 12 July 2018. It was for me a really nice day and I’d like to share it with you.
By default, on CentOS 7, the PostgreSQL v10 data directory is located in /var/lib/pgsql/10/data.
Here’s a simple trick to easily place it somewhere else without using symbolic links.
PAF (aka. “PostgreSQL Automatic Failover” : http://clusterlabs.github.io/PAF/) is a Resource Agent providing service High Availability for PostgreSQL, based on Pacemaker and Corosync.
In the previous post, we saw how to quickly install it. Let’s see now how to manage it.