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@xxxxxxxxxxxxxx [mailto:pgsql-admin-owner@xxxxxxxxxxxxxx] En nombre de Craig Ringer (I've dropped the Cc of pgsql-general to avoid cross-posting) On 17 March 2015 at 15:12, Ruth Melendo <rmelendo@xxxxxxxxxxxx> wrote: Ok, I will try to explain my environment. I want to have a high availability environment in active/active mode. [snip]
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.
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. |
