BDR replication slots

Hello,

What do you see on each node's log after enablibg interfaces?

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

Sent from my Sony Xperia™ smartphone

---- Nikhil wrote ----

Hello,

I have a 2 node BDR group and replication is happening properly. if i bring
down one of the node's interface, after sometime the replication slots are
becoming inactive (pg_replication_slots view). Then if i bring back
interface slots are not turning active automatically and replication stops.
Any idea why automatically its not re-established ?

Best Regards,
Nikhil

2016-04-19 6:51 GMT+02:00 Nikhil <nikhilsmenon@gmail.com>:

Hello,

I have a 2 node BDR group and replication is happening properly. if i
bring down one of the node's interface, after sometime the replication
slots are becoming inactive (pg_replication_slots view). Then if i bring
back interface slots are not turning active automatically and replication
stops. Any idea why automatically its not re-established ?

May be postgres does not detect the link is down.
You could try modifying the connection strings, so that postgres detects
earlier the problem, like described in this post :
https://github.com/2ndQuadrant/bdr/issues/173 :

<<<
[...]
Example of dsn_connection field:
host=192.168.1.140 port=5432 dbname=safewalk-server connect_timeout=10
keepalives_idle=5 keepalives_interval=1

Hope this helps,

Sylvain

On interface down:
------------------
<10.102.31.213(27599)postgres13082016-04-19 06:31:36
GMTprocess_journal%LOG: terminating walsender process due to replication
timeout

Once interface is brought back
----------------------------------------
425906 <12692016-04-19 08:32:58 GMT%LOG: starting background worker
process "bdr (6275149074578269365,2,16386,)->bdr (6275135922714263763,1,"
425907 <597732016-04-19 08:32:58 GMT%ERROR: relation "mygroup" already
exists
425908 <597732016-04-19 08:32:58 GMT%CONTEXT: during DDL replay of ddl
statement: CREATE TABLE public.mygroup (id pg_catalog."varchar"(14) NOT
NULL COLLATE pg_catalog."default", name pg_catalog."varchar"(100) COLLATE
pg_catalog."default", device_type pg_catalog."varchar"(30) COLLATE
pg_catalog."default", platform_type pg_catalog."varchar"(30) COLLATE
pg_catalog."default",
CONSTRAINT mygroup_pkey PRIMARY KEY (id) ) WITH (oids=OFF)
425909 <12692016-04-19 08:32:58 GMT%LOG: worker process: bdr
(6275149074578269365,2,16386,)->bdr (6275135922714263763,1,(PID 59773)
exited with exit code 1
425910 <10.102.31.213(13467)postgres597742016-04-19 08:32:59
GMTprocess_journal%LOG: starting logical decoding for slot
"bdr_16386_6275135922714263763_1_16386__"
425911 <10.102.31.213(13467)postgres597742016-04-19 08:32:59
GMTprocess_journal%DETAIL: streaming transactions committing after
0/1014CEE8, reading WAL from 0/1014A920
425912 <10.102.31.213(13467)postgres597742016-04-19 08:32:59
GMTprocess_journal%LOG: logical decoding found consistent point at
0/1014A920
425913 <10.102.31.213(13467)postgres597742016-04-19 08:32:59
GMTprocess_journal%DETAIL: There are no running transactions.
425914 *<10.102.31.213(13467)postgres597742016-04-19 08:32:59
GMTprocess_journal%LOG: unexpected EOF on standby con**nection*

On Tue, Apr 19, 2016 at 10:29 AM, Alvaro Aguayo Garcia-Rada <
aaguayo@opensysperu.com> wrote: