Yes, I know synchronisation to alternate partners is deprecated in SQL2005 but....
In SQL2000 there is a Sync Partners tab in the publication properties dialog that allows you tick a checkbox for each co-publisher to be enabled as an alternate synchronisation partner. What is the equivalent in SQL2005?
I've set up replication in SQL2000 following these instructions http://support.microsoft.com/?kbid=321176 and it works. Now I'm trying to do the same thing in SQL2005 but I can't find a substitute for steps 10 & 11 in the section "Set Up the Alternate Synchronisation Partner". What's the answer?
Thanks in advance.
As you mention that alternate sync partners is deprecated, there is no furhter development for this feature. You can use what is available in SQL 2005 (using stored procedures) but again I would not count on it working the way it used to in SQL 2000.|||Will Windows Server 2003 Clustering with SQL Server Clustering able to help? Such as having a cluster server for publisher and a cluster server for subscriber on active/active mode. Will this able to increase the performance, such as when a either publisher / subscriber is busy, it will look for the cluster server among them and sync the data.
Pls let me know your thought.
Thanks
|||You could try clustering, which can provide you some relief when server (node) goes down, but you should know that it comes at a price of extra administration and will still not replace the alternate sync partners behavior that you were looking for.
If you do not have high number of nodes in your topology and always need up-to-date data you should probably also look at Transactional Peer-to-Peer replication. But if you are currently using the conflict handling and other merge replication features, this may not be a solution.
|||Imagine a situation in which a server at head office replicates information to branch office servers over very slow lines. The branch office servers republish the data and the travelling workforce sync their laptops before they go out for the day and sync them again when they get back. Sometimes they return to a different office from the one they started out in (and they don't always know that's going to happen) but there's no link between the branch offices.
Synchronisation to alternate partners works quite well in this situation. What other solutions are there? Please don't suggest changing any part of the problem as that's not an option.
|||Unfortunately alternate sync partners is deprecated and will not be supported in the next release.
If the traveling workforce will have internet connection, you should look at Web Synchronization in SQL 2005.
That way, the traveling workforce need not always go to the same office to sync with the dedicated branch office. They can go to any of the branch offices but still sync with the brnach office off of which they subscriber using the internet connection.
|||The problem is that it is deprecated, just like a couple of other replication features that are being used in organizations.
This is one feature deprecation that I don't agree with. Unfortunately, there aren't any options and there aren't any replacements to this functionality. I use it very extensively in a few very large merge architectures. The basic scenario essentially boils down to what you are using it for. Basically, you are allowing synchronization to route around the unavailability of the primary publisher for a subscription. Whether that is a traveling workforce in your case or it is to route entire sections of a merge hierarchy around outages (my scenarios), it is really the same core capability.
Web synchronization is not acceptable in my case, because it can not handle the load in the first place and in the second place it is not an infrastructure option that is available.
I'm still trying to find a way around this so that I can continue to use it, but I haven't gotten everything wired together properly and it requires very significant hacking of the replication metadata tables to even get part way there.
The only suggestion that I have is the product feedback center. It would have been nice to have an alternative if the feature was deprecated, but there aren't any alternatives.
|||ok, here is another thought. You could have your publisher (or republisher) machine A run mirroring with another server B and make this mirror setup replication aware.
So your subscriber will sync with say machine A and then when machine A goes down for some reason, machine B now becomes the active machine and your subscriber can now sync with machine B. When machine A resumes back, your susbscribers can continue to sync with mahcine A.
The caveat in this setup is that your republisher machine B will not be able to sync with its (root) publisher. Only machine A will be able to do so.
|||Database Mirroring doesn't work with the publisher, although it does work with the distributor or subscriber. Been trying to force feed that one for almost a year now and haven't gotten anything working yet.|||Database Mirroring should be working for the publisher machine.
Please let us know what issue you are encountering when you are trying to set it up.
