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 -PublisherFailoverPartner agent parameter to the new mirror's hostname and all is well.
Note however that if you do choose this method to replace the mirror partner, you absolutely MUST NOT do as the Microsoft Guide says in Step 3 of their guide, and that is -
And because replication is so reliant on the NetBIOS names of the publisher, distributor and subscribers, you can't practically perform much replication maintenance while on a mirror server either, as apart from the agents that support the failover partner parameter (because they are using the ADO driver for a connection) , most operations will be looking to the publisher do anything, and it will be offline or the database will be in recovery mode.
One caveat here - if you did setup your mirror and publications correctly in the first place, you could, instead of replacing your mirror with a new machine with a new hostname, simply do a "DR" style replacement of your mirror by restoring the master and msdb databases and copying the mirrored databases files over. This is the method I used to replace the mirror master and publisher of this setup and will be covered in my next article.
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 -PublisherFailoverPartner agent parameter to the new mirror's hostname and all is well.
Note however that if you do choose this method to replace the mirror partner, you absolutely MUST NOT do as the Microsoft Guide says in Step 3 of their guide, and that is -
execute sp_adddistributor at the mirrorIf you do this, when there is a publication already up and running, you will DESTROY REPLICATION. The time to run sp_adddistributor at the mirror is in a new environment where you are just setting up mirroring and publications. The Log Reader Agent will still work without doing this, in a failover scenario. And practically, failing over to the mirror is a temporary thing - it's unlikely you have your SQL jobs etc set up to run on both. So you will never be on the mirror for an extended period of time and if the log reader is churning away, happy days.
And because replication is so reliant on the NetBIOS names of the publisher, distributor and subscribers, you can't practically perform much replication maintenance while on a mirror server either, as apart from the agents that support the failover partner parameter (because they are using the ADO driver for a connection) , most operations will be looking to the publisher do anything, and it will be offline or the database will be in recovery mode.
One caveat here - if you did setup your mirror and publications correctly in the first place, you could, instead of replacing your mirror with a new machine with a new hostname, simply do a "DR" style replacement of your mirror by restoring the master and msdb databases and copying the mirrored databases files over. This is the method I used to replace the mirror master and publisher of this setup and will be covered in my next article.
salt likit
ReplyDeletesalt likit
dr mood likit
big boss likit
dl likit
dark likit
SWP38