Re: BDR Cluster vs DB Config

Поиск
Список
Период
Сортировка
От Jonathan Eastgate
Тема Re: BDR Cluster vs DB Config
Дата
Msg-id CAF0Mkq__EAUMj81dmNxo0ZzGy6j8tsOZ3guCNNQyqYfzJXjWDg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BDR Cluster vs DB Config  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: BDR Cluster vs DB Config  (Martín Marqués <martin@2ndquadrant.com>)
Список pgsql-general
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



Keep up to date with simPRO at: http://simprogroup.com/blog
The contents of this email are subject to our email disclaimer.


On Wed, Jul 20, 2016 at 5:18 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
On 20 July 2016 at 13:22, Jonathan Eastgate <jonathan.eastgate@simpro.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


--

В списке pgsql-general по дате отправления:

Предыдущее
От: John R Pierce
Дата:
Сообщение: Re: Is it possible to control the location of the lock file when starting postgres?
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: Is it possible to control the location of the lock file when starting postgres?