<story><title>Bidirectional Replication is coming to PostgreSQL 9.6</title><url>http://blog.2ndquadrant.com/bdr-is-coming-to-postgresql-9-6/</url></story><parent_chain><item><author>ukj</author><text>Holy crap, I am scared!&lt;p&gt;Please, please, please read the fine print and ensure you understand the design tradeoffs as well as your application&amp;#x27;s requirements before blindly using this.&lt;p&gt;The moment I heard multi-master I thought Paxos, Raft or maybe virtual synchrony. Hmm, nothing in the documentation. Maybe a new consensus protocol was written from scratch then? That should be interesting!&lt;p&gt;No, none of that either - this implementation completely disregards consistency and makes write conflicts the developer&amp;#x27;s problem.&lt;p&gt;From &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;bdr-project.org&amp;#x2F;docs&amp;#x2F;stable&amp;#x2F;weak-coupled-multimaster.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;bdr-project.org&amp;#x2F;docs&amp;#x2F;stable&amp;#x2F;weak-coupled-multimaster....&lt;/a&gt;&lt;p&gt;* Applications using BDR are free to write to any node so long as they are careful to prevent or cope with conflicts&lt;p&gt;* There is no complex election of a new master if a node goes down or network problems arise. There is no wait for failover. Each node is always a master and always directly writeable.&lt;p&gt;* Applications can be partition-tolerant: the application can keep keep working even if it loses communication with some or all other nodes, then re-sync automatically when connectivity is restored. Loss of a critical VPN tunnel or WAN won&amp;#x27;t bring the entire store or satellite office to a halt.&lt;p&gt;Basically:&lt;p&gt;* Transactions are a lie&lt;p&gt;* Consistent reads are a lie&lt;p&gt;* Datasets will diverge during network partitioning&lt;p&gt;* Convergence is not guaranteed without a mechanism for resolving write conflicts&lt;p&gt;I am sure there are use-cases where the risk of this design is acceptable (or necessary), but ensure you have a plan for dealing with data inconsistencies!</text></item></parent_chain><comment><author>simon2Q</author><text>&amp;quot;Everything after &amp;quot;Basically&amp;quot; is misleading and inaccurate.&lt;p&gt;The conclusions here are not logical: The existence of some restrictions does not imply &amp;quot;Transactions are a lie&amp;quot;, since that makes us think ALL transaction semantics are suspended, which is very far from the case.&lt;p&gt;There are good reasons for the design and restrictions in the BDR design, offering performance about x100 what is possible with eager consensus. Real world pragmatism, with production tools to ensure no inconsistencies exist in the database. The BDR tools allow you to trap and handle run-time issues, so it is not a theoretical debate or a mysterious issue, just a practical task for application authors to check their apps work.&lt;p&gt;&amp;quot;Consistent reads are a lie&amp;quot;. Reads from multiple nodes at the same time are not guaranteed to be consistent - but this is multi-master - why would you read two nodes when all the data is on one node? The whole point is to put the data you need near the users who need it, so this is designed to avoid multiple node reads.&lt;p&gt;I could go on, and will do in a longer post elsewhere, but the main purpose of my retort is to show that the conclusions drawn here are not valid. Let&amp;#x27;s see how the hacker news method of consensus decides what is correct in this case.</text></comment>
<story><title>Bidirectional Replication is coming to PostgreSQL 9.6</title><url>http://blog.2ndquadrant.com/bdr-is-coming-to-postgresql-9-6/</url></story><parent_chain><item><author>ukj</author><text>Holy crap, I am scared!&lt;p&gt;Please, please, please read the fine print and ensure you understand the design tradeoffs as well as your application&amp;#x27;s requirements before blindly using this.&lt;p&gt;The moment I heard multi-master I thought Paxos, Raft or maybe virtual synchrony. Hmm, nothing in the documentation. Maybe a new consensus protocol was written from scratch then? That should be interesting!&lt;p&gt;No, none of that either - this implementation completely disregards consistency and makes write conflicts the developer&amp;#x27;s problem.&lt;p&gt;From &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;bdr-project.org&amp;#x2F;docs&amp;#x2F;stable&amp;#x2F;weak-coupled-multimaster.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;bdr-project.org&amp;#x2F;docs&amp;#x2F;stable&amp;#x2F;weak-coupled-multimaster....&lt;/a&gt;&lt;p&gt;* Applications using BDR are free to write to any node so long as they are careful to prevent or cope with conflicts&lt;p&gt;* There is no complex election of a new master if a node goes down or network problems arise. There is no wait for failover. Each node is always a master and always directly writeable.&lt;p&gt;* Applications can be partition-tolerant: the application can keep keep working even if it loses communication with some or all other nodes, then re-sync automatically when connectivity is restored. Loss of a critical VPN tunnel or WAN won&amp;#x27;t bring the entire store or satellite office to a halt.&lt;p&gt;Basically:&lt;p&gt;* Transactions are a lie&lt;p&gt;* Consistent reads are a lie&lt;p&gt;* Datasets will diverge during network partitioning&lt;p&gt;* Convergence is not guaranteed without a mechanism for resolving write conflicts&lt;p&gt;I am sure there are use-cases where the risk of this design is acceptable (or necessary), but ensure you have a plan for dealing with data inconsistencies!</text></item></parent_chain><comment><author>jimktrains2</author><text>&amp;gt; I am sure there are use-cases where the risk of this design is acceptable (or necessary), but ensure you have a plan for dealing with data inconsistencies!&lt;p&gt;I&amp;#x27;d argue most non-financing applications would find these risks acceptable. This form of Multi-Master is what most people writing web-based applications actually are looking for.  It simplifies having fail-over, at the costs you mentioned, but those aren&amp;#x27;t a major issues, especially if they&amp;#x27;re known upfront.&lt;p&gt;&amp;gt; * Datasets will diverge during network partitioning&lt;p&gt;&amp;gt; * Convergence is not guaranteed without a mechanism for resolving write conflicts&lt;p&gt;While this isn&amp;#x27;t ideal in a perfect world, it&amp;#x27;s workable for, again, web-based applications where consistency isn&amp;#x27;t usually required. Also, the rules are known &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;bdr-project.org&amp;#x2F;docs&amp;#x2F;stable&amp;#x2F;conflicts-types.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;bdr-project.org&amp;#x2F;docs&amp;#x2F;stable&amp;#x2F;conflicts-types.html&lt;/a&gt;&lt;p&gt;So yes, there are definitely workloads where this type of replication isn&amp;#x27;t appropriate, however, acting like there aren&amp;#x27;t any is blatantly ignoring many types of workloads.</text></comment>