Things that keep me up at night

This is a follow on from my previous post , about how I replaced the mirror in a SQL Mirror set, all the while keeping replication flowing. In this episode, we'll explore how to move the primary server in the mirror, which is also the publisher of a bunch of publications, onto new hardware. Unlike the mirror, because the primary is the publisher, it s replacement must use the same NetBIOS name  as the machine being replaced. Note, it doesn't need the same IP - just the same NetBIOS/hostname. This can be understandably difficult if both machines need go on the same domain. In this instance, don't join the new hardware to the domain just yet and uncheck the boxes about automatically registering itself in DNS, under the network hardware settings. The first steps are to backup both the service master key and the database master keys. Remember to snag the master databases  master key as well as the published/mirrored databases master key. You must also make sure the disk...

So, as with most technical "support" available a Google search away, the literature about SQL Server Replication and Mirroring is mostly inaccurate and, worse yet, in some instances it will cause you significant data loss and heartache. This small mini series uncovers the truth about SQL Server and how mirroring and replication interact. I understand that mirroring has been deprecated for AlwaysOn Availability Groups - I'm sure I'll have something to say when I do one of those migrations. Anyway, I recently had cause to do a hardware refresh on a SQL mirror pair that was also configured as a replication publisher. In this instance, for reasons I don't fully remember, I provisioned a new mirror server, made sure the SQL version and patch level matched, broke the original mirror and re-established it to the "new" mirror hardware. And this worked fine. All you need to remember to do is update the replication Log Reader Agent and Snapshot Agent's -...