Because BDR is asynchronous multi-master _replication_ though, clients
are expected to be aware of some of the anomalies that can occur. A
naïve client that just picked a random BDR server and did the next
transaction on it would be very likely to cause unwanted replication
anomalies, apply conflicts, etc.
For example, if the client inserted a row on one server then tried to
immediately update it on another, the update would likely fail because
the row probably hasn't replicated yet.
Any ideas giving BDR an option to be synchronous. I mean in ”close quarters” with low latency it should work ok.
Just to clarify, I don't mean a 48 node synchronous group, but perhaps allow one synchronous ”neighbor” node.
That way we could get two synch writeable nodes in one datacenter(or 2 datacenter really close to each other. common in Europe), and can be combined with asynch nodes in more distant datacenters. That would enable load balancing between 2 nodes for all type of queries.
Synchrounous Streaming Replication is supported with BDR, but that only gives support for a read-only replica. It does not give a fully writeable node. Figuring out what queries are readonly to direct to a readonly replica, is not the easiest thing, if I’ve understood documentation for pgpool etc correct.
It is generally a good idea to make clients "sticky" to a given server,
but clients also need to be aware of replication anomalies unless each
server's data is a self-contained shard that doesn't interact with the
others. In which case you probably wouldn't be using BDR
|
