I have an application set up with transactional replication being pushed to a standby machine that will be used for emergency failovers. The replication appears to be working, any inserts made to Server 1 will automatically appear at Server 2.
However, I can't quite get the failover working. In the scenario that Server 1 becomes unavailable (which is the only scenario where Server 2 will ever be used, so the replication is one-way), the idea is that work should continue at Server 2, and that the transition should be somewhat seamless since all data has already been replicated.
But when moving to Server 2, after making sure that all updates on Server 1 have been transferred, I keep getting primary key violation exceptions, for some tables.<blockquote>
Violation of PRIMARY KEY constraint 'PK_TableA'. Cannot insert duplicate key in object 'dbo.TableA'.</blockquote>
A simple query such as
INSERT INTO TableA (Field1, Field2, TableB_ID) VALUES ('a','b', 6)
will yield the above error. It seems that when I instruct the table to assign an identity of its own, by omitting it from the query (
TableA has an
ID int identity(1,1) field), SQL Server will auto-assign an ID that violates a PK constraint. Why would this be?
TableA has a trigger for
DELETE that does a simple denormalization job
UPDATE TableB SET Count = (SELECT COUNT(1) FROM TableA WHERE TableB.ID = TableA.TableB_ID) WHERE ID IN( -- Fetch affected ID's from deleted or inserted rows SELECT DISTINCT TableB_ID FROM deleted UNION SELECT DISTINCT TableB_ID FROM inserted )
This was accidentally not a part of the Server 2 database at the time of the replication, and I inserted it afterwards. Consistency in the
TableB.Count field is not critical for the task at hand. The PK Violation occurred before the trigger existed in Server 2, as well as after creating it.
At both Publisher and Subscriber, the ID field that is yielding the violations has the following definition:
[ID] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL
I suppose the
NOT FOR REPLICATION part is redundant on the Publisher, as no replication job will ever write to it, but I can't see that it should be the cause of the problem, either.
IDENTITY ranges must be managed explicitly in a replication scenario.<ul><li><a href="http://msdn.microsoft.com/en-us/library/ms152543.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/ms152543.aspx</a></li> <li><a href="http://msdn.microsoft.com/en-us/library/ms151736.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/ms151736.aspx</a></li> </ul>
In your case you need to find, for each IDENTITY, a value larger than all current values.
Then you can configure one server to assign only odd numbers and the other only even numbers. JUst change the definition to IDENTITY(MAXPLUS1,2) on the publisher and IDENTITY(MAXPLUS2,2) on the subscriber.
Obviously you can extend this scheme to support any number of susbcribers.