(I've dropped the Cc of pgsql-general to avoid cross-posting)
On 17 March 2015 at 15:12, Ruth Melendo <rmelendo@xxxxxxxxxxxx> wrote:
Right, so that's some of the architecture, but nothing on the application.
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.
