Re: Bi-Directional replication client awareness - Mailing list pgsql-general

From Martin Gudmundsson
Subject Re: Bi-Directional replication client awareness
Date
Msg-id 191D9551-21A6-4CF4-AF94-A6B8FA10E40B@gmail.com
Whole thread Raw
In response to Re: Bi-Directional replication client awareness  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-general
12 jul 2014 kl. 14:48 skrev Andres Freund <andres@2ndquadrant.com>:

> On 2014-07-12 14:37:02 +0200, Martin Gudmundsson wrote:
>>> 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?
>
> It is bidirectional if you configure a bdr node in
> synchronous_standby_names.

OK, I will play around with this a bit.
Thanks for the hint.


> Note that streaming replication's synchronous mode probably doesn't give
> the guarantees you're thinking it does:

> a) A sent commit might succeed locally on the primary, but the system
> might fail to send it to the synchronous standby. I.e. postgres'
> synchronous replication of normal commits is *not* 2-safe.

> b) Even if a transaction is replicated to the standby it's *not*
> guaranteed to be applied. All that's guaranteed is that it has been
> shipped to the synchronous standby

Very good info! I’m not sure that is so clear in the documentation but I have to revisit it.


>> 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. 
>
> I'd like that too, but I don't think that's going to happen. There's
> just too many caveats (CAP theorem et al) to make that generally
> useful/applicable.

We are currently using solutions that works like that, DB2 Datasharing on z/OS is one example.
But it’s not built around replication, but global filesystems and central locking facilities.  That approach also have
it’sissues, with performance bottlenecks etc. 


> I think we (as in postgres) will probably get the ability to run
> individual transactions in such a mode, but you surely wouldn't want to
> run every transaction in it.

That sounds like o good trade off. Looking forward to it.

>
> Greetings,
>
> Andres Freund
>
> --
> Andres Freund                       http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services



pgsql-general by date:

Previous
From: Martin Gudmundsson
Date:
Subject: Re: Bi-Directional replication client awareness
Next
From: Ramesh T
Date:
Subject: performance monitoring/tuning