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…)
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
# 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…)
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…)
Last week I was pleased to attend Code Sprint 2016 in Paris, organised by the OSGeo Foundation: it has been an opportunity for many GIS users from all over the world to get together, discuss and actively work on many open tasks of some of the major open source frameworks on GIS. PostGIS was obviously one of the projects involved in the Code Sprint.
Some background information first. A few months ago I started to work on adding BRIN support to the geospatial datatype available in PostGIS: I was able to develop a working prototype on my own.
However, it was thanks to this Code Sprint that I was finally able to complete the job. Code Sprint was the opportunity for me to know Julien and Ronan from Dalibo, who shared the same goals. We worked as a team and shared our skills and (more…)
The introduction of the JSONB data type in PostgreSQL, definitely makes the “NoSQL” side of this relational DBMS come out: this introduction meets the requirements of all those who prefer a data structure in a “key-value” array, dictionary style (widely used in the field of development) and, at the same time, ensures all the advantages of a relational database.
Written by Giuseppe Broccolo
First published in Italian
Since PostgreSQL 9.3, it is possible to update and insert into views directly, so long as the view refers to only one underlying table.
PostgreSQL 9.4 allows us to use the CHECK clause for INSERTs into updatable views. For example, consider a table composed of just one integer column; and consider two views, one on numbers divisible by 2 and one on numbers divisible by 3. If we try to insert the number 123 into the first view:
$ CREATE TABLE some_data(id int4 PRIMARY KEY);
$ CREATE VIEW first AS SELECT * FROM some_data WHERE 0 = id%2;
$ CREATE VIEW second AS SELECT * FROM some_data WHERE 0 = id%3;
$ INSERT INTO first(id) VALUES (123 (more…)