February 18, 2015 at 10:20 am
We have been planning on implementing some kind of DR strategy, but we are still not sure which one to implement. We have thought about the log shipping, but I don't know if it will serve the purpose or not. If we are concerned about high availability, we should go with mirroring, replication, clustering etc, but then again what are some of the pros and cons? Which will be cost effective? Any advise will be highly appreciated.
"He who learns for the sake of haughtiness, dies ignorant. He who learns only to talk, rather than to act, dies a hyprocite. He who learns for the mere sake of debating, dies irreligious. He who learns only to accumulate wealth, dies an atheist. And he who learns for the sake of action, dies a mystic."[/i]
February 18, 2015 at 11:20 am
I would not look to replication as a DR or HA solution. It's mainly for data distribution for reporting, stuff like that.
Then, you need to break down HA and DR into separate stacks too. Failover clustering and availability groups both have automatic mechanisms for high availability. No changes are necessary in code or connection strings to ensure that you get to the right database on the right server using one these. Mirroring doesn't have the same mechanisms. You would have to modify code and/or connection strings to ensure you're going to the secondary database in the event the first went offline.
Disaster Recovery is the ability to have a second location, but that's not necessarily highly available. Clustering and AG can both work within this, as can mirroring. You can also look to log shipping (actually a form of mirroring) VM snapshots and disk snapshots, all as mechanisms for DR. Just simple backups are also an important part of any DR strategy.
As to the strengths and weaknesses of each, that's actually not the way to go about it. Instead, you need to get a full understanding from the business exactly what's expected in terms of HA & DR. Then, you can explain what each of the different mechanisms can do, what they'll cost, and determine if that meets the needs of the business.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 18, 2015 at 11:24 am
Grant Fritchey (2/18/2015)
I would not look to replication as a DR or HA solution. It's mainly for data distribution for reporting, stuff like that.Then, you need to break down HA and DR into separate stacks too. Failover clustering and availability groups both have automatic mechanisms for high availability. No changes are necessary in code or connection strings to ensure that you get to the right database on the right server using one these. Mirroring doesn't have the same mechanisms. You would have to modify code and/or connection strings to ensure you're going to the secondary database in the event the first went offline.
Disaster Recovery is the ability to have a second location, but that's not necessarily highly available. Clustering and AG can both work within this, as can mirroring. You can also look to log shipping (actually a form of mirroring) VM snapshots and disk snapshots, all as mechanisms for DR. Just simple backups are also an important part of any DR strategy.
As to the strengths and weaknesses of each, that's actually not the way to go about it. Instead, you need to get a full understanding from the business exactly what's expected in terms of HA & DR. Then, you can explain what each of the different mechanisms can do, what they'll cost, and determine if that meets the needs of the business.
Thanks for all the information Grant. I really appreciate that.
"He who learns for the sake of haughtiness, dies ignorant. He who learns only to talk, rather than to act, dies a hyprocite. He who learns for the mere sake of debating, dies irreligious. He who learns only to accumulate wealth, dies an atheist. And he who learns for the sake of action, dies a mystic."[/i]
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply