Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I have two servers - one located in Australia (Distributor / Publisher), and a second in the UK (Subscriber) both on Amazon's cloud. I have attempted to configure replication as both pull and push with neither configuration giving me any joy. I have configured the security such that there is no TCP block between the two servers (with fixed IP addresses)

In the pull scenario, the UK server connects to the AU server okay, and fails to obtain the subscriber object list. It comes back with a TCP Semaphore issue and crashes out. I can't for the life of me figure out what would be causing that as I can connect to the AU server through the Management Studio without any issues at all and pull back some large queries.

In the push scenario, the AU server connects to the UK server and gets about half an hour into the initialization and then, on the same table, which disappears, every time, crashes out. The table itself is dropped - and a few times I've watched the process get to that point, see the table being dropped, and manually re-scripted it. After the table drops, the AU server reports a connection issue, and will reconnect in about 20 seconds - it's during that window I've attempted to recreate the table - it eventually crashes out with a message complaining. It's always the exact same table each time, which makes me think that it's not a network issue.

Anyone with some ideas here?

share|improve this question
    
You needs to enable verbose agent logging (support.microsoft.com/kb/312292). Add the parameters -OutputVerboseLevel 4 -Output C:\TEMP\mergeagent.log to the Merge Agent Run Agent job step. Re-run the Merge Agent and collect the log. I suspect it is a timeout issue. You may need to increase the Merge Agent -QueryTimeout parameter to a higher value. The default is 300 seconds, try bumping it up to 1800 seconds. –  Brandon Williams Feb 21 at 6:52
    
See if you can apply any of this to your situation -- sqlblog.com/blogs/argenis_fernandez/archive/2011/05/31/… –  DenisT Feb 21 at 15:30
    
Well it is (was) not a network / timeout related issue. I think part of the issue was the way I was syncing the snapshot file, but ultimately, the more I attempted to fix the issue, the worse state the distributor database got into. I ended up so far down the rabbit hole that the replication database couldn't perform basic functions. I've since rebuilt the server after backing up the db and moving it to a new location. A re-establishment of the syncing (minus a little data loss in the UK) has put the servers and replication back into commission. –  Rocksalt Feb 21 at 15:50
    
Just on the snapshot issue. I think at one stage I suspected that the snapshot that the subscriber was using to base it's logic off was an old version that was missing the table that was being dropped. It appeared that the new location for the snapshot wasn't being recognised which is why it was using an old data file, and consequently why I think the table was being dropped. –  Rocksalt Feb 21 at 15:52

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.