>> >> I’ve seen some mailing list threads regarding this but was that ever implemented? Do you know where it’s documented? > > I don't think the patch ever got accompanying documentation. > > It's not mentioned here, anyway: > > http://jdbc.postgresql.org/documentation/93/connect.html > > Failover URLs are of the form: > > jdbc:postgresql://host1:port1,host2:port2/dbnjame > > with the port being optional. > > I'll document that now, before I get caught up in working on something else. > > In case you're looking, the code was added by git > bddc05f939ac9227b682e85d1ba0a9b902da814c . > Great! Will look have a look at the code. >> Any ideas giving BDR an option to be synchronous. I mean in ”close quarters” with low latency it should work ok. > > BDR doesn't do synchronous replication _yet_, but it's on the roadmap. > Right now BDR as a whole is in its early days; the feature is being > shaped by feedback and the requirements of sponsors and contributors. > It's changing quite quickly, which is one good reason most of it is > implemented as a plugin to PostgreSQL. Synchronous replication is one of > a number of things that the team has looked into but hasn't prioritized > implementing yet. > > Out of interest, what sorts of problems are you interested in solving > using BDR? What needs are you trying to meet? > > Are you looking to use it for scaling? For HA? For data > protection/redundancy? For transparent distributed databases > (client/node locality)? > > I'm curious about what part you see synchronous replication support for > BDR playing in any deployment you're contemplating. > One thing I’m thinking about a possible future replacement for other database vendors solutions. Solutions like DB2 DataSharing on z/OS and DB2 PureScale on Linux. They would be somewhat comparable to a synch multimaster setup, but of course only works in low latency environments. But they provide online upgrades. Perfromed one node at a time(only z/OS), and every node is equal. But they have central locking facilities, which creates other problems of course. But the applications would not need to care about if the transactions have been applied or not. The nodes are always in synch. Scaling is also something that has been on my mind for some apps that has intense write activity at times. BDR gives us that but currently we would need to watch out for potential situations where the data might not have been replicated to all nodes. Online scaling up and down a write intense environment without needing to worry if transactions have been applied or not, would be neat. But I know it would put constraints on the infrastructure, and possibly also not give us complete HA protection in case of a site failure, since the latency needs to be kept low. But if there could be a mix of synch and async nodes in a BDR group, it could cover more HA. Hope that explains a bit more what I’m thinking about. Currently I’m just looking at what BDR could give us here, so it’s nice to understand your plans. No real projects ongoing currently. Thanks for taking your time answering my questions. Best regards, Martin
