Re: BDR Selective Replication

On 28 April 2015 at 05:38, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:

> On 4/26/15 7:49 AM, Craig Ringer wrote:
>
>> There are also some improvements needed to the user interface - in
>> particular, providing a function interface for changing replication set
>> memberships for connections so there's no need to manually restart the
>> apply backends after a change, and providing default replication sets
>> for a node.
>>
>
> If 'default replication set' is the idea of "here's what tables *should*
> be getting replicated regardless of whether that's happening or not", it'd
> be great if that was done so it could be split out on it's own at some
> point. It's a problem that affects all replication systems.

It wasn't, but that's an interesting idea.

You need away to identify peer nodes in an abstract way before you can
really define sets of which nodes should get which tables. So I think
replication identifiers ( https://commitfest.postgresql.org/4/161/ ) are a
pre-requisite for that though, and one that's proving difficult to get in.

I think any sort of replication sets is likely to have similar problems,
especially the "no in-core user" problem. There's nothing fundamentally
impossible about filtering WAL sent to physical downstreams over streaming
replication to include only replicated tables and the catalogs, though, so
perhaps there could be an in-core user for it.

In BDR we're currently (ab)using security labels to tag tables with their
replication sets, but I'd love to have a proper way to do that. As I recall
the prior approach, of allowing custom relation options, was rejected on
-hackers.

How would you want to go about storing and tracking the information? A new
catalog? The other issue for in-core replication sets would probably be
making it foreign-key aware, so replication of a table transitively
requires replication of its references.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services