12 jul 2014 kl. 13:45 skrev Andres Freund <andres@2ndquadrant.com>:
> On 2014-07-12 13:23:08 +0200, Martin Gudmundsson wrote:
>>
>> 12 jul 2014 kl. 12:33 skrev Andres Freund <andres@2ndquadrant.com>:
>>
>>> 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
transactionexecutes, 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
whenI 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.
Butsome scenarios are tricky.
> Greetings,
>
> Andres Freund
>
> --
> Andres Freund http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
