How to handle identity columns in merge replications with no app effect
I have decided to scale my SQL Servers in an active-active scenario, but understand that in SQL Server clustering (active-active) both servers do not write to the same data files. Hence, I have decided to set up merge replication between the six tables in my database. Can you explain what is the best way to handle identity columns (all six tables have identity columns) in such a way that there is no effect on the application? Also, if you can recommend best practices for merge replication, I'd be very grateful.
Merge replication? In this case, it seems rather an odd application. There is a great deal of overhead associated with merge replication because this form of replication cannot read from the transaction log like snapshot and transactional replication. I strongly suggest that you use good ol' transactional replication to scale your application or use an application design that will balance the load over two or more servers.
As an aside, remember that clustering in all its forms (active-passive and active-active) is an availability solution, not a scalability solution. That is, clustering does not help the database scale to higher levels of performance, it only provides an added layer of redundancy to keep the database available to users during a crash.
This was first published in August 2005