BDR: Node join and leave questions

From: sym39 <marechal(dot)sylvain2(at)gmail(dot)com>
To: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: BDR: Node join and leave questions
Date: 2015-06-12 16:43:09
Message-ID: 557B0C1D.1030801@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hello all,

I am playing with multiple nodes to understand how cleanly to detach a
node. Even after reading the post
"[BDR] Node Join Question"
(http://www.postgresql.org/message-id/flat/CANf8RLvYXsLPxOHUcSvdBcVNkTmNiHKkMY2_ncer3egky+ac+g(at)mail(dot)gmail(dot)com#CANf8RLvYXsLPxOHUcSvdBcVNkTmNiHKkMY2_ncer3egky+ac+g@mail.gmail.com),
this is still not clear to me.

Next find what I currently do with nodes node1, node2 node3, when I
like to detach node3:
1) Connect to node1:
a) Issue a select bdr.bdr_part_by_node_names('{node3}'). After that:
-node3 state is 'k';
-the node3 corresponding replication slot should have been deleted.
b) Check pg_replication_slots and remove the slot corresponding to node3
with pg_drop_replication_slot() if it has not been removed.
c) Then remove the node3 identifier in pg_replication_identifiers with
pg_replication_identifier_drop().
d) Remove the entry corresponding to node3 in bdr.bdr_nodes.
e) Remove the entry corresponding to node3 in bdr.bdr_connections.

2) Connect to node2:
b) Check pg_replication_slots and remove the slot corresponding to node3
with pg_drop_replication_slot() if it has not been removed.
c) Then remove the node3 identifier in pg_replication_identifiers with
pg_replication_identifier_drop().

4) connect to node3:
a) Issue a select bdr.bdr_part_by_node_names('{node3}'). After that:
-node3 state is 'k';
-the node1 and node2 corresponding replication slots should have been
deleted.
b) Check pg_replication_slots and remove the slot corresponding to node1
and node2 with pg_drop_replication_slot() if they have not been removed.

Questions :
A) Is there a specific order to leave the nodes / Am I correct the way I
do it ?

B) If I want to "re-join" node3, the only solution is to drop and
recreate the database on node3.Is there "no way" to redo a join on a
fresh detached node? I could understand it but I like to be sure this is
not possible.

C) Now that node3 can live its life independently of node1 and node2, it
is possible to add/remove data in tables, but DDL are still forbidden.
Is it a bug?
Next, a simpler sample to illustrate the problem:
<<<
postgres=# create database test template template0;
CREATE DATABASE
postgres=# \c test
You are now connected to database "test" as user "dbadmin".
test=# CREATE EXTENSION btree_gist;
CREATE EXTENSION
test=# CREATE EXTENSION bdr;
CREATE EXTENSION

-- DDL are still possible
test=# create table before_node_creation (i int primary key not null);
CREATE TABLE

-- Now create the group. After that, DDL are now forbidden
test=# SELECT bdr.bdr_group_create(local_node_name :=
'node1',node_external_dsn := 'host=172.27.118.64 port=5432 dbname=test');

test=# create table after_node_creation (i int primary key not null);
ERROR: No peer nodes or peer node count unknown, cannot acquire DDL lock
HINT: BDR is probably still starting up, wait a while

-- Now detach the group, in the hope to create some table
-- But this does not work. DDL are still forbidden
test=# select bdr.bdr_part_by_node_names('{node1}');

test=# create table after_node_creation (i int primary key not null);
ERROR: No peer nodes or peer node count unknown, cannot acquire DDL lock
HINT: BDR is probably still starting up, wait a while
test=#
>>>

So is there a way to completely leave a node so that the database to be
usable (DDL possible) as before calling bdr.bdr_group_create()?

Thanks and Regards,
Sylvain

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2015-06-12 16:45:58 Re: cached row type not invalidated after DDL change
Previous Message Filipe Pina 2015-06-12 16:25:18 Re: database-level lockdown