Re: adding a bdr node using bcv backup

I'm sorry, I didn't send the correct information about node 2...

Here's what I get on all three nodes after I take a snapshot on node 1 and
bring it up on node 3...

*=== On Node 1: ===*
bdrdemo=# select bdr.bdr_get_local_nodeid();
bdr_get_local_nodeid
-------------------------------
(*6239328434665526195,1,16385*)
(1 row)

bdrdemo=# select bdr.bdr_get_local_node_name();
bdr_get_local_node_name
-------------------------
node1
(1 row)

bdrdemo=# SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid |
database | active | xmin | catalog_xmin | restart_lsn
-----------------------------------------+--------+-----------+--------+----------+--------+------+--------------+-------------
bdr_16385_6241964183952916534_1_16385__ | bdr | logical | 16385 |
bdrdemo | t | | 4593 | 0/123E9808

*=== On Node 2: ===*
bdrdemo=# select bdr.bdr_get_local_nodeid();
bdr_get_local_nodeid
-------------------------------
(*6241964183952916534,1,16385*)
(1 row)

bdrdemo=# select bdr.bdr_get_local_node_name();
bdr_get_local_node_name
-------------------------
node2
(1 row)

bdrdemo=# SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid |
database | active | xmin | catalog_xmin | restart_lsn
-----------------------------------------+--------+-----------+--------+----------+--------+------+--------------+-------------
bdr_16385_6239328434665526195_1_16385__ | bdr | logical | 16385 |
bdrdemo | t | | 3039 | 0/4EB0D28
(1 row)

*=== On Node 3: ===*
bdrdemo=# select bdr.bdr_get_local_nodeid();
bdr_get_local_nodeid
-------------------------------
(*6239328434665526195,1,16385*)
(1 row)

bdrdemo=# select bdr.bdr_get_local_node_name();
bdr_get_local_node_name
-------------------------
node1
(1 row)

bdrdemo=# SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | active | xmin |
catalog_xmin | restart_lsn
-----------+--------+-----------+--------+----------+--------+------+--------------+-------------
(0 rows)

On Thu, Jan 21, 2016 at 10:46 AM (Daniel Stolf) <dstolf(at)gmail(dot)com> wrote:

> Ok, I'm at work now and I have access to my lab...
>
> *==== On Node 1: ====*
> bdrdemo=# select bdr.bdr_get_local_nodeid();
> bdr_get_local_nodeid
> -------------------------------
> (6239328434665526195,1,16385)
> (1 row)
>
> bdrdemo=# select bdr.bdr_get_local_node_name();
> bdr_get_local_node_name
> -------------------------
> node1
> (1 row)
>
> bdrdemo=# select bdr.bdr_get_local_nodeid();
> bdr_get_local_nodeid
> -------------------------------
> (6239328434665526195,1,16385)
> (1 row)
>
> bdrdemo=# select bdr.bdr_get_local_node_name();
> bdr_get_local_node_name
> -------------------------
> node1
> (1 row)
>
> ================
>
> *=== On Node 2: ===*
> bdrdemo=# select bdr.bdr_get_local_nodeid();
> bdr_get_local_nodeid
> -------------------------------
> (6239328434665526195,1,16385)
> (1 row)
>
> bdrdemo=# select bdr.bdr_get_local_node_name();
> bdr_get_local_node_name
> -------------------------
> node1
> (1 row)
> ================
>
> Now, I take a snapshot from node1 and bring up a clone on node3... Here's
> what I got on node3:
>
> *=== On Node 3: ===*
> bdr_get_local_nodeid
> -------------------------------
> (6239328434665526195,1,16385)
> (1 row)
>
> bdrdemo=# select bdr.bdr_get_local_node_name();
> bdr_get_local_node_name
> -------------------------
> node1
> (1 row)
>
> bdrdemo=# SELECT * FROM pg_replication_slots;
> slot_name | plugin | slot_type | datoid | database | active | xmin |
> catalog_xmin | restart_lsn
>
> -----------+--------+-----------+--------+----------+--------+------+--------------+-------------
> (0 rows)
>
> ================
>
> As you can see, when I brought up a clone of node1 on node3, it got the
> same node name and id as node1...
>
> 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?
> 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?
>
> Regards,
> Daniel Stolf
>
>
> On Thu, Jan 21, 2016 at 8:34 AM (Daniel Stolf) <dstolf(at)gmail(dot)com> wrote:
>
>> 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 <craig(at)2ndquadrant(dot)com>
>> escreveu:
>>
>>> On 21 January 2016 at 08:29, (Daniel Stolf) <dstolf(at)gmail(dot)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
>>>
>>