Ok, Thanks. I have tuned my db to work with global sequences in every table. I think that will solve most of the problems. Cartography will be updated just from time to time. That shouldn´t cause problems. But now, my dude is about pgpool. Do you think It can work well just as a balancer in this environment? My main troubles from the beginning have been in recovery and I dind´t find detailed doc in that way. Most of times, I need to delete data directory in node 2 and starts init replication again. 1.- Stop both nodes and comment BDR entries in postgresql.conf 2.- Delete data directory in node 2. 3.- Start node 1 without BDR so that BDR schema drops. 4.- Restart node 1 with BDR active 5.- Start node 2 with BDR active so that init replica happens and BDR gets well configured from here in both nodes. Is that the best way to recovery? There is something I can do to recover database without all these steps? Ruth Patricia Melendo Ventura Software Engineer TELTRONIC, S.A.U. T: +34 976 465656 Ext. 179 F: +34 976 465722
De: Craig Ringer [mailto:craig@xxxxxxxxxxxxxxx] On 17 March 2015 at 17:18, Ruth Melendo <rmelendo@xxxxxxxxxxxx> wrote: 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. If that's a requirement, then you're going to need to write the application to cope with the consequences. What if, while there's replication lag due to network issues, someone creates a row with id "42" in one node. Someone else creates a row with id "42" in the same table in another node? The app has to be able to deal with that, or use things (like BDR's global sequences) to prevent it. And you can't always prevent it unless writeable tables are basically append-only, since two UPDATEs that affect the same row can also conflict. So ... *if* you can review your application and change it where necessary to cope with the anomalies that can arise in asynchronous multi-master replication, BDR will be absolutely ideal for your needs. That's pretty much what it's for. But you need to be able to do that review and adjustment rather than just pointing your app at a couple of BDR nodes and hoping for the best. BDR has conflict logging and conflict statistics features that will help you during testing, too; see the docs for details on them.
Craig Ringer http://www.2ndQuadrant.com/ |
