I'd rather use something like this:
bdr_dump -N bdr -h localhost -U postgres -W mydb > /backup.sql
That's for each database. You would restore it, you must first create the empty database:
CREATE DATABASE mydb WITH ENCODING 'UTF-8' TEMPLATE template0;
(change encoding according to your needs. Run "psql --list" on your current system to see current encoding for each db)
Then, restore its contents:
cat /backup.sql | psql mydb
During restore, you may see some errors due to the backup containing the bdr truncate trigger on each table; it's normal at this point, so just ignore it.
You may need to backup your postgres users:
pg_dumpall -g > /globals.sql
And restore it BEFORE any database with
cat /globals.sql | psql
Backing up and restoring globals may be important when rewtoring databases, mostly to preserve permissions on tables/sequences during each database restore.
Regards,
Alvaro Aguayo
Jefe de Operaciones
Open Comb Systems E.I.R.L.
Oficina: (+51-1) 3377813 | RPM: #034252 / (+51) 995540103 | RPC: (+51) 954183248
Website: www.ocs.pe
Sent from my Sony Xperia™ smartphone
---- Slava Bendersky wrote ----
To: "volga629" <volga629@xxxxxxxxxxxxxx>
Cc: "pgsql-general" <pgsql-general@xxxxxxxxxxxxxx>, "John R Pierce" <pierce@xxxxxxxxxxxx>
Sent: Thursday, 31 March, 2016 02:41:17
Subject: Re: bdr replication
What I don't understand is the need of a shared storage in this case. It would be a lot better to have the data folder inside each server virtual disk to avoid troubles with the shared storage; I really see no reason for such configuration here.
Now, getting into the solution rather than in the problem. I suggest you to do the following:
1. First of all, backup your data folder for both nodes. Just in case. Make backup with postgres stopped to avoid problems.
2. Choose one node which will be considered up-to-date(Let's say "Node A")
3. Dump your database(s) on that node, excluding the bdr schema on each db. Dump also your globals
4. Wipe or rename your data folder on each node, and then initialize each node. Do not configure BDR yet.
5. Restore your data(backed up at step 3) on Node A
6. Configure BDR on Node A
7. Add Node B to the replication group, using "bdr_init_copy" to make it replicate from Node A.
That should do the trick. There is another possibility: Drop the replication configuration no Node A, and then start from scratch(Steps 1, 6 & 7). However, this can be troublesome, as it involves editing bdr & postgres schemas, and that can lead you to problems on the future, so I'd recommend you the "long" way.
Feel free to ask any question regarding this issue. Looks serious....
Alvaro Aguayo
Jefe de Operaciones
Open Comb Systems E.I.R.L.
Oficina: (+51-1) 3377813 | RPM: #034252 / (+51) 995540103 | RPC: (+51) 954183248
Website: www.ocs.pe
----- Original Message -----
From: "Slava Bendersky" <volga629@xxxxxxxxxxxxxx>
To: "Alvaro Aguayo Garcia-Rada" <aaguayo@xxxxxxxxxxxxxxx>
Cc: "pgsql-general" <pgsql-general@xxxxxxxxxxxxxx>, "John R Pierce" <pierce@xxxxxxxxxxxx>
Sent: Thursday, 31 March, 2016 12:28:09 AM
Subject: Re: bdr replication
Hello Alvaro,
We running BDR where each PostgreSQL vm is a master and shared storage only on hypervisor level. All vm leave with own virtual disk. Right now we have 2 server for redundancy which have shared network between them. Issue that BDR is working right now see log below. And my question how to restore BDR replication correctly.
volga629
----- Original Message -----
From: "Alvaro Aguayo Garcia-Rada" <aaguayo@xxxxxxxxxxxxxxx>
To: "volga629" <volga629@xxxxxxxxxxxxxx>
Cc: "pgsql-general" <pgsql-general@xxxxxxxxxxxxxx>, "John R Pierce" <pierce@xxxxxxxxxxxx>
Sent: Thursday, 31 March, 2016 02:19:42
Subject: Re: bdr replication
What's the purpose of such configuration? Doesn't makes sense for me. The only reasonable case where you would want to put the data folder on a shared storage is for usage with warm standby, where you can have a secondary server which serves as a read-only replica, and can be rpomoted to master on master failure.
If you intend high availability, you'd rather try it at VM level, like vmware HA or Proxmox HA. That will make your VM run on any hypervisor in the group disregarding the failure of some node.
Regards,
Alvaro Aguayo
Jefe de Operaciones
Open Comb Systems E.I.R.L.
Oficina: (+51-1) 3377813 | RPM: #034252 / (+51) 995540103 | RPC: (+51) 954183248
Website: www.ocs.pe
----- Original Message -----
From: "Slava Bendersky" <volga629@xxxxxxxxxxxxxx>
To: "John R Pierce" <pierce@xxxxxxxxxxxx>
Cc: "pgsql-general" <pgsql-general@xxxxxxxxxxxxxx>
Sent: Wednesday, 30 March, 2016 10:57:13 PM
Subject: Re: bdr replication
In my case only virtual hosts are use share storage (feed from glusterfs), but actual virtual machines have own separate disks and all PostgreSQL run on separate data directories.
volga629
----- Original Message -----
From: "John R Pierce" <pierce@xxxxxxxxxxxx>
To: "pgsql-general" <pgsql-general@xxxxxxxxxxxxxx>
Sent: Thursday, 31 March, 2016 00:34:55
Subject: Re: bdr replication
On 3/30/2016 8:09 PM, Slava Bendersky wrote:
> Is any share storage technology recommended for PostgreSQL in virtual
> environment ?
> Ok what I will do is going take backups, shutdown both virtual servers
> and place all vm use local disk on server only.
'share storage technology'... um. thats such a vague term, it can
mean lots of things.
each postgres instance needs its own data store, two instances can NOT
share the same files under any condition. these data stores can be
on SAN or NAS, as long the storage is reliable about committed random
writes, and as long as two different servers aren't using the SAME
directory for their data stores.
--
john r pierce, recycling bits in santa cruz
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general