Tag: standby

Dec82017 by Shaun Thomas3 Comments

PG Phriday: Getting RAD with Docker [Part 4]

PgBouncer is a popular proxy and pooling layer for Postgres. It's extremely common to reconfigure PgBouncer with repmgr so it always directs connections to the current primary node. It just so happens our emerging Docker stack could use such a component.In our last article, we combined Postgres with repmgr to build a Docker container that could initialize and maintain a Postgres cluster with automated failover capabilities. Yet there was the lingering issue of connecting to the cluster. It's great that Postgres is always online, but how do we connect to whichever node is the primary?While we could write a layer into our application stack to call repmgr cluster show to find the primary before connecting, that's extremely cumbersome. Besides that, there's a better way. Let's alter our stack (more…)

Oct172016 by 2ndQuadrant PressNo Comments

Back to the Future Part 3: pg_rewind with PostgreSQL 9.6

2ndQuadrant, Giuseppe's PlanetPostgreSQL

This is the third and last part of blog articles dedicated to pg_rewind. In the two previous articles we have seen how pg_rewind is useful to fix split-brain events due to mistakes in the switchover procedures, avoiding the need of new base backups. We have also seen that this is true for simple replication clusters, where more standby nodes are involved. In this case, just two nodes can be fixed, and the other ones need a new base backup to be re-synchronised. pg_rewind for PostgreSQL 9.6 is now able to work with complex replication clusters. Indeed, pg_rewind has been extended so it can view the timeline history graph of an entire HA cluster, like the one mentioned in my previous blog article. It is able to find out the most recent, shared point in the timeline history between (more…)

Sep282016 by 2ndQuadrant PressNo Comments

Back to the Future Pt. 2: How to use pg_rewind with PostgreSQL 9.5

2ndQuadrant, Featured, Giuseppe's PlanetPostgreSQL

In the previous blog article we have seen how pg_rewind works with a simple HA cluster, composed of a master node replicating to a standby. In this context, an eventual switchover involves just two nodes that have to be aligned. But what happens with HA clusters when there are several (also cascading) standbys? Now, consider a more complicated HA cluster, composed of a master with two standbys, based on PostgreSQL 9.5; similar to what has been made in the first blog article dedicated to pg_rewind, we now create a master node replicating to two standby instances. Let's start with the master: # Set PATH variable export PATH=/usr/pgsql-9.5/bin:${PATH} # This is the directory where we will be working on # Feel free to change it and the rest of the script # will adapt itself (more…)

Sep122016 by 2ndQuadrant Press16 Comments

Back to the Future Pt. 1: Introduction to pg_rewind

2ndQuadrant, Featured, Giuseppe's PlanetPostgreSQL

Since PostgreSQL 9.5, pg_rewind has been able to make a former master follow up a promoted standby although, in the meantime, it proceeded with its own timeline. Consider, for instance, the case of a switchover that didn't work properly. Have you ever experienced a "split brain" during a switchover operation? You know, when the goal is to switch the roles of the master and the standby, but instead you end up with two independent masters - each one with its own timeline? For PostgreSQL DBAs in HA contexts, this where pg_rewind comes in handy! Until PostgreSQL 9.5, there was only one solution to this problem: re-synchronise the PGDATA of the downgraded master with a new base backup and add it to the HA cluster as a new standby node. Generally, this is not a problem, unless your (more…)

Aug172016 by Gulcin Yildirim2 Comments

Evolution of Fault Tolerance in PostgreSQL: Synchronous Commit

2ndQuadrant, Featured, Gulcin's PlanetPostgreSQL, PostgreSQL

PostgreSQL is an awesome project and it evolves at an amazing rate. We’ll focus on evolution of fault tolerance capabilities in PostgreSQL throughout its versions with a series of blog posts. This is the fourth post of the series and we’ll talk about synchronous commit and its effects on fault tolerance and dependability of PostgreSQL. If you would like to witness the evolution progress from the beginning, please check the first three blog posts of the series below. Each post is independent, so you don't actually need to read one to understand another. Evolution of Fault Tolerance in PostgreSQL Evolution of Fault Tolerance in PostgreSQL: Replication Phase Evolution of Fault Tolerance in PostgreSQL: Time Travel Synchronous Commit By default, PostgreSQL (more…)

Jul212016 by Gulcin YildirimNo Comments

Evolution of Fault Tolerance in PostgreSQL: Time Travel

2ndQuadrant, Featured, Gulcin's PlanetPostgreSQL, PostgreSQL

PostgreSQL is an awesome project and it evolves at an amazing rate. We’ll focus on evolution of fault tolerance capabilities in PostgreSQL throughout its versions with a series of blog posts. This is the third post of the series and we’ll talk about timeline issues and their effects on fault tolerance and dependability of PostgreSQL. If you would like to witness the evolution progress from the beginning, please check the first two blog posts of the series: Evolution of Fault Tolerance in PostgreSQL Evolution of Fault Tolerance in PostgreSQL: Replication Phase Timelines The ability to restore the database to a previous point in time creates some complexities which we’ll cover some of the cases by explaining failover (Fig. 1), switchover (Fig. 2) and pg_rewind (Fig (more…)

Jul192016 by Gabriele BartoliniNo Comments

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

Jul112016 by Gulcin YildirimNo Comments

Evolution of Fault Tolerance in PostgreSQL: Replication Phase

2ndQuadrant, Featured, Gulcin's PlanetPostgreSQL, PostgreSQL

PostgreSQL is an awesome project and it evolves at an amazing rate. We’ll focus on evolution of fault tolerance capabilities in PostgreSQL throughout its versions with a series of blog posts. This is the second post of the series and we'll talk about replication and its importance on fault tolerance and dependability of PostgreSQL. If you would like to witness the evolution progress from the beginning, please check the first blog post of the series: Evolution of Fault Tolerance in PostgreSQL PostgreSQL Replication Database replication is the term we use to describe the technology used to maintain a copy of a set of data on a remote system. Keeping a reliable copy of a running system is one of the biggest concerns of redundancy and we all like maintainable, easy-to-use and (more…)

Oct62015 by Gabriele Bartolini1 Comment

Getting WAL files from Barman with ‘get-wal’

Barman, Gabriele's PlanetPostgreSQL

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…)