PostgreSQL & BDR: Is BDR truly multi-master, is it Open Source and EOL for 1.x in 2019?
I am confused regarding PostgreSQL BDR and I have several questions:
Question 1: Is BDR truly multi-master for PostgreSQL?
According to the docs here, it says that:
The BDR (Bi-Directional Replication) project adds multi-master
replication to PostgreSQL 9.4
but if I read on 2ndQuadrant, I read the following:
If I read that part, they dont mention multi-master much at all; just that a "second master, working in passive", which indicates its not a real master?
Question 2: Is BDR open-source?
I read here that it is, at least that it was:
BDR is the first open source multi-master replication system for PostgreSQL
Is it still? Because when I look, I am often directed to 2ndQuadrants webpage, and that gives me the impression that its not open-source, when they say that:
How can you get Postgres-BDR?
Just fill out the contact form below and a PostgreSQL expert will be in touch shortly!
Sounds like selling to me =)
Question 3: What version is what?
I read that 2ndQuadrant released version 1.0.5 in March this year. I also read on 2ndQuadrants webpage that
In the complex environment of replication, the 3rd generation of BDR achieves...
The 3rd gen? Is version 1.0.5 that same 3rd gen, or is it something else?
Also, the same page says that:
Note for current Postgres-BDR users: BDR 1.x will reach EOL in December 2019. Our team of PostgreSQL experts can help plan and execute your upgrade with minimal impact and almost zero downtime. Contact us today and a member of our professional services team will be in touch with you as soon as possible.
So, 1.0.5 was released in March, but has EOL in December 2019? Is 2.x not open-source, so some licens cost associated with it, and 1.x is EOL 2019?
Please clarify =)
postgresql postgresql-bdr postgres-bdr
add a comment |
I am confused regarding PostgreSQL BDR and I have several questions:
Question 1: Is BDR truly multi-master for PostgreSQL?
According to the docs here, it says that:
The BDR (Bi-Directional Replication) project adds multi-master
replication to PostgreSQL 9.4
but if I read on 2ndQuadrant, I read the following:
If I read that part, they dont mention multi-master much at all; just that a "second master, working in passive", which indicates its not a real master?
Question 2: Is BDR open-source?
I read here that it is, at least that it was:
BDR is the first open source multi-master replication system for PostgreSQL
Is it still? Because when I look, I am often directed to 2ndQuadrants webpage, and that gives me the impression that its not open-source, when they say that:
How can you get Postgres-BDR?
Just fill out the contact form below and a PostgreSQL expert will be in touch shortly!
Sounds like selling to me =)
Question 3: What version is what?
I read that 2ndQuadrant released version 1.0.5 in March this year. I also read on 2ndQuadrants webpage that
In the complex environment of replication, the 3rd generation of BDR achieves...
The 3rd gen? Is version 1.0.5 that same 3rd gen, or is it something else?
Also, the same page says that:
Note for current Postgres-BDR users: BDR 1.x will reach EOL in December 2019. Our team of PostgreSQL experts can help plan and execute your upgrade with minimal impact and almost zero downtime. Contact us today and a member of our professional services team will be in touch with you as soon as possible.
So, 1.0.5 was released in March, but has EOL in December 2019? Is 2.x not open-source, so some licens cost associated with it, and 1.x is EOL 2019?
Please clarify =)
postgresql postgresql-bdr postgres-bdr
1
We have @CraigRinger here on SO from 2nd Quadrant who also worked on BDR. but he's been inactive for some time.
– Kamil Gosciminski
Aug 17 '18 at 10:16
@KamilGosciminski Yeah, busy with dev work etc, but I try to keep vaguely in touch.
– Craig Ringer
Nov 13 '18 at 1:31
add a comment |
I am confused regarding PostgreSQL BDR and I have several questions:
Question 1: Is BDR truly multi-master for PostgreSQL?
According to the docs here, it says that:
The BDR (Bi-Directional Replication) project adds multi-master
replication to PostgreSQL 9.4
but if I read on 2ndQuadrant, I read the following:
If I read that part, they dont mention multi-master much at all; just that a "second master, working in passive", which indicates its not a real master?
Question 2: Is BDR open-source?
I read here that it is, at least that it was:
BDR is the first open source multi-master replication system for PostgreSQL
Is it still? Because when I look, I am often directed to 2ndQuadrants webpage, and that gives me the impression that its not open-source, when they say that:
How can you get Postgres-BDR?
Just fill out the contact form below and a PostgreSQL expert will be in touch shortly!
Sounds like selling to me =)
Question 3: What version is what?
I read that 2ndQuadrant released version 1.0.5 in March this year. I also read on 2ndQuadrants webpage that
In the complex environment of replication, the 3rd generation of BDR achieves...
The 3rd gen? Is version 1.0.5 that same 3rd gen, or is it something else?
Also, the same page says that:
Note for current Postgres-BDR users: BDR 1.x will reach EOL in December 2019. Our team of PostgreSQL experts can help plan and execute your upgrade with minimal impact and almost zero downtime. Contact us today and a member of our professional services team will be in touch with you as soon as possible.
So, 1.0.5 was released in March, but has EOL in December 2019? Is 2.x not open-source, so some licens cost associated with it, and 1.x is EOL 2019?
Please clarify =)
postgresql postgresql-bdr postgres-bdr
I am confused regarding PostgreSQL BDR and I have several questions:
Question 1: Is BDR truly multi-master for PostgreSQL?
According to the docs here, it says that:
The BDR (Bi-Directional Replication) project adds multi-master
replication to PostgreSQL 9.4
but if I read on 2ndQuadrant, I read the following:
If I read that part, they dont mention multi-master much at all; just that a "second master, working in passive", which indicates its not a real master?
Question 2: Is BDR open-source?
I read here that it is, at least that it was:
BDR is the first open source multi-master replication system for PostgreSQL
Is it still? Because when I look, I am often directed to 2ndQuadrants webpage, and that gives me the impression that its not open-source, when they say that:
How can you get Postgres-BDR?
Just fill out the contact form below and a PostgreSQL expert will be in touch shortly!
Sounds like selling to me =)
Question 3: What version is what?
I read that 2ndQuadrant released version 1.0.5 in March this year. I also read on 2ndQuadrants webpage that
In the complex environment of replication, the 3rd generation of BDR achieves...
The 3rd gen? Is version 1.0.5 that same 3rd gen, or is it something else?
Also, the same page says that:
Note for current Postgres-BDR users: BDR 1.x will reach EOL in December 2019. Our team of PostgreSQL experts can help plan and execute your upgrade with minimal impact and almost zero downtime. Contact us today and a member of our professional services team will be in touch with you as soon as possible.
So, 1.0.5 was released in March, but has EOL in December 2019? Is 2.x not open-source, so some licens cost associated with it, and 1.x is EOL 2019?
Please clarify =)
postgresql postgresql-bdr postgres-bdr
postgresql postgresql-bdr postgres-bdr
asked Aug 17 '18 at 10:08
Ted
8,5223181126
8,5223181126
1
We have @CraigRinger here on SO from 2nd Quadrant who also worked on BDR. but he's been inactive for some time.
– Kamil Gosciminski
Aug 17 '18 at 10:16
@KamilGosciminski Yeah, busy with dev work etc, but I try to keep vaguely in touch.
– Craig Ringer
Nov 13 '18 at 1:31
add a comment |
1
We have @CraigRinger here on SO from 2nd Quadrant who also worked on BDR. but he's been inactive for some time.
– Kamil Gosciminski
Aug 17 '18 at 10:16
@KamilGosciminski Yeah, busy with dev work etc, but I try to keep vaguely in touch.
– Craig Ringer
Nov 13 '18 at 1:31
1
1
We have @CraigRinger here on SO from 2nd Quadrant who also worked on BDR. but he's been inactive for some time.
– Kamil Gosciminski
Aug 17 '18 at 10:16
We have @CraigRinger here on SO from 2nd Quadrant who also worked on BDR. but he's been inactive for some time.
– Kamil Gosciminski
Aug 17 '18 at 10:16
@KamilGosciminski Yeah, busy with dev work etc, but I try to keep vaguely in touch.
– Craig Ringer
Nov 13 '18 at 1:31
@KamilGosciminski Yeah, busy with dev work etc, but I try to keep vaguely in touch.
– Craig Ringer
Nov 13 '18 at 1:31
add a comment |
2 Answers
2
active
oldest
votes
I received an answer from 2ndQuadrant via email, so I will post it here as it addresses the questions above:
1- "BDR is truly master-master; the shadow master is still a master.
BDR is an eventually consistent multi master solution; in eventually
consistent multi master cluster, it is possible to write on more than
one master at the same time, and conflicts might arise when the same
rows are written at the same time. Conflicts might be acceptable or
not depending on the logical model of the application. Some people do
not need to write on both nodes at the same time, and will use BDR
only to achieve faster failover, as in our BDR-AlwaysOn architecture.
Other people need to write on both nodes, and in that case we need to
assess impact and likeliness of conflicts."
2- BDR 1.x is open source (http://bdr-project.org/docs/stable/) .
Later versions including BDR3 is only available to 2ndQuadrant
Production Support customers. Happy to talk about that in more detail.
You are right, it does sound like selling, we are a business :)
3- The latest version is BDR3, this is the third generation of BDR. It
will still be live, but is only available to Support Customers.
1.x is open source, but EOL as you mentioned.
I have asked follow-up questions regarding "eventual constistency" and what differences there are between BDR 1.x and BDR 3 =)
– Ted
Aug 24 '18 at 10:51
add a comment |
BDR1 is open source. BDR2 is not. BDR3 is not yet, but should become so at some later stage.
BDR is truly multi-master. The "AlwaysOn Architecture" is a simplified model for BDR deployments that uses active/standby with fast-failover, designed to retain better compatibility with existing applications while improving HA and robustness.
So BDR can and often is deployed in fully multi-master roles, the AlwaysOn architecture just doesn't use it that way.
The BDR 1.x series for PostgreSQL 9.4 (+BDR patches) is open source. It will go EoL in December 2019. It works fine, but I don't recommend it for new deployments given the planned EoL.
The BDR 2.x series (for PostgreSQL 9.6) is not open source and is only available for 2ndQuadrant customers. However, parts of it have been submitted to PostgreSQL itself. It has been superseded by BDR 3.x.
The BDR 3.x series, which is now entering production, is not currently open source and is available only to 2ndQuadrant customers. My understanding is that it's intended for eventual open source release, but no date has been set, and I cannot speak officially for 2ndQuadrant about this. BDR3 adds a much more robust node communication model, better conflict handling, and a lot more, plus it runs on PostgreSQL 10 and 11.
I have been encouraging the relevant people to provide some updated official guidance on these matters. The latest I have for you right now is "News and Roadmap for BDR (Multi-master PostgreSQL)" on the 2ndQuadrant blog.
Thanks for the update. My main problem is this "BDR is an eventually consistent multi master solution; in eventually consistent multi master cluster, it is possible to write on more than one master at the same time, and conflicts might arise when the same rows are written at the same time". That doesnt sound like its usable in some cases. The point with MM is that different instances can operate on any node, and no conflicts arises, like Galera for MySQL... Otherwise, how does one dare use it?
– Ted
Nov 19 '18 at 2:30
@Ted Galera is subject to conflicts and anomalies. Read the manual more closely. The PACELC theorem (a more useful formulation than CAP) is rather clear on this. You get availability or consistency, pick one. Vendors use all sorts of wording and tricks to get around this, but physics and the speed of light is pretty adamant about it. Different systems have different compromises and tradeoffs, yes, and some have ways to switch modes, but fundamentall your app must tolerate conflicts, or it cannot remain write-available when nodes are down.
– Craig Ringer
Nov 19 '18 at 5:06
@Ted See my talk here: blog.2ndquadrant.com/… . The presentation was a bit stilted due to some personal stuff going on, but the content should be pretty clear. There are PDF slides available too.
– Craig Ringer
Nov 19 '18 at 5:07
Well, we have used Galera for some 5+ years I think. We write randomly to 3+ nodes in a cluster, never seen any conflicts or anomalies.
– Ted
Nov 19 '18 at 8:36
@Ted galeracluster.com/documentation-webpages/isolationlevels.html . You can get phantom reads amongst other things. If you haven't had any conflicts or (known) anomalies, your app likely takes care to operate safely. Galrea is definitely easier to use safely, at the cost of reduced performance and availability. Try this: take two Galrea nodes, isolate them from the network. Now try to point your workload at each. What happens? You've hit an availability limit imposed by the consistency guarantees. Each system makes different tradeoffs.
– Craig Ringer
Nov 19 '18 at 14:17
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f51893065%2fpostgresql-bdr-is-bdr-truly-multi-master-is-it-open-source-and-eol-for-1-x-i%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
I received an answer from 2ndQuadrant via email, so I will post it here as it addresses the questions above:
1- "BDR is truly master-master; the shadow master is still a master.
BDR is an eventually consistent multi master solution; in eventually
consistent multi master cluster, it is possible to write on more than
one master at the same time, and conflicts might arise when the same
rows are written at the same time. Conflicts might be acceptable or
not depending on the logical model of the application. Some people do
not need to write on both nodes at the same time, and will use BDR
only to achieve faster failover, as in our BDR-AlwaysOn architecture.
Other people need to write on both nodes, and in that case we need to
assess impact and likeliness of conflicts."
2- BDR 1.x is open source (http://bdr-project.org/docs/stable/) .
Later versions including BDR3 is only available to 2ndQuadrant
Production Support customers. Happy to talk about that in more detail.
You are right, it does sound like selling, we are a business :)
3- The latest version is BDR3, this is the third generation of BDR. It
will still be live, but is only available to Support Customers.
1.x is open source, but EOL as you mentioned.
I have asked follow-up questions regarding "eventual constistency" and what differences there are between BDR 1.x and BDR 3 =)
– Ted
Aug 24 '18 at 10:51
add a comment |
I received an answer from 2ndQuadrant via email, so I will post it here as it addresses the questions above:
1- "BDR is truly master-master; the shadow master is still a master.
BDR is an eventually consistent multi master solution; in eventually
consistent multi master cluster, it is possible to write on more than
one master at the same time, and conflicts might arise when the same
rows are written at the same time. Conflicts might be acceptable or
not depending on the logical model of the application. Some people do
not need to write on both nodes at the same time, and will use BDR
only to achieve faster failover, as in our BDR-AlwaysOn architecture.
Other people need to write on both nodes, and in that case we need to
assess impact and likeliness of conflicts."
2- BDR 1.x is open source (http://bdr-project.org/docs/stable/) .
Later versions including BDR3 is only available to 2ndQuadrant
Production Support customers. Happy to talk about that in more detail.
You are right, it does sound like selling, we are a business :)
3- The latest version is BDR3, this is the third generation of BDR. It
will still be live, but is only available to Support Customers.
1.x is open source, but EOL as you mentioned.
I have asked follow-up questions regarding "eventual constistency" and what differences there are between BDR 1.x and BDR 3 =)
– Ted
Aug 24 '18 at 10:51
add a comment |
I received an answer from 2ndQuadrant via email, so I will post it here as it addresses the questions above:
1- "BDR is truly master-master; the shadow master is still a master.
BDR is an eventually consistent multi master solution; in eventually
consistent multi master cluster, it is possible to write on more than
one master at the same time, and conflicts might arise when the same
rows are written at the same time. Conflicts might be acceptable or
not depending on the logical model of the application. Some people do
not need to write on both nodes at the same time, and will use BDR
only to achieve faster failover, as in our BDR-AlwaysOn architecture.
Other people need to write on both nodes, and in that case we need to
assess impact and likeliness of conflicts."
2- BDR 1.x is open source (http://bdr-project.org/docs/stable/) .
Later versions including BDR3 is only available to 2ndQuadrant
Production Support customers. Happy to talk about that in more detail.
You are right, it does sound like selling, we are a business :)
3- The latest version is BDR3, this is the third generation of BDR. It
will still be live, but is only available to Support Customers.
1.x is open source, but EOL as you mentioned.
I received an answer from 2ndQuadrant via email, so I will post it here as it addresses the questions above:
1- "BDR is truly master-master; the shadow master is still a master.
BDR is an eventually consistent multi master solution; in eventually
consistent multi master cluster, it is possible to write on more than
one master at the same time, and conflicts might arise when the same
rows are written at the same time. Conflicts might be acceptable or
not depending on the logical model of the application. Some people do
not need to write on both nodes at the same time, and will use BDR
only to achieve faster failover, as in our BDR-AlwaysOn architecture.
Other people need to write on both nodes, and in that case we need to
assess impact and likeliness of conflicts."
2- BDR 1.x is open source (http://bdr-project.org/docs/stable/) .
Later versions including BDR3 is only available to 2ndQuadrant
Production Support customers. Happy to talk about that in more detail.
You are right, it does sound like selling, we are a business :)
3- The latest version is BDR3, this is the third generation of BDR. It
will still be live, but is only available to Support Customers.
1.x is open source, but EOL as you mentioned.
answered Aug 24 '18 at 10:50
Ted
8,5223181126
8,5223181126
I have asked follow-up questions regarding "eventual constistency" and what differences there are between BDR 1.x and BDR 3 =)
– Ted
Aug 24 '18 at 10:51
add a comment |
I have asked follow-up questions regarding "eventual constistency" and what differences there are between BDR 1.x and BDR 3 =)
– Ted
Aug 24 '18 at 10:51
I have asked follow-up questions regarding "eventual constistency" and what differences there are between BDR 1.x and BDR 3 =)
– Ted
Aug 24 '18 at 10:51
I have asked follow-up questions regarding "eventual constistency" and what differences there are between BDR 1.x and BDR 3 =)
– Ted
Aug 24 '18 at 10:51
add a comment |
BDR1 is open source. BDR2 is not. BDR3 is not yet, but should become so at some later stage.
BDR is truly multi-master. The "AlwaysOn Architecture" is a simplified model for BDR deployments that uses active/standby with fast-failover, designed to retain better compatibility with existing applications while improving HA and robustness.
So BDR can and often is deployed in fully multi-master roles, the AlwaysOn architecture just doesn't use it that way.
The BDR 1.x series for PostgreSQL 9.4 (+BDR patches) is open source. It will go EoL in December 2019. It works fine, but I don't recommend it for new deployments given the planned EoL.
The BDR 2.x series (for PostgreSQL 9.6) is not open source and is only available for 2ndQuadrant customers. However, parts of it have been submitted to PostgreSQL itself. It has been superseded by BDR 3.x.
The BDR 3.x series, which is now entering production, is not currently open source and is available only to 2ndQuadrant customers. My understanding is that it's intended for eventual open source release, but no date has been set, and I cannot speak officially for 2ndQuadrant about this. BDR3 adds a much more robust node communication model, better conflict handling, and a lot more, plus it runs on PostgreSQL 10 and 11.
I have been encouraging the relevant people to provide some updated official guidance on these matters. The latest I have for you right now is "News and Roadmap for BDR (Multi-master PostgreSQL)" on the 2ndQuadrant blog.
Thanks for the update. My main problem is this "BDR is an eventually consistent multi master solution; in eventually consistent multi master cluster, it is possible to write on more than one master at the same time, and conflicts might arise when the same rows are written at the same time". That doesnt sound like its usable in some cases. The point with MM is that different instances can operate on any node, and no conflicts arises, like Galera for MySQL... Otherwise, how does one dare use it?
– Ted
Nov 19 '18 at 2:30
@Ted Galera is subject to conflicts and anomalies. Read the manual more closely. The PACELC theorem (a more useful formulation than CAP) is rather clear on this. You get availability or consistency, pick one. Vendors use all sorts of wording and tricks to get around this, but physics and the speed of light is pretty adamant about it. Different systems have different compromises and tradeoffs, yes, and some have ways to switch modes, but fundamentall your app must tolerate conflicts, or it cannot remain write-available when nodes are down.
– Craig Ringer
Nov 19 '18 at 5:06
@Ted See my talk here: blog.2ndquadrant.com/… . The presentation was a bit stilted due to some personal stuff going on, but the content should be pretty clear. There are PDF slides available too.
– Craig Ringer
Nov 19 '18 at 5:07
Well, we have used Galera for some 5+ years I think. We write randomly to 3+ nodes in a cluster, never seen any conflicts or anomalies.
– Ted
Nov 19 '18 at 8:36
@Ted galeracluster.com/documentation-webpages/isolationlevels.html . You can get phantom reads amongst other things. If you haven't had any conflicts or (known) anomalies, your app likely takes care to operate safely. Galrea is definitely easier to use safely, at the cost of reduced performance and availability. Try this: take two Galrea nodes, isolate them from the network. Now try to point your workload at each. What happens? You've hit an availability limit imposed by the consistency guarantees. Each system makes different tradeoffs.
– Craig Ringer
Nov 19 '18 at 14:17
add a comment |
BDR1 is open source. BDR2 is not. BDR3 is not yet, but should become so at some later stage.
BDR is truly multi-master. The "AlwaysOn Architecture" is a simplified model for BDR deployments that uses active/standby with fast-failover, designed to retain better compatibility with existing applications while improving HA and robustness.
So BDR can and often is deployed in fully multi-master roles, the AlwaysOn architecture just doesn't use it that way.
The BDR 1.x series for PostgreSQL 9.4 (+BDR patches) is open source. It will go EoL in December 2019. It works fine, but I don't recommend it for new deployments given the planned EoL.
The BDR 2.x series (for PostgreSQL 9.6) is not open source and is only available for 2ndQuadrant customers. However, parts of it have been submitted to PostgreSQL itself. It has been superseded by BDR 3.x.
The BDR 3.x series, which is now entering production, is not currently open source and is available only to 2ndQuadrant customers. My understanding is that it's intended for eventual open source release, but no date has been set, and I cannot speak officially for 2ndQuadrant about this. BDR3 adds a much more robust node communication model, better conflict handling, and a lot more, plus it runs on PostgreSQL 10 and 11.
I have been encouraging the relevant people to provide some updated official guidance on these matters. The latest I have for you right now is "News and Roadmap for BDR (Multi-master PostgreSQL)" on the 2ndQuadrant blog.
Thanks for the update. My main problem is this "BDR is an eventually consistent multi master solution; in eventually consistent multi master cluster, it is possible to write on more than one master at the same time, and conflicts might arise when the same rows are written at the same time". That doesnt sound like its usable in some cases. The point with MM is that different instances can operate on any node, and no conflicts arises, like Galera for MySQL... Otherwise, how does one dare use it?
– Ted
Nov 19 '18 at 2:30
@Ted Galera is subject to conflicts and anomalies. Read the manual more closely. The PACELC theorem (a more useful formulation than CAP) is rather clear on this. You get availability or consistency, pick one. Vendors use all sorts of wording and tricks to get around this, but physics and the speed of light is pretty adamant about it. Different systems have different compromises and tradeoffs, yes, and some have ways to switch modes, but fundamentall your app must tolerate conflicts, or it cannot remain write-available when nodes are down.
– Craig Ringer
Nov 19 '18 at 5:06
@Ted See my talk here: blog.2ndquadrant.com/… . The presentation was a bit stilted due to some personal stuff going on, but the content should be pretty clear. There are PDF slides available too.
– Craig Ringer
Nov 19 '18 at 5:07
Well, we have used Galera for some 5+ years I think. We write randomly to 3+ nodes in a cluster, never seen any conflicts or anomalies.
– Ted
Nov 19 '18 at 8:36
@Ted galeracluster.com/documentation-webpages/isolationlevels.html . You can get phantom reads amongst other things. If you haven't had any conflicts or (known) anomalies, your app likely takes care to operate safely. Galrea is definitely easier to use safely, at the cost of reduced performance and availability. Try this: take two Galrea nodes, isolate them from the network. Now try to point your workload at each. What happens? You've hit an availability limit imposed by the consistency guarantees. Each system makes different tradeoffs.
– Craig Ringer
Nov 19 '18 at 14:17
add a comment |
BDR1 is open source. BDR2 is not. BDR3 is not yet, but should become so at some later stage.
BDR is truly multi-master. The "AlwaysOn Architecture" is a simplified model for BDR deployments that uses active/standby with fast-failover, designed to retain better compatibility with existing applications while improving HA and robustness.
So BDR can and often is deployed in fully multi-master roles, the AlwaysOn architecture just doesn't use it that way.
The BDR 1.x series for PostgreSQL 9.4 (+BDR patches) is open source. It will go EoL in December 2019. It works fine, but I don't recommend it for new deployments given the planned EoL.
The BDR 2.x series (for PostgreSQL 9.6) is not open source and is only available for 2ndQuadrant customers. However, parts of it have been submitted to PostgreSQL itself. It has been superseded by BDR 3.x.
The BDR 3.x series, which is now entering production, is not currently open source and is available only to 2ndQuadrant customers. My understanding is that it's intended for eventual open source release, but no date has been set, and I cannot speak officially for 2ndQuadrant about this. BDR3 adds a much more robust node communication model, better conflict handling, and a lot more, plus it runs on PostgreSQL 10 and 11.
I have been encouraging the relevant people to provide some updated official guidance on these matters. The latest I have for you right now is "News and Roadmap for BDR (Multi-master PostgreSQL)" on the 2ndQuadrant blog.
BDR1 is open source. BDR2 is not. BDR3 is not yet, but should become so at some later stage.
BDR is truly multi-master. The "AlwaysOn Architecture" is a simplified model for BDR deployments that uses active/standby with fast-failover, designed to retain better compatibility with existing applications while improving HA and robustness.
So BDR can and often is deployed in fully multi-master roles, the AlwaysOn architecture just doesn't use it that way.
The BDR 1.x series for PostgreSQL 9.4 (+BDR patches) is open source. It will go EoL in December 2019. It works fine, but I don't recommend it for new deployments given the planned EoL.
The BDR 2.x series (for PostgreSQL 9.6) is not open source and is only available for 2ndQuadrant customers. However, parts of it have been submitted to PostgreSQL itself. It has been superseded by BDR 3.x.
The BDR 3.x series, which is now entering production, is not currently open source and is available only to 2ndQuadrant customers. My understanding is that it's intended for eventual open source release, but no date has been set, and I cannot speak officially for 2ndQuadrant about this. BDR3 adds a much more robust node communication model, better conflict handling, and a lot more, plus it runs on PostgreSQL 10 and 11.
I have been encouraging the relevant people to provide some updated official guidance on these matters. The latest I have for you right now is "News and Roadmap for BDR (Multi-master PostgreSQL)" on the 2ndQuadrant blog.
answered Nov 13 '18 at 1:41
Craig Ringer
192k33388516
192k33388516
Thanks for the update. My main problem is this "BDR is an eventually consistent multi master solution; in eventually consistent multi master cluster, it is possible to write on more than one master at the same time, and conflicts might arise when the same rows are written at the same time". That doesnt sound like its usable in some cases. The point with MM is that different instances can operate on any node, and no conflicts arises, like Galera for MySQL... Otherwise, how does one dare use it?
– Ted
Nov 19 '18 at 2:30
@Ted Galera is subject to conflicts and anomalies. Read the manual more closely. The PACELC theorem (a more useful formulation than CAP) is rather clear on this. You get availability or consistency, pick one. Vendors use all sorts of wording and tricks to get around this, but physics and the speed of light is pretty adamant about it. Different systems have different compromises and tradeoffs, yes, and some have ways to switch modes, but fundamentall your app must tolerate conflicts, or it cannot remain write-available when nodes are down.
– Craig Ringer
Nov 19 '18 at 5:06
@Ted See my talk here: blog.2ndquadrant.com/… . The presentation was a bit stilted due to some personal stuff going on, but the content should be pretty clear. There are PDF slides available too.
– Craig Ringer
Nov 19 '18 at 5:07
Well, we have used Galera for some 5+ years I think. We write randomly to 3+ nodes in a cluster, never seen any conflicts or anomalies.
– Ted
Nov 19 '18 at 8:36
@Ted galeracluster.com/documentation-webpages/isolationlevels.html . You can get phantom reads amongst other things. If you haven't had any conflicts or (known) anomalies, your app likely takes care to operate safely. Galrea is definitely easier to use safely, at the cost of reduced performance and availability. Try this: take two Galrea nodes, isolate them from the network. Now try to point your workload at each. What happens? You've hit an availability limit imposed by the consistency guarantees. Each system makes different tradeoffs.
– Craig Ringer
Nov 19 '18 at 14:17
add a comment |
Thanks for the update. My main problem is this "BDR is an eventually consistent multi master solution; in eventually consistent multi master cluster, it is possible to write on more than one master at the same time, and conflicts might arise when the same rows are written at the same time". That doesnt sound like its usable in some cases. The point with MM is that different instances can operate on any node, and no conflicts arises, like Galera for MySQL... Otherwise, how does one dare use it?
– Ted
Nov 19 '18 at 2:30
@Ted Galera is subject to conflicts and anomalies. Read the manual more closely. The PACELC theorem (a more useful formulation than CAP) is rather clear on this. You get availability or consistency, pick one. Vendors use all sorts of wording and tricks to get around this, but physics and the speed of light is pretty adamant about it. Different systems have different compromises and tradeoffs, yes, and some have ways to switch modes, but fundamentall your app must tolerate conflicts, or it cannot remain write-available when nodes are down.
– Craig Ringer
Nov 19 '18 at 5:06
@Ted See my talk here: blog.2ndquadrant.com/… . The presentation was a bit stilted due to some personal stuff going on, but the content should be pretty clear. There are PDF slides available too.
– Craig Ringer
Nov 19 '18 at 5:07
Well, we have used Galera for some 5+ years I think. We write randomly to 3+ nodes in a cluster, never seen any conflicts or anomalies.
– Ted
Nov 19 '18 at 8:36
@Ted galeracluster.com/documentation-webpages/isolationlevels.html . You can get phantom reads amongst other things. If you haven't had any conflicts or (known) anomalies, your app likely takes care to operate safely. Galrea is definitely easier to use safely, at the cost of reduced performance and availability. Try this: take two Galrea nodes, isolate them from the network. Now try to point your workload at each. What happens? You've hit an availability limit imposed by the consistency guarantees. Each system makes different tradeoffs.
– Craig Ringer
Nov 19 '18 at 14:17
Thanks for the update. My main problem is this "BDR is an eventually consistent multi master solution; in eventually consistent multi master cluster, it is possible to write on more than one master at the same time, and conflicts might arise when the same rows are written at the same time". That doesnt sound like its usable in some cases. The point with MM is that different instances can operate on any node, and no conflicts arises, like Galera for MySQL... Otherwise, how does one dare use it?
– Ted
Nov 19 '18 at 2:30
Thanks for the update. My main problem is this "BDR is an eventually consistent multi master solution; in eventually consistent multi master cluster, it is possible to write on more than one master at the same time, and conflicts might arise when the same rows are written at the same time". That doesnt sound like its usable in some cases. The point with MM is that different instances can operate on any node, and no conflicts arises, like Galera for MySQL... Otherwise, how does one dare use it?
– Ted
Nov 19 '18 at 2:30
@Ted Galera is subject to conflicts and anomalies. Read the manual more closely. The PACELC theorem (a more useful formulation than CAP) is rather clear on this. You get availability or consistency, pick one. Vendors use all sorts of wording and tricks to get around this, but physics and the speed of light is pretty adamant about it. Different systems have different compromises and tradeoffs, yes, and some have ways to switch modes, but fundamentall your app must tolerate conflicts, or it cannot remain write-available when nodes are down.
– Craig Ringer
Nov 19 '18 at 5:06
@Ted Galera is subject to conflicts and anomalies. Read the manual more closely. The PACELC theorem (a more useful formulation than CAP) is rather clear on this. You get availability or consistency, pick one. Vendors use all sorts of wording and tricks to get around this, but physics and the speed of light is pretty adamant about it. Different systems have different compromises and tradeoffs, yes, and some have ways to switch modes, but fundamentall your app must tolerate conflicts, or it cannot remain write-available when nodes are down.
– Craig Ringer
Nov 19 '18 at 5:06
@Ted See my talk here: blog.2ndquadrant.com/… . The presentation was a bit stilted due to some personal stuff going on, but the content should be pretty clear. There are PDF slides available too.
– Craig Ringer
Nov 19 '18 at 5:07
@Ted See my talk here: blog.2ndquadrant.com/… . The presentation was a bit stilted due to some personal stuff going on, but the content should be pretty clear. There are PDF slides available too.
– Craig Ringer
Nov 19 '18 at 5:07
Well, we have used Galera for some 5+ years I think. We write randomly to 3+ nodes in a cluster, never seen any conflicts or anomalies.
– Ted
Nov 19 '18 at 8:36
Well, we have used Galera for some 5+ years I think. We write randomly to 3+ nodes in a cluster, never seen any conflicts or anomalies.
– Ted
Nov 19 '18 at 8:36
@Ted galeracluster.com/documentation-webpages/isolationlevels.html . You can get phantom reads amongst other things. If you haven't had any conflicts or (known) anomalies, your app likely takes care to operate safely. Galrea is definitely easier to use safely, at the cost of reduced performance and availability. Try this: take two Galrea nodes, isolate them from the network. Now try to point your workload at each. What happens? You've hit an availability limit imposed by the consistency guarantees. Each system makes different tradeoffs.
– Craig Ringer
Nov 19 '18 at 14:17
@Ted galeracluster.com/documentation-webpages/isolationlevels.html . You can get phantom reads amongst other things. If you haven't had any conflicts or (known) anomalies, your app likely takes care to operate safely. Galrea is definitely easier to use safely, at the cost of reduced performance and availability. Try this: take two Galrea nodes, isolate them from the network. Now try to point your workload at each. What happens? You've hit an availability limit imposed by the consistency guarantees. Each system makes different tradeoffs.
– Craig Ringer
Nov 19 '18 at 14:17
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f51893065%2fpostgresql-bdr-is-bdr-truly-multi-master-is-it-open-source-and-eol-for-1-x-i%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
We have @CraigRinger here on SO from 2nd Quadrant who also worked on BDR. but he's been inactive for some time.
– Kamil Gosciminski
Aug 17 '18 at 10:16
@KamilGosciminski Yeah, busy with dev work etc, but I try to keep vaguely in touch.
– Craig Ringer
Nov 13 '18 at 1:31