Hi Craig, how are you? Thanks for your answer. It doesn't seems too complex... Also, it's just a test scenario, I don't intend to use as a production setup or to recommend as such, at least not until I'm 100% sure I got it right...
So, assuming I get the snapshot right... The steps would be... 1) create replication slots on prior nodes before taking the snapshot (not sure how to do that, which command would it be? ); 2) take the snapshot; 3) bring it up on another server; 4) use bdr_init_copy I'm not at work right now, but I remember two things... On node 3 I brought up the copy, if I try get local node name, it says node1, which is the node I got the copy from, ... Wouldn't I also have to do something about that? Like, delete the previous information on bdr database that went along? Em qui, 21 de jan de 2016 00:50, Craig Ringer <cr...@2ndquadrant.com> escreveu: > On 21 January 2016 at 08:29, (Daniel Stolf) <dst...@gmail.com> wrote: > >> Hello there... >> >> I'm new to postgres and I'm trying out BDR replication... >> >> I know that when I issue the bdr.bdr_group_join command, it will copy the >> entire database from the host I specify on parameter 'join_using_dsn' and >> this may take a while depending on the network and the size of the >> database... >> >> What I wanted to know is if I can leverage a bcv backup... Is it possible? >> > > BCV seems to be an EMC backup system. It looks like a snapshot. If the > snapshot taken is consistent and atomic, and if it includes both pg_xlog > and the rest of the datadir and all tablespaces in the SAME snapshot taken > at the SAME instant, then you can treat it much like a pg_basebackup. In > that case you can use bdr_init_copy to bring it up as a new BDR node. You > must either stop all writes to all other nodes or pre-create the > replication slots *before* taking the snapshot though, otherwise the new > node won't be able to catch up to writes done after the snapshot and before > it was started. > > If this sounds too complex then stick to the documented methods that work. > Working from separately taken snapshots is hard to get right and could lead > to subtle data problems if you get it wrong. > > -- > Craig Ringer http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services >