Progress 10.2B08 on Windows servers
Trying to get OE Replication running on a client site. Normally have few issues but struggling today for some reason.
Source and Target have identical repl.properties files.
[server]
control-agents=l_idx41_pctrl
database=pctrl
defer-agent-startup=10080
transition=manual
transition-timeout=600
agent-shutdown-action=recovery
[control-agent.l_idx41_pctrl]
name=l_idx41_pctrl
database=pctrl
host=cmlsql03
port=38140
connect-timeout=86400
replication-method=async
critical=0
[agent]
name=l_idx41_pctrl
database=pctrl
connect-timeout=86400
listener-maxport=4500
listener-minport=4387
[transition]
database-role=reverse
restart-after-transition=0
auto-begin-ai=1
transition-to-agents=l_idx41_pctrl
When I Restart Server and check status it is 1100 on source, 3104 on target. The port 38140 is the port the database is started on on the Target DB. That's correct is it not?
Any ideas?
38140 is indeed the -S port of/for the target db.
What does the pctrl.lg file say on the source side after the dsrutil pctrl -C restart server ?
1100 is connecting ....
It's not the properties, I used yours above for test and
2016/10/31@18:12:49.372+0100] P-14772 T-15748 I RPLS 6: (11251) The Replication Server successfully connected to all of it's configured Agents.
[2016/10/31@18:12:49.372+0100] P-14772 T-15748 I RPLS 6: (10436) The source database pctrl and the target database D:\repltest2\secondary\pctrl on host localhost are synchronized.
Looking for what you're asking for and found the following which I didn't find earlier:
[2016/10/31@16:26:54.816+0000] P-14908 T-15416 I RPLS 18: (-----) Connection timeout for host cmlsql03 port 38140 transport TCP.
[2016/10/31@16:27:44.818+0000] P-14908 T-15416 I RPLS 18: (-----) Connection timeout for host cmlsql03 port 38140 transport TCP.
[2016/10/31@16:27:52.819+0000] P-14908 T-15416 I RPLS 18: (10396) The Fathom Replication Server cannot connect to the database broker on cmlsql03 at the port -27396.
[2016/10/31@16:27:52.819+0000] P-14908 T-15416 I RPLS 18: (10397) The connection attempt to the Fathom Replication Agent l_idx41_pctrl failed.
[2016/10/31@16:27:52.819+0000] P-14908 T-15416 I RPLS 18: (11241) The Replication Server will continue to attempt Agent connections until Mon Nov 07 16:21:12 2016.
[2016/10/31@16:28:14.838+0000] P-6496 T-7964 I SRV 10: (742) Login usernum 90, userid PSLAdmin4 client type ABL , on CMLSQL01 using TCP/IP IPV4 address 127.0.0.1.
We have 9 databases in the application and 10.2B suffers from that horrible 'feature' where database connect/disconnect messages are written for all databases in the session to each db log file, so there's a lot of noise. Easy to miss stuff! :(
This would suggest that either target database is not started on 38140, or the agent is not running (I believe you said it was), or there is a firewall between source and target.
Thanks Libor. Fairly sure it's firewall related. Got to wait for the datacentre to think about investigating now.
Rather than create a new thread, it seems the datacentre hosting the client's servers is having a bit of a nightmare.
They tried to open the ports up on the firewall for this and ended up breaking connectivity for the application.
So, they want to have a definitive list of what ports need to be open in order for the application to work. Is it just the ports that the databases are running on, or are there others?
How can opening up the ports break the connectivity ? :-D
I don't know what does your app need port wise - aside of the client server that is.
For the replication itself between the source and target it would be:
port=38140
range from listener-minport=4387 to listener-maxport=4500 (you can tighten this up to like 2 ports range per DB set, if you are replicating more than 1 set of databases)
For the client-server connectivity it would be -S and range from (database) minport to (database) maxport.
if you have appserver/webspeed etc - there is more.
Thanks Libor. I suspect that they changed from a blacklist to a whitelist or something. They were meant to be opening up the connectivity between Source and Target, but broke the connectivity between the Citrix boxes and the source in the process. No idea what they did. Bit useless though.
The annoying thing is we get it in the neck. The datacentre never makes mistakes apparently.