I have always handled identity management on merge replications manually. I have read over the papers on setting up automatic range management but I am not sure if I want to head in that direction or stay with the manual management.
My scenario:
I have two 2008 R2 servers in two seperate geographical locations. Server A is the primary server and Server B is the fail-over server. The only time that Server B is active and receiving data from a client is when there is a problem connecting to server A (Windows update reboot, connectivity issues, hardware issue, etc.). The vast majority of transactions will be done on Server A (roughly 300,000 per year)
With that in mind, I am trying to establish what my ranges should look like. I feel like the Publisher range size should be a high number (i.e. 10,000,000) mainly because I like to keep the incrementing key in a range that tells me where the insert was done (Server A vs. Server B). I then thought I should have the Subscriber set to 300,000 which should handle and failover events for some time.
Questions/Comment request
1. If I need to make changes to a table and have to stop replication, how would I handle the ranges? How does SQL Server handle the identities that have already been used on server A? Will it jump the the next 10,000,000 and start using ids in the 12,000,000 range?
2. If my ideas on the ranges above can be improved, please comment.
3. If I have an extended outage on Server A, what happens if I run out of IDs in the subscriber assigned range. I used a large number above to make sure I would not run out, is that a good way to handle it?
Thank you