Re: BDR Cluster vs DB Config

Thanks guys.

Very helpful - I was thinking we may need to look at moving to schemas
instead of individual db's.

I assume that once BDR is enabled on a database that any additional schemas
added post config are automatically included in BDR replication?

And so you see any issues having potentially 200 schemas within the DB -
performance or replication wise?

Thanks in advance.

*Jonathan J. Eastgate*
Chief Technology Officer | simPRO Software Group
Ph: 1300 139 467 +61 7 3147 8777

<http://simprogroup.com/email-signature-promo/>

Keep up to date with simPRO at: http://simprogroup.com/blog
The contents of this email are subject to our email disclaimer
<http://simprogroup.com/au/legal/email-confidentiality-notice>.

On Wed, Jul 20, 2016 at 5:18 PM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> On 20 July 2016 at 13:22, Jonathan Eastgate <jonathan(dot)eastgate(at)simpro(dot)co>
> wrote:
>
>> Hi everyone.
>>
>> We've been testing BDR on and off for the last 2 years and are keen to
>> start looking at implementing it in production as it seems 0.93 has
>> resolved most of the issues we faced with it in the early days.
>>
>> However there is still one item that makes it a difficult proposition...
>>
>> DSN config per database.
>>
>> Is there any way to configure BDR on a cluster wide basis so that all
>> DB's on a cluster are replicated via BDR instead of having to configure a
>> connection for each DB we want to replicate?
>>
>
> No.
>
> Not only that, but if you're replicating lots of databases between
> PostgreSQL instances you're likely to start facing some performance
> problems around the sheer number of background workers required, the way
> WAL needs to be processed multiple times, etc.
>
> If you're using this for multi-tenancy or similar, see if you can isolate
> by schema not by database.
>
>
>> The problem we have is over 20 clusters with about 200 DB's per cluster
>> and growing constantly so this would make deploying BDR a painful process -
>> if we had to add a connection for each existing DB and then every new DB.
>>
>
> Yeah. That's going to cause you pain even aside from the management of it.
>
>
>
>> Is there a way around this or are there plans to make this type of config
>> available?
>>
>
> There are no plans to automate this configuration. BDR works at a database
> level, with the exception of bdr_init_copy bringing up all BDR-enabled
> databases on the join target node as a one-time operation at setup.
>
> Maybe once we eventually have some kind of answer for how to replicate
> instance-global DDL that affects shared catalogs, like database
> creation/drop, user creation/drop, etc, then it might make sense to extend
> BDR or its successor to do this. But not at the moment.
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

--
--