Saturday, June 24

Tag: pg_rewind

Back to the Future Part 3: pg_rewind with PostgreSQL 9.6

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...
Back to the Future Pt. 2: How to use pg_rewind with PostgreSQL 9.5

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...
Back to the Future Pt. 1: Introduction to pg_rewind

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...
Evolution of Fault Tolerance in PostgreSQL: Synchronous Commit

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 TravelSynchronous CommitBy default, PostgreSQL implements
Evolution of Fault Tolerance in PostgreSQL: Time Travel

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. 3) case
Evolution of Fault Tolerance in PostgreSQL

Evolution of Fault Tolerance in PostgreSQL

2ndQuadrant, Featured, Gulcin's PlanetPostgreSQL, PostgreSQL
"It is paradoxical, yet true, to say, that the more we know, the more ignorant we become in the absolute sense, for it is only through enlightenment that we become conscious of our limitations. Precisely one of the most gratifying results of intellectual evolution is the continuous opening up of new and greater prospects." Nikola TeslaPostgreSQL 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. (more…)