<div dir="ltr">It replicated for 2 months with the firewall and anti-virus on. Just in case, I turned the firewall and anti virus off and it's still not replicating. I used wiresharks to examine the packets and did not see anything suspicious. Using pgadmin, I'm able to connect to the main server from the replicated server and vice versa so the connection seems to be accepted.<div><br></div><div>When connection cannot be established or is rejected, slon log usually gives an error. In my case, it's just stuck on: <span style="font-size:12.8px">INFO remoteWorkerThread_1: syncing set</span></div><div style="font-size:12.8px"> 1 with 59 table(s) from provider 1" with no errors.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Actually, it gets stuck for several minutes and then do some cleanup operations. The following is the last few lines of the slon log. Sorry, the person's windows is in French hence you see a mixture of English and French:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><div style="font-size:12.8px">2016-01-31 19:44:24 AmÚr. du Sud occid. INFO remoteWorkerThread_1: syncing set</div><div style="font-size:12.8px"> 1 with 59 table(s) from provider 1</div><div style="font-size:12.8px">NOTICE: Slony-I: cleanup stale sl_nodelock entry for pid=5388</div><div style="font-size:12.8px">CONTEXT: instruction SQL ┬½ SELECT "_slony_Securithor2".cleanupNodelock() ┬╗</div><div style="font-size:12.8px">fonction PL/pgsql "_slony_Securithor2".cleanupevent(interval), ligne 82 ├á PERFO</div><div style="font-size:12.8px">RM</div><div style="font-size:12.8px">NOTICE: Slony-I: cleanup stale sl_nodelock entry for pid=1176</div><div style="font-size:12.8px">CONTEXT: instruction SQL ┬½ SELECT "_slony_Securithor2".cleanupNodelock() ┬╗</div><div style="font-size:12.8px">fonction PL/pgsql "_slony_Securithor2".cleanupevent(interval), ligne 82 ├á PERFO</div><div style="font-size:12.8px">RM</div><div style="font-size:12.8px">NOTICE: Slony-I: log switch to sl_log_1 complete - truncate sl_log_2</div><div style="font-size:12.8px">CONTEXT: fonction PL/pgsql "_slony_Securithor2".cleanupevent(interval), ligne 9</div><div style="font-size:12.8px">5 ├á affectation</div><div style="font-size:12.8px">2016-01-31 19:54:24 AmÚr. du Sud occid. INFO cleanupThread: 0.062 seconds f</div><div style="font-size:12.8px">or cleanupEvent()</div><div style="font-size:12.8px">NOTICE: Slony-I: Logswitch to sl_log_2 initiated</div><div style="font-size:12.8px">CONTEXT: instruction SQL ┬½ SELECT "_slony_Securithor2".logswitch_start() ┬╗</div><div style="font-size:12.8px">fonction PL/pgsql "_slony_Securithor2".cleanupevent(interval), ligne 97 ├á PERFO</div><div style="font-size:12.8px">RM</div><div style="font-size:12.8px">2016-01-31 20:04:25 AmÚr. du Sud occid. INFO cleanupThread: 0.000 seconds f</div><div style="font-size:12.8px">or cleanupEvent()</div></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">What would cause no replication yet no error in the logs?</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Thanks.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 29, 2016 at 9:50 AM, Jan Wieck <span dir="ltr"><<a href="mailto:jan@wi3ck.info" target="_blank">jan@wi3ck.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 01/28/2016 10:57 PM, Sung Hsin Lei wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello guys,<br>
<br>
So I have this setup that has already stopped on me 3 times the last 6<br>
months. Each time it would replicate properly for 2-3 months and then it<br>
would just stop. It currently is stopped since January 11, 2016. The<br>
only way I can get replication back is to set everything up from<br>
scratch. I'm wondering if anyone has an idea on the issue causing the<br>
stoppage. I'm running 64-bit slony 2.2.4.<br>
<br>
Currently, when I run slon on the replicated machine, I get the following:<br>
<br>
<br>
<br>
C:\Program Files\PostgreSQL\9.3\bin>slon slony_Securithor2 "dbname =<br>
Securithor2<br>
user = slonyuser password = securiTHOR971 port = 6234"<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: slon version 2.2.4<br>
starting<br>
up<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Integer option<br>
vac_frequenc<br>
y = 3<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Integer option<br>
log_level =<br>
0<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Integer option<br>
sync_interva<br>
l = 2000<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Integer option<br>
sync_interva<br>
l_timeout = 10000<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Integer option<br>
sync_group_m<br>
axsize = 20<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Integer option<br>
quit_sync_pr<br>
ovider = 0<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Integer option<br>
remote_liste<br>
n_timeout = 300<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Integer option<br>
monitor_inte<br>
rval = 500<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Integer option<br>
explain_inte<br>
rval = 0<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Integer option<br>
tcp_keepaliv<br>
e_idle = 0<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Integer option<br>
tcp_keepaliv<br>
e_interval = 0<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Integer option<br>
tcp_keepaliv<br>
e_count = 0<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Integer option<br>
apply_cache_<br>
size = 100<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Boolean option<br>
log_pid = 0<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Boolean option<br>
log_timestam<br>
p = 1<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Boolean option<br>
tcp_keepaliv<br>
e = 1<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Boolean option<br>
monitor_thre<br>
ads = 1<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: Real option<br>
real_placeholde<br>
r = 0.000000<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: String option<br>
cluster_name<br>
= slony_Securithor2<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: String option<br>
conn_info = d<br>
bname = Securithor2 user = slonyuser password = securiTHOR971 port = 6234<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: String option<br>
pid_file = [N<br>
ULL]<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: String option<br>
log_timestamp<br>
_format = %Y-%m-%d %H:%M:%S %Z<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: String option<br>
archive_dir =<br>
[NULL]<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: String option<br>
sql_on_connec<br>
tion = [NULL]<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: String option<br>
lag_interval<br>
= [NULL]<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: String option<br>
command_on_lo<br>
garchive = [NULL]<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: String option<br>
cleanup_inter<br>
val = 10 minutes<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: local node id = 2<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. INFO main: main process started<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: launching<br>
sched_start_mainl<br>
oop<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: loading current<br>
cluster con<br>
figuration<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG storeNode: no_id=1<br>
no_comment='Ma<br>
ster Node'<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG storePath: pa_server=1<br>
pa_client=<br>
2 pa_conninfo="dbname=Securithor2 host=192.168.1.50 user=slonyuser<br>
password = se<br>
curiTHOR971 port = 6234" pa_connretry=10<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG storeListen: li_origin=1<br>
li_recei<br>
ver=2 li_provider=1<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG storeSet: set_id=1<br>
set_origin=1 s<br>
et_comment='All tables and sequences'<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. WARN remoteWorker_wakeup: node<br>
1 - no<br>
worker thread<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG storeSubscribe: sub_set=1<br>
sub_pro<br>
vider=1 sub_forward='f'<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. WARN remoteWorker_wakeup: node<br>
1 - no<br>
worker thread<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG enableSubscription: sub_set=1<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. WARN remoteWorker_wakeup: node<br>
1 - no<br>
worker thread<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: last local event<br>
sequence =<br>
5000462590<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG main: configuration<br>
complete - st<br>
arting threads<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. INFO localListenThread: thread<br>
starts<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG version for "dbname =<br>
Securithor2<br>
user = slonyuser password = securiTHOR971 port = 6234" is 90310<br>
NOTICE: Slony-I: cleanup stale sl_nodelock entry for pid=5188<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG enableNode: no_id=1<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. INFO remoteWorkerThread_1:<br>
thread star<br>
ts<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. INFO remoteListenThread_1:<br>
thread star<br>
ts<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. INFO main: running scheduler<br>
mainloop<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG cleanupThread: thread starts<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. INFO syncThread: thread starts<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. INFO monitorThread: thread starts<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG version for "dbname =<br>
Securithor2<br>
user = slonyuser password = securiTHOR971 port = 6234" is 90310<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG remoteWorkerThread_1:<br>
update prov<br>
ider configuration<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG remoteWorkerThread_1:<br>
added activ<br>
e set 1 to provider 1<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG version for<br>
"dbname=Securithor2 h<br>
ost=192.168.1.50 user=slonyuser password = securiTHOR971 port = 6234"<br>
is 90306<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG version for "dbname =<br>
Securithor2<br>
user = slonyuser password = securiTHOR971 port = 6234" is 90310<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG cleanupThread: bias = 60<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG version for "dbname =<br>
Securithor2<br>
user = slonyuser password = securiTHOR971 port = 6234" is 90310<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG version for "dbname =<br>
Securithor2<br>
user = slonyuser password = securiTHOR971 port = 6234" is 90310<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. CONFIG version for<br>
"dbname=Securithor2 h<br>
ost=192.168.1.50 user=slonyuser password = securiTHOR971 port = 6234"<br>
is 90306<br>
2016-01-28 17:41:00 AmÚr. du Sud occid. INFO remoteWorkerThread_1:<br>
syncing set<br>
1 with 59 table(s) from provider 1<br>
<br>
<br>
<br>
<br>
It gets stuck at "syncing set 1 with 59 table(s) from provider 1" (the<br>
last line) forever with the occasional messages that says something<br>
about cleaning(threadcleaning I thing).<br>
<br>
<br>
Checking the postgres logs, I see lots of:<br>
<br>
2016-01-28 17:33:07 AST LOG: n'a pas pu recevoir les données du client<br>
: unrecognized winsock error 10061<br>
<br>
Which translates to:<br>
<br>
2016-01-28 17:33:07 AST LOG: was not able to receive the data from the<br>
client : unrecognized winsock error 10061<br>
<br>
I'm able to connect to the main db from the replicated machine no<br>
problem. I have no idea how this error 10061 is caused.<br>
</blockquote>
<br></div></div>
Winsock error 10061 is WSAECONNREFUSED<br>
<br>
Connection refused.<br>
<br>
No connection could be made because the target computer actively<br>
refused it. This usually results from trying to connect to a<br>
service that is inactive on the foreign host—that is, one with no<br>
server application running.<br>
<br>
This might be a firewall issue. Can you use some network sniffer to find out what is happening on the TCP/IP level between the two machines?<br>
<br>
<br>
Regards, Jan<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Jan Wieck<br>
Senior Software Engineer<br>
<a href="http://slony.info" rel="noreferrer" target="_blank">http://slony.info</a><br>
</font></span></blockquote></div><br></div>