Thanks for the idea, and that is it... it's indeed the other direction of 
replication was affected by blocking a port

-----Original Message-----
From: Alvaro Aguayo Garcia-Rada [mailto:aagu...@opensysperu.com] 
Sent: Friday, August 25, 2017 5:00 PM
To: Zhu, Joshua <j...@thalesesec.net>
Cc: PostgreSql-general <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] BDR replication port

That's weird. Another idea: Do changes on that server get replicated to the 
other servers? I'm not sure if incomming connections are used to receive WAL or 
to send it.

Regards,

Alvaro Aguayo
Jefe de Operaciones
Open Comb Systems E.I.R.L.

Oficina: (+51-1) 3377813 | RPM: #034252 / (+51) 995540103  | RPC: (+51) 
954183248
Website: www.ocs.pe

----- Original Message -----
From: "Zhu, Joshua" <j...@vormetric.com>
To: "Alvaro Aguayo Garcia-Rada" <aagu...@opensysperu.com>
Cc: "PostgreSql-general" <pgsql-general@postgresql.org>
Sent: Friday, 25 August, 2017 18:35:21
Subject: RE: [GENERAL] BDR replication port

Thought about that possibility, so postgres on the node with port blocked was 
restarted after blocking the port.

-----Original Message-----
From: Alvaro Aguayo Garcia-Rada [mailto:aagu...@opensysperu.com] 
Sent: Friday, August 25, 2017 3:23 PM
To: Zhu, Joshua <j...@thalesesec.net>
Cc: PostgreSql-general <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] BDR replication port

Just a guess: How did you blocked the port? Depending on that, you could be 
blocking only new connections, but connections already established would 
continue to transmit data; remember BDR only reconnects when connection is lost.

Alvaro Aguayo
Jefe de Operaciones
Open Comb Systems E.I.R.L.

Oficina: (+51-1) 3377813 | RPM: #034252 / (+51) 995540103  | RPC: (+51) 
954183248
Website: www.ocs.pe

----- Original Message -----
From: "Zhu, Joshua" <j...@vormetric.com>
To: "PostgreSql-general" <pgsql-general@postgresql.org>
Sent: Friday, 25 August, 2017 16:49:44
Subject: [GENERAL] BDR replication port

Hi, I am experimenting how network configuration impacts BDR replication, ran 
into something that I can't explain, and wonder if someone can shed light.  
Here it goes:

With a four node BDR group configured and running (all using default port 
5432), I purposely blocked port 5432 on one of the node in the group, and was 
expecting to see changes on other nodes stop being replicated to this node, but 
that's not  what happened.

Shell commands show that the port was indeed blocked  (In the following example 
session, the port 5432 is blocked on 10.3.122.31, but open on 10.3.122.21):

% nc -v --send-only 10.3.122.21 5432 </dev/null
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 10.3.122.21:5432.
Ncat: 0 bytes sent, 0 bytes received in 0.00 seconds.

% nc -v --send-only 10.3.122.31 5432 </dev/null
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connection timed out.

% psql -h 10.3.122.21 mydb
psql (9.4.10)
Type "help" for help.
mydb=#

% psql -h 10.3.122.31 mydb
psql: could not connect to server: Connection timed out
        Is the server running on host "10.3.122.31" and accepting
        TCP/IP connections on port 5432?

At this state, I tried insertion and update on node 10.3.122.21, and all of 
which were replicated to node 10.3.122.31.  However, attempt to create a new 
table on node 10.3.122.21 was stuck (as expected) until the port 5432 on 
10.3.122.31 opened again.

So my question is, is there another port other than port 5432 that BDR uses for 
replication? If not, how could changes be replicated to 10.3.122.31 when its 
port 5432 was blocked?

Thanks,


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Reply via email to