Thread: Geographical multi-master replication
Hi Everybody,
I am currently working with a client that has requirements for geographically dispersed multi-master replication.
The current solution that we have in place is the BDR 1.0.7, which is asynchronous and eventually consistent and it is actually very close to real time. So far we are managing a small cluster of three nodes and we are very happy with this solution.
The problem is that the version for BDR 1.0.7, which has an implementation for postgres 9.4, will be on end of live at the end of this year. Unfortunately the paid solution is out of our budget, so we currently have two options: find an alternative or remove the multi-region implementation. We are currently looking for alternatives.
Reading the different replication options in PostgreSQL 11, it looks like there are two options that might be suitable:
1 - Logical Replication, which according to the documentation Logical replication doesn't require a particular server to be designated as a master or a replica but allows data to flow in multiple directions. It should be suitable. The limitations are OK for us, however there is no such thing as conflict resolution. If there is a conflict, the replication just stops. In our application (currently replicated using BDR), we have a very small amount of conflicts, and when conflict happens they are harmless.
What do you think about this solution for geographically dispersed multi-master replication ?
Is there any configuration options for the conflict resolution in the Logical Replication ?
2 - Asynchronous Multimaster Replication - For example by using Bucardo. Does anybody has experience for using Bucardo for Asynchronous Multimaster Replication ? Would be suitable for geographically dispersed infrastructures ?
Is there any other option available that I might be missing ?
Thanks in advance,
Ruben
The problem is that the version for BDR 1.0.7, which has an implementation for postgres 9.4, will be on end of live at the end of this year. Unfortunately the paid solution is out of our budget, so we currently have two options: find an alternative or remove the multi-region implementation. We are currently looking for alternatives.
You are missing all of the alternatives here. Why don't you consider upgrading from postgres 9.4 and with it to a supported version of BDR? There is nothing better you can do to keep your infrastructure up to date, performant, secure, and actually meet your multi-master needs than to upgrade to a newer version of postgres which does have BDR support.
Even "stock" postgres 9.4 is set for end of life soon. Upgrade!
Thanks,
Jeremy
Am 25.01.19 um 06:10 schrieb Jeremy Finzel: > > The problem is that the version for BDR 1.0.7, which has an > implementation for postgres 9.4, will be on end of live at the end > of this year. Unfortunately the paid solution is out of our > budget, so we currently have two options: find an alternative or > remove the multi-region implementation. We are currently looking > for alternatives. > > > You are missing all of the alternatives here. Why don't you consider > upgrading from postgres 9.4 and with it to a supported version of > BDR? There is nothing better you can do to keep your infrastructure > up to date, performant, secure, and actually meet your multi-master > needs than to upgrade to a newer version of postgres which does have > BDR support. > > Even "stock" postgres 9.4 is set for end of life soon. Upgrade! ACK! Sure, you have to pay for a support contract, and this isn't for free, but you will get a first-class support for BDR. If you really needs a worldwide distributed multi-master solution you should be able to buy that. Regards, Andreas -- 2ndQuadrant - The PostgreSQL Support Company. www.2ndQuadrant.com
I do not know the use case but we did try the following.
We had a small requirement wrt some regional data written to tables but needs to be available to all regions.
We made use of logical replication to replicate/publish each local table to all the other regions ( like a many to many)
In theory, if there were no network delay all regions will have all the data at any point of time.
If there is a wan outage b/w A and B,
They both still talk to C and c can be considered the region with more correct data, till we have others recovered.
basically given we had disjoint data, we were able to make use of this feature.
And it it definitely not for HA, there are other options for it.
On Fri, 25 Jan 2019 at 11:16 AM Andreas Kretschmer <andreas@a-kretschmer.de> wrote:
Am 25.01.19 um 06:10 schrieb Jeremy Finzel:
>
> The problem is that the version for BDR 1.0.7, which has an
> implementation for postgres 9.4, will be on end of live at the end
> of this year. Unfortunately the paid solution is out of our
> budget, so we currently have two options: find an alternative or
> remove the multi-region implementation. We are currently looking
> for alternatives.
>
>
> You are missing all of the alternatives here. Why don't you consider
> upgrading from postgres 9.4 and with it to a supported version of
> BDR? There is nothing better you can do to keep your infrastructure
> up to date, performant, secure, and actually meet your multi-master
> needs than to upgrade to a newer version of postgres which does have
> BDR support.
>
> Even "stock" postgres 9.4 is set for end of life soon. Upgrade!
ACK!
Sure, you have to pay for a support contract, and this isn't for free,
but you will get a first-class support for BDR. If you really needs a
worldwide distributed multi-master solution you should be able to buy that.
Regards, Andreas
--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com
Vijay
På fredag 25. januar 2019 kl. 06:45:43, skrev Andreas Kretschmer <andreas@a-kretschmer.de>:
Am 25.01.19 um 06:10 schrieb Jeremy Finzel:
>
> The problem is that the version for BDR 1.0.7, which has an
> implementation for postgres 9.4, will be on end of live at the end
> of this year. Unfortunately the paid solution is out of our
> budget, so we currently have two options: find an alternative or
> remove the multi-region implementation. We are currently looking
> for alternatives.
>
>
> You are missing all of the alternatives here. Why don't you consider
> upgrading from postgres 9.4 and with it to a supported version of
> BDR? There is nothing better you can do to keep your infrastructure
> up to date, performant, secure, and actually meet your multi-master
> needs than to upgrade to a newer version of postgres which does have
> BDR support.
>
> Even "stock" postgres 9.4 is set for end of life soon. Upgrade!
ACK!
Sure, you have to pay for a support contract, and this isn't for free,
but you will get a first-class support for BDR. If you really needs a
worldwide distributed multi-master solution you should be able to buy that.
Regards, Andreas
To my surprise I'm unable to find downloadable BDR3. I thought it was an open-source extention to vanilla-pg-11, isn't that the case anymore?
-- 
Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
Attachment
Am 25.01.19 um 10:10 schrieb Andreas Joseph Krogh: > To my surprise I'm unable to find downloadable BDR3. I thought it was > an open-source extention to vanilla-pg-11, isn't that the case anymore? yeah, you have to sign a support contract. It works as a extension to vanilla-pg-11, but it's not open source. Regards, Andreas -- 2ndQuadrant - The PostgreSQL Support Company. www.2ndQuadrant.com
On Fri., 25 Jan. 2019, 8:40 pm Andreas Kretschmer <andreas@a-kretschmer.de wrote:
Am 25.01.19 um 10:10 schrieb Andreas Joseph Krogh:
> To my surprise I'm unable to find downloadable BDR3. I thought it was
> an open-source extention to vanilla-pg-11, isn't that the case anymore?
yeah, you have to sign a support contract. It works as a extension to
vanilla-pg-11, but it's not open source.
Also, no Windows support, which makes it a non starter for our organisation.
Hi Jeremy,
> Why don't you consider upgrading from postgres 9.4 and with it to a supported version of BDR? There is nothing better you can do to keep your infrastructure up to date, performant, secure, and actually meet your multi-master needs than to upgrade to a newer version of postgres which does have BDR support.
This is something that we have definitely thought of. That would be a good alternative but I have an strong feeling that the business won't be willing to pay for it. The cost of the paid BDR version, in comparison with the current fixed expenses of the infrastructure, are just too large. That's why we are researching alternatives.
On Fri, Jan 25, 2019 at 4:10 PM Jeremy Finzel <finzelj@gmail.com> wrote:
The problem is that the version for BDR 1.0.7, which has an implementation for postgres 9.4, will be on end of live at the end of this year. Unfortunately the paid solution is out of our budget, so we currently have two options: find an alternative or remove the multi-region implementation. We are currently looking for alternatives.You are missing all of the alternatives here. Why don't you consider upgrading from postgres 9.4 and with it to a supported version of BDR? There is nothing better you can do to keep your infrastructure up to date, performant, secure, and actually meet your multi-master needs than to upgrade to a newer version of postgres which does have BDR support.Even "stock" postgres 9.4 is set for end of life soon. Upgrade!Thanks,Jeremy
On Mon, Jan 28, 2019 at 3:32 PM Ruben Rubio Rey <tk421.1@gmail.com> wrote:
Hi Jeremy,> Why don't you consider upgrading from postgres 9.4 and with it to a supported version of BDR? There is nothing better you can do to keep your infrastructure up to date, performant, secure, and actually meet your multi-master needs than to upgrade to a newer version of postgres which does have BDR support.This is something that we have definitely thought of. That would be a good alternative but I have an strong feeling that the business won't be willing to pay for it. The cost of the paid BDR version, in comparison with the current fixed expenses of the infrastructure, are just too large. That's why we are researching alternatives.
When I said “supported version” of BDR, I mostly meant a newer version of Postgres. I know you have to decide on getting support BDR but regardless of what route you take, part of your plan needs to be > 9.4 :).
Thanks,
Jeremy
> When I said “supported version” of BDR, I mostly meant a newer version of Postgres. I know you have to decide on getting support BDR but regardless of what route you take, part of your plan needs to be > 9.4 :).
I agree with you. We will be upgrading to the latest postgres version.
On Tue, Jan 29, 2019 at 8:48 AM Jeremy Finzel <finzelj@gmail.com> wrote:
On Mon, Jan 28, 2019 at 3:32 PM Ruben Rubio Rey <tk421.1@gmail.com> wrote:Hi Jeremy,> Why don't you consider upgrading from postgres 9.4 and with it to a supported version of BDR? There is nothing better you can do to keep your infrastructure up to date, performant, secure, and actually meet your multi-master needs than to upgrade to a newer version of postgres which does have BDR support.This is something that we have definitely thought of. That would be a good alternative but I have an strong feeling that the business won't be willing to pay for it. The cost of the paid BDR version, in comparison with the current fixed expenses of the infrastructure, are just too large. That's why we are researching alternatives.When I said “supported version” of BDR, I mostly meant a newer version of Postgres. I know you have to decide on getting support BDR but regardless of what route you take, part of your plan needs to be > 9.4 :).Thanks,Jeremy