January 25, 2006 at 10:26 am
I have an ASP.NET web app running on a remote server drawing data from a remote SQL Server 2000. I have a local server on which I want to intstall the web app and SQL Server 2000. I want to set up replication so that if the remote sql server goes down for any reason, the data can be drawn from the local sql server by the web app.
The web app is allowing users to read and updte data so the replication type must be updating the local server as the remote server is in use. When the remote server goes down, I need to switch the web app to use the local server but once the remote server is up again, the new transactions on the local server need to be updated to the remote server.
Which kind of replication do I need for this and is this doable? Right now, it seems that I'd have to do a one way type of replication and then DTS back to the remote server once it comes back up.
Thanks in advance...
January 26, 2006 at 7:47 am
Assuming I understand what you're trying to do, Merge Replication is the only way you can have changes on the subscriber replicate back to the publisher.
January 26, 2006 at 7:57 am
HI Larry, we have a similar situation - we have used transaction shipping to (in your case) the local server. The shipping log is implemented by the production server's maintenance Plan. Try look at the article located on: http://www.microsoft.com/technet/prodtechnol/sql/2000/reskit/part4/c1361.mspx.
Regards
James
January 26, 2006 at 4:17 pm
Not meaning to hijack Larry's thread, but we have a similar requirement and I thought my questions might help here too. If you think it's better that I start a new thread, let me know.
We are looking to achieve the same type of solution, with an ASP.NET front-end and SQL Server back-end and we also wwant to establish a backup server that can be easily employed to replace the Primary if needed.
I've been reading up on Replication, Log Shipping (thanks to James for that link - it's a good article) and Failover Clustering, and I'm not really much closer to deciding which way to go.
I guess our decision has to factor in the amount of transactions, size of log files, cost of setting up servers and then maintaining them and the amount of data traffic. So here are my questions:
"The main reason for using log shipping with replication is to provide protection in the event of a Publisher failure"
...but I thought that in a Replication environment the Subscriber server would be up-to-date (or close to) when the Publisher went down.
Anyway, thanks for taking the time to read this and I'd appreciate reading anyone's experiences in this or any suggested articles.
Tony
January 26, 2006 at 6:27 pm
Hi Tony et al,
I'm not sure about Q1. In Q2, my assumption is that one of the other can be the monitor.
I had the same question you had in Q3. We don't have Enterprise Edition and from the article it seems that you need at least one instance of EE to use log shipping. Is this true? If so, can I achieve something similar with replication? It seems that if I use some type of replication on a frequent basis, with the identity keys in tact, I should be able to fall over to the backup server. When the remote server comes back online, I could then DTS or backup and restore from the local to the remote. This seems a bit dangerous as there can be some user error in the process and down time may be a bit longer than desired but wouldn't this work?
Thanks...
Larry
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply