Hello!
Per the subject, I've encountered a challenge on a couple of occasions where attempting to plan an upgrade of Active Roles in an environment that is leveraging SQL replication and happens to have a significant volume of change/management history data (e.g., 50-100GB or more). According tho the by-the-book process, you need to break replication, upgrade the publisher, import all of that change history data, re-establish replication, then wait for that change history to replicate from scratch. The replication burden is then multiplied by the number of subscribers in the environment. Even in an environment with good WAN links, you're probably talking a process that will take multiple days at best.
While I do realise that the Change History import process can import selectively based on age, I'm not expecting that to provide a overly significant result in the process.
Was hoping that there was some options for mitigating all of this. For example, it would be great if one could choose to upgrade each node simultaneously, and import the Change History on each node. That way, at least, the import process runs "locally", and once replication was re-established, it would only be a delta sync. Unfortunately I'm pretty sure that this isn't an option, however: I believe that the console will wipe out any existing databases/tables that may reside on the subscriber when you establish it as a replication partner, meaning that you have to replicate everything from scratch.
Anyone know if there is some way to adjust this behaviour? Force it to replicate with data that's already there?
Welcome any thoughts anyone might have to share!
Thanks.