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
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 |