Ask ten database administrators (DBAs) how they define high availability (HA), and you’ll probably get ten different answers. We’re going to throw our own (informal) definition into the hat as well. In its simplest form, HA is about keeping your servers and their services up and running. HA is about making sure that end users do not experience hiccups in the operation of the system, and that the business can perform at an acceptable level. We use the term acceptable level, because one organization may consider an acceptable level to be 1 hour of downtime per week, while another may consider 1 second of downtime per week acceptable. It depends on the level of HA that you need. An effective HA strategy will ensure that the defined acceptable level of downtime is met. Downtime comes in one of the following two forms:
• Unplanned downtime: This is what most people are trying to avoid when they implement an HA solution. These are the dreaded crashes, power outages, and so on.
• Planned downtime: This includes activities like performing regular maintenance, patching, installing software, upgrading hardware, and similar tasks that you will know about in advance and can plan for accordingly. Most times, your downtime is planned rather than unplanned. Any HA strategy should try to help you minimize this type of downtime as well.
A term that goes hand in hand with HA is disaster recovery (DR), which is the means by which you protect your system against lost data and restore normal operations in the event of a system failure. DR is a piece of any HA strategy. Even after a disaster, you need to be able to get your system back up and running to achieve HA.
In essence, your DR strategy is your backup and restore strategy. For the highest level of DR, this involves a secondary site located some distance from the primary site. In the event that a catastrophic failure happens at the primary site, there is a failover to the secondary site. You can combine HA with DR to make servers in both the primary and secondary sites more bulletproof. DR is a key part of any overarching HA solution.
Many SQL Server technologies are available when implementing your HA/DR solutions. Database mirroring is the newest of these technologies. Other HA-related technologies include failover clustering, log shipping, and transactional replication.
Log shipping is one of the principles by which database mirroring operates. In other words, entries from a transaction log in one database are transferred and applied to another. When the database mirroring feature was originally being developed, it was called real-time log shipping. As development progressed, it made more sense to rename the feature to database mirroring, since, in effect, that is what the feature does. Most administrators understand disk mirroring in a Redundant Array of Inexpensive Disks (RAID) configuration, so the term database mirroring for SQL Server made sense.
The main advantages mirroring has over log shipping or transactional replication are that potential data loss is eliminated, automatic failover is enabled, and administration and monitoring are simplified. An interesting addition is the transparent client redirection.
Without this technology, developers would need to write custom code into their application to failover gracefully. It’s true that failover clustering provides automatic failover and client redirection, but mirroring is much easier to set up and use than clustering, which also requires specialized hardware. Additionally, mirroring provides a substantial decrease in potential downtime over clustering.
Source of Information : Apress Accelerated SQL Server 2008
• Unplanned downtime: This is what most people are trying to avoid when they implement an HA solution. These are the dreaded crashes, power outages, and so on.
• Planned downtime: This includes activities like performing regular maintenance, patching, installing software, upgrading hardware, and similar tasks that you will know about in advance and can plan for accordingly. Most times, your downtime is planned rather than unplanned. Any HA strategy should try to help you minimize this type of downtime as well.
A term that goes hand in hand with HA is disaster recovery (DR), which is the means by which you protect your system against lost data and restore normal operations in the event of a system failure. DR is a piece of any HA strategy. Even after a disaster, you need to be able to get your system back up and running to achieve HA.
In essence, your DR strategy is your backup and restore strategy. For the highest level of DR, this involves a secondary site located some distance from the primary site. In the event that a catastrophic failure happens at the primary site, there is a failover to the secondary site. You can combine HA with DR to make servers in both the primary and secondary sites more bulletproof. DR is a key part of any overarching HA solution.
Many SQL Server technologies are available when implementing your HA/DR solutions. Database mirroring is the newest of these technologies. Other HA-related technologies include failover clustering, log shipping, and transactional replication.
Log shipping is one of the principles by which database mirroring operates. In other words, entries from a transaction log in one database are transferred and applied to another. When the database mirroring feature was originally being developed, it was called real-time log shipping. As development progressed, it made more sense to rename the feature to database mirroring, since, in effect, that is what the feature does. Most administrators understand disk mirroring in a Redundant Array of Inexpensive Disks (RAID) configuration, so the term database mirroring for SQL Server made sense.
The main advantages mirroring has over log shipping or transactional replication are that potential data loss is eliminated, automatic failover is enabled, and administration and monitoring are simplified. An interesting addition is the transparent client redirection.
Without this technology, developers would need to write custom code into their application to failover gracefully. It’s true that failover clustering provides automatic failover and client redirection, but mirroring is much easier to set up and use than clustering, which also requires specialized hardware. Additionally, mirroring provides a substantial decrease in potential downtime over clustering.
Source of Information : Apress Accelerated SQL Server 2008
|
|
0 comments
Post a Comment