What are the implications of server clustering on replication?
Replications works with SQL Server 7.0, SQL Server 2000, and SQL Server 2005 clustering. But as you might well imagine, configuring and maintaining a SQL Server cluster that is also involved in replication can be a headache.
Whether or not you decide to cluster SQL Servers involved in replication has to do with how important the servers are to your enterprise. If they are mission critical and your business cannot function without them, you will probably want to cluster your SQL Servers. At the same time, you will also have to accept the extra added dimension of complexity that is involved.
If you are going to implement replication and the SQL Server cluster will participate as a Publisher and a Distributor, use a file share located on the cluster disk resource as the snapshot folder. This way, replication will failover when SQL Server fails over.
When you configure a clustered SQL Server as a Distributor, SQL Server needs to have access to a snapshot folder as a temporary holding place during the replication process. In order to ensure that replication still works when failover occurs, this folder must be located on a shared folder on the cluster’s shared disk resource. If it is not, then when failover occurs, replication may stop working.
You will have to manually create the required folder on the shared disk resource, and additionally create the necessary share with appropriate permissions. In addition, you will have to configure the shared folder using Cluster administrator as a clustered shared folder.
If you don’t want to do the above, one option is to not make the clustered SQL Server a Distributor, but only a Publisher, and locate the Distributor on a non-clustered SQL Server. This way, the snapshot folder will exit on a non-clustered SQL Server, negating the above advice.