Re: pgpool + BDR, is it possible? - Mailing list pgsql-admin
Thanks for your help.
My app is a GIS Server and we strongly need high availability. The reason to be master/master is to share load because we have a lot of users and as, this is an app for security sector, each node must be able to work alone to ensure availability all the time.
The 2 databases I want to configure for replica master/master are the admin database which has no high amount of transactions and the cartography one. The data db does not need replication because each node has its own data cache coming from another control application.
With this description, do you still think that best way is active/passive? I´m not sure about that and it is taking me much time to take a decision…. :/
Ruth Patricia Melendo Ventura
Software Engineer
TELTRONIC, S.A.U.
T: +34 976 465656 Ext. 179
F: +34 976 465722
De: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql.org] En nombre de Craig Ringer
Enviado el: martes, 17 de marzo de 2015 9:31
Para: Ruth Melendo
CC: pgsql-admin
Asunto: Re: [ADMIN] pgpool + BDR, is it possible?
(I've dropped the Cc of pgsql-general to avoid cross-posting)
On 17 March 2015 at 15:12, Ruth Melendo <rmelendo@teltronic.es> wrote:
Ok, I will try to explain my environment.
I want to have a high availability environment in active/active mode. [snip]
Right, so that's some of the architecture, but nothing on the application.
You need to understand that you'd be working with asynchronous replication here. The app has to be aware of and written to cope with anomalies arising from that, like insert/insert conflicts, etc. BDR provides some tools to help, like global sequences and user-defined conflict handlers, but it's *not* the same thing as just pointing the app at a standalone PostgreSQL server. The nodes are *not* always consistent with each other (because it's asynchronous) so the app can see older data on one node than on another. That sort of thing.
If your goal is HA then I strongly recommend an active/passive setup with failover. It will be simpler and not require app changes. BDR comes into its own when you need latency tolerance, partition tolerance, etc, and it doesn't sound like you do.
About Barman, to restore database
1.- Stop nodes
2.- Disable BDR in node 1
3.- Backup node 1
4.- Start node 1
5.- Delete data directory in node 2
6.- Start node 2 with BDR active.
That would be the recovery process?
Since there's no restore in that list, no, it wouldn't. I haven't written step by step guidance there, but it's something that's worth adding to the documentation, so I'll note that.
Attachment
pgsql-admin by date: