On 21 January 2016 at 20:46, (Daniel Stolf) <dst...@gmail.com> wrote:
> So here's what I don't get: > > 1) if I have to create a new replication slots on node1 and 2 beforehand > using "pg_create_physical_replication_slot" , don't they need the if of > node3 on their name? > You need to create a logical replication slot with the 'bdr' plugin, since that's what BDR uses. > 2) If node3 has the same name and if as node1, won't that introduce a > conflic? Don't I need to clean that up before node3 can join the > replication group? > It will not have the same sysid. bdr_init_copy resets it normally. If you're doing it manually you'd have to run pg_resetxlog with the option to reset the sysid, create the new slots with the new sysid, then make sure bdr_init_copy doesn't reset the sysid again it afterwards when it brings the new node up. Honestly I don't remember the exact steps that had to be performed before bdr_init_copy got support for automating the pg_basebackup step. That's the supported way to do it. I'm trying to prepare some conference presentations and a new pglogical release so I can't presently dig into it further for you; you may need to take a look at the bdr_init_copy sources and/or study how the node bringup works in more detail. I can see it being useful to add a new mode to bdr_init_copy where you tell it to generate a sysid and make new slots for that sysid; *then* you make a snapshot and restore it, then you run bdr_init_copy again to finish bringup, resetting the sysid to the new value and finishing setup. There's nothing like that now though. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
