Scenario:
I have a set of highly transactional OLTP databases on SQL Server 2008/Win2008 VMs. I need to establish a disaster recovery method that will minimize downtime and data loss both during the failover to secondary location and the subsequent failover
back to primary location once its up. Changing locations (making the old secondary into primary location and vice versa) is very cumbersome because of a million considerations outside the scope of this post, so I would prefer to have the DR location
as a temporary thing. Some of my databases have jobs, scheduled to run on a regular basis, that delete all rows in, and then re-populate certain tables, with millions of rows of data. Also, some tables are not cleared, but simply acquire a few
million of additional rows.
My assumption:
I figured that if I set up transactional replication with updatable subscriptions, all I would need to do in case of a disaster is change the server name in the connection string of my applications and I will continue running seamlessly. Then, once my primary location comes back up, I would revert the connection string to the original value, the subscriber will "reverse-replicate" all new data back to the publisher, and I am now seamlessly back to the original setup.
What actually happened:
That job that re-populates tables with millions of rows failed with the following error:
Msg 548, Level 16, State 2,The insert failed. It conflicted with an identity range check constraint in database [MyDatabase]
It appears that a new identity range couldn't be allocated fast enough, or that it failed to allocate at all.
My questions:
In my scenario, did I choose "Transactional replication with updatable subscriptions" correctly? If so - how can I make this work? If not - what would be the best DR scenario under the circumstances? I am trying to avoid the necessity of the backup-copy-restore operation into the primary location once the disaster is past, to minimize my downtime.
Any assistance in this would be greatly appreciated.