0

We have an active/active cluster on LUNs (with one named instance on each node and a total of an 100 DBs)

For DR purpose, LUNs will be replicated (with same drive letters) and attached to a standalone server with same configuration of SQL Server but not same Windows Server editions (enterprise vs standard, but i don't think it may be an issue), and the two same named instances pre-installed.

I proposed the Attach / Detach solution, with a script that auto-generate the attach / detach to simplify the tasks, and other scripts to copy Logins, jobs and so on.

Other DBA said a better option will be to rename the MASTER and MSDB databases from the pre-installed named instances on standalone server with _old, and to attach the MASTER / MSDB databases from Cluster node instance to both corresponding named instance in standalone instance.

He said it works and had tested it.

However, I've never heard of such a solution nor can i find any documentation of it.

I would like to hear some other opinions.

Thank you, Kukah

Improve this question
2
  • 4
    From start to finish, however many times I read it, this doesn't make any sense. Your DR solution is a frankenstein monster of replicated LUNS, attach/detach scripts, and something I can't comprehend involving renaming master and msdb?
    – Mark Storey-Smith
    Commented May 4, 2013 at 1:16
  • @MarkStorey-Smith I totally agree about the frankenstein monster DR. I haven't designed that DR. It comes from our project department. Maybe a picture would help to understand better tinypic.com/r/21lqv6r/5
    – user23398
    Commented May 4, 2013 at 22:40

1 Answer 1

Reset to default
3

I'd stay away from the scripting and detach/attach methods. I've done two migrations in the past nine months and was convinced that a better method would be to backup and restore the databases. That way you have a last-known good configuration point-in-time restore.

So here's my thought process.

  1. Restart the source instance in single-user mode
  2. Backup your databases WITH COPY_ONLY, COMPRESSION
  3. Stop the old instance. Take it offline. Pull the network cables, if you must.
  4. Restart the new instance in single-user mode
  5. Restore master
  6. Change the location of tempdb (see below)
  7. Restore model and msdb
  8. Restart the instance.
  9. Restore your user databases.

Please note that you will need to do some cleanup on the instance names since you're moving from what I assume will be a named instance from your Multi-Instance Cluster to what I assume will be the default instance on a dedicated piece of hardware.

I may have misunderstood what you meant by "replicated." Do you mean that you're going to provision LUNs of the same size (you've already mentioned letters) on your SAN that you attach to new hardware? In this case, you're not describing a DR scenario at all. You're simply describing the provisioning of hardware for your new SQL instance. Disaster recovery would be how you plan to recover from the failure of these instances.

Naturally you know that you're moving away from a High Availability solution. I hope you're not relying on your SAN to do both HA and DR.

Improve this answer
1
  • Thank you for the recommendation and the step by step. Both Instances on the standalone server will be pre-installed and will have the same names has on the cluster. Yes I know we are moving away from HA solution and I don't really understand either what the point of this DR. My guess is that they want to test both Cluster and LUNs1 failure at the same time, using the replication LUNs2 and standalone as DR solution.
    – user23398
    Commented May 4, 2013 at 22:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.