Holy crap, I am scared!
Please, please, please read the fine print and ensure you understand the design tradeoffs as well as your application's requirements before blindly using this.
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!
No, none of that either - this implementation completely disregards consistency and makes write conflicts the developer's problem.
From http://bdr-project.org/docs/stable/weak-coupled-multimaster....
* Applications using BDR are free to write to any node so long as they are careful to prevent or cope with conflicts
* 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.
* 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't bring the entire store or satellite office to a halt.
Basically:
* Transactions are a lie
* Consistent reads are a lie
* Datasets will diverge during network partitioning
* Convergence is not guaranteed without a mechanism for resolving write conflicts
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!
Please, please, please read the fine print and ensure you understand the design tradeoffs as well as your application's requirements before blindly using this.
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!
No, none of that either - this implementation completely disregards consistency and makes write conflicts the developer's problem.
From http://bdr-project.org/docs/stable/weak-coupled-multimaster....
* Applications using BDR are free to write to any node so long as they are careful to prevent or cope with conflicts
* 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.
* 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't bring the entire store or satellite office to a halt.
Basically:
* Transactions are a lie
* Consistent reads are a lie
* Datasets will diverge during network partitioning
* Convergence is not guaranteed without a mechanism for resolving write conflicts
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!