One of the headline features of the brand new PostgreSQL release out 2 months ago is Logical Replication. Logical replication allows more flexibility than physical replication, including replication between different major versions of PostgreSQL and selective-table replication. You can get more details on the feature here.
So, now that we have this, I've been asked on occasion if we are still going to continue develop pglogical and if it's even needed. I was also asked a couple of times why we put the native logical replication into PostgreSQL when we already have pglogical. I'd like to answer those questions in this blog post.
Why Logical Replication in PostgreSQL 10?
Let's start with the simpler, or rather shorter, topic of why we added logical replication into PostgreSQL 10.
PostgreSQL 10 is getting close to its first beta release and it will include the initial support for logical replication, which is was written primarily by me and committed by my colleague Peter Eisentraut, and is internally based on the work 2ndQuadrant did on pglogical (even though the user interface is somewhat different).
I'd like to share some overview of basics in this blog post.
What's logical replication?
Let me start with briefly mentioning what logical replication is and what's it good for. I expect that most people know the PostgreSQL streaming master-standby replication that has been part of PostgreSQL for years and is commonly used both for high availability and read scaling.
So why add another replication mechanism and why call it logical? Well, the traditional
PostgreSQL 9.6 is now out and so is an updated version of pglogical that works with it.
For quick guide on how to upgrade the database with pglogical you can check my post which announced 9.6beta support.
The main change besides the support for 9.6.x release of PostgreSQL is in the way we handle the output plugin and apply plugin. They have now been merged into single code base and single package so that there is no need to track the pglogical_output separately for the users and developers alike.
We fixed several bugs this time and also made upgrades from 9.4 much easier.
Here is a more detailed list of changes:
keepalive is tuned to much smaller values by default so that pglogical will notice network issues earlier
better compatibility when upgrading from PostgreSQL 9.4
You may ask why do we release packages for beta version of Postgres? Well, one of the reasons is that you can use pglogical to replicate your existing PostgreSQL 9.5 or 9.4 database to the 9.6beta1 in real-time and run tests on it to help weed out any remaining bugs in the beta release. Here is a quick tutorial on how to do that.
We have made pglogical 1.1 packages available for PostgreSQL 9.6beta1 for both rpm and deb based distributions. They are available for install from our standard
The new feature version of pglogical is now available. The new release brings support for sequence replication, manually configured parallel subscriptions, replica triggers, numerous usability improvements and bug fixes. Let's look into the changes in more detail.
In last couple of months I've been working on online upgrade for very large databases as part of the AXLE project and I would like to share my thoughts on the topic and what progress we have made recently.
Before joining 2ndQuadrant I used to work in Skype where the business would not allow a maintenance window for our databases. This meant no downtime was allowed for deployments, upgrades, etc. That kind of rule makes you change the way you do things. Most changes are small, you don't do any heavy locks, you have replicas to allow for fast fail-over. But while you can make your releases small and non-blocking, what happens when you need to do a major version upgrade of the PostgreSQL database?
You might be in a different situation, as most companies do have an upgrade window, and