Re: adding a bdr node using bcv backup

Hi Craig, how are you?

Just as an update, I figured it out...

First, here's my setup:
Node 1 and Node 2 running postgresql-bdr94-bdr and bdr enabled.
Node 3 with the same setup, ready to receive the snapshot clone.

These were my steps:
1) pg_start_backup
2) take snapshot from Node 1
3) pg_stop_backup
(alternatively, one could bring a node down and take the snapshot, instead
of the start_backup/stop_backup procedure)
4) bring clone up on Node 3
5) no need for pg_resetxlog -s, otherwise you'll get error
'postgresql-bdr94-bdr'
6) bdr_init_copy
7) checking the logs, I see the error 'ERROR: replication slot
"bdr_16385_6241964183952916534_1_16385__" already exists'. It's trying to
create the replication slot for Node 2, even though it's already there
8) pg_drop_replication_slot('bdr_16385_6241964183952916534_1_16385__')
9) bdr on Node 3 finally (re)creates the replication slot for Node 2 and
resumes its operations.

Make some tests on all nodes, delete some previous records, insert new
ones... All seems to be working... Except for that minor hickup on step 7,
all went fine. Maybe bdr could check if the replication slot is already
exists before trying to create it and move along if it's already there?

Thanks a lot!

On Fri, Jan 22, 2016 at 6:57 AM Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> On 21 January 2016 at 20:46, (Daniel Stolf) <dstolf(at)gmail(dot)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
>