PostgreSQL & BDR: Is BDR truly multi-master, is it Open Source and EOL for 1.x in 2019?












3














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:



enter image description here



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 =)










share|improve this question


















  • 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
















3














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:



enter image description here



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 =)










share|improve this question


















  • 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














3












3








3







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:



enter image description here



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 =)










share|improve this question













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:



enter image description here



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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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














  • 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












2 Answers
2






active

oldest

votes


















2














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.







share|improve this answer





















  • 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



















1














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.






share|improve this answer





















  • 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











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
});


}
});














draft saved

draft discarded


















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









2














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.







share|improve this answer





















  • 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
















2














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.







share|improve this answer





















  • 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














2












2








2






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.







share|improve this answer












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.








share|improve this answer












share|improve this answer



share|improve this answer










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


















  • 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













1














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.






share|improve this answer





















  • 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
















1














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.






share|improve this answer





















  • 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














1












1








1






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.






share|improve this answer












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.







share|improve this answer












share|improve this answer



share|improve this answer










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


















  • 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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Xamarin.iOS Cant Deploy on Iphone

Glorious Revolution

Dulmage-Mendelsohn matrix decomposition in Python