12 jul 2014 kl. 13:45 skrev Andres Freund <andres@xxxxxxxxxxxxxxx>: > On 2014-07-12 13:23:08 +0200, Martin Gudmundsson wrote: >> >> 12 jul 2014 kl. 12:33 skrev Andres Freund <andres@xxxxxxxxxxxxxxx>: >> >>> On 2014-07-12 18:22:30 +0800, Craig Ringer wrote: >>>> On 07/12/2014 02:24 PM, Martin Gudmundsson wrote: >>>>> 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. >>> >>> Just to clarify: There's two things that sometimes are referred to as >>> 'synchronous' in the context of multimaster replication. >>> >>> Just like with HS' builtin synchronous replication it can mean that the >>> client doesn't get a reply until the COMMIT has safely been replicated >>> to other systems. That's supported by BDR today. >> >> Would that be to a streaming replication synchronous standby? I.e replicated to a read only node? > > It's possible to do it to a streaming replication sync standby, but also > to another BDR node. The logical decoding facility added in 9.4 allows > logical replication solutions to use the same mechanism as streaming rep > does. > Sounds interesting, but it does not sound like it’s being bi-directional in that case? Is it just a standard streaming synchronous replication you setup for that? Ideally I’m looking for a solution where I can run an application and it does not really matter on what node a transaction executes, or if it changes data or not. With BDR in it’s current state, I need to look out for replication lag. That is what I was looking for a solution to when I mentioned synchronous bdr in the beginning. Don’t get me wrong, BDR can solve a lot of problems for us in it’s current state. You’ve done a tremendous job on this. But some scenarios are tricky. > Greetings, > > Andres Freund > > -- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services
