BDR: Node join and leave questions

Поиск
Список
Период
Сортировка
От sym39
Тема BDR: Node join and leave questions
Дата
Msg-id 557B0C1D.1030801@gmail.com
обсуждение исходный текст
Список 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@mail.gmail.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


В списке pgsql-general по дате отправления:

Предыдущее
От: Filipe Pina
Дата:
Сообщение: Re: database-level lockdown
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: cached row type not invalidated after DDL change