SQL Server 上的高可用性，解决方案的优缺点？

Question 1

Brent 很好地介绍了日志传送和数据库镜像，所以我就不多说了。关于这个主题的必读书籍是 Allan Hirt 的书Pro SQL Server 2005 高可用性。我知道这是针对 2005 的，但它也与 SQL Server 2008 有 95% 的相关性。您必须阅读本文才能很好地了解可用的选项。以下是我对 Brent 的回复的补充：

故障转移群集

如果财务、电力和服务器机房资源不受限制，那么这是我为 SQL Server 实现高可用性的首选。您需要共享磁盘存储（通常是 SAN）才能实现此功能，而且我更喜欢将 C 驱动器也放在 SAN 上，以便于 DR。我设置的方法是让群集中的每个 SQL Server 实例都有一个仲裁 LUN (Q)、一个 MSDTC LUN (M) 和一个挂载点。在挂载点内，为 SQLData、SQLLogs、SQLBackups 和可选的 SQLtempdb 设置一个 LUN。对于一个实例，您将得到 D:\SQLData、D:\SQLLogs、D:\SQLBackups、D:\SQLtempdb（例如）。对于下一个实例，您可能有 E:\SQLData、E:\SQLLogs、E:\SQLBackups、E:\SQLtempdb。所有共享磁盘都需要呈现给群集中的所有节点。故障转移是自动的，在我的生产环境中大约需要 20 秒。它很强大，但如果您缺乏经验，设置起来可能会很棘手。

虚拟化 SQL 服务器

您尚未探索的一个选项是使用 vmware ESX 服务器来托管您的数据库服务器。我真的很喜欢这个选项，但还没有信心在生产环境中部署它。我已经在非生产环境中非常成功地部署了它，而且这项技术非常出色。我认为它只适用于中等到轻负载的 SQL Server，如果性能至关重要或您的工作量很大，则不应使用它。SQL Server 到 ESX 主机的一对一映射是一种非常理想的配置。vmware VMotion 是一项很棒的技术，其停机时间比故障转移群集短得多。我曾经看过一个演示，视频在服务器上播放，服务器故障转移后视频运行顺畅。现在，这令人印象深刻！

SQL Server 复制

这可能不适用于第三方应用程序，因为它可能需要更改架构。SQL Server 复制并非为高可用性而设计，而是为在其他位置提供数据副本而设计。由于其复杂性，我不建议将其用于高可用性。但是，由于它提供的粒度级别较低，因此在某些情况下它可能很有用 - 例如，您可以对数据进行水平和垂直分区。

第三方磁盘复制

也可以考虑使用诸如 NSI 的 double take 之类的解决方案来实现高可用性，但我更喜欢将其用于非基于 SAN 的系统的灾难恢复。它基本上将数据以块级别复制到目标服务器，目标服务器监视源服务器的可用性。如果源服务器不可用，它会触发故障转移条件，您可以将其设置为自动故障转移或警报以进行手动故障转移。故障转移时间与 SQL Server 群集相似。优点是您不需要任何特殊硬件即可完成此操作，但软件许可证可能很昂贵。

备份还原

这不是真正的高可用性解决方案，但对于要求较宽松的人来说，这个非常简单的解决方案可能满足您的所有需求。只需按计划将数据库备份到备份服务器，并确保备份文件在目标计算机上可用。设置一个作业来恢复备份的文件，这样您就可以以低成本获得一个粗糙的高可用性解决方案。

Answer

Brent 很好地介绍了日志传送和数据库镜像，所以我就不多说了。关于这个主题的必读书籍是 Allan Hirt 的书Pro SQL Server 2005 高可用性。我知道这是针对 2005 的，但它也与 SQL Server 2008 有 95% 的相关性。您必须阅读本文才能很好地了解可用的选项。以下是我对 Brent 的回复的补充：

故障转移群集

如果财务、电力和服务器机房资源不受限制，那么这是我为 SQL Server 实现高可用性的首选。您需要共享磁盘存储（通常是 SAN）才能实现此功能，而且我更喜欢将 C 驱动器也放在 SAN 上，以便于 DR。我设置的方法是让群集中的每个 SQL Server 实例都有一个仲裁 LUN (Q)、一个 MSDTC LUN (M) 和一个挂载点。在挂载点内，为 SQLData、SQLLogs、SQLBackups 和可选的 SQLtempdb 设置一个 LUN。对于一个实例，您将得到 D:\SQLData、D:\SQLLogs、D:\SQLBackups、D:\SQLtempdb（例如）。对于下一个实例，您可能有 E:\SQLData、E:\SQLLogs、E:\SQLBackups、E:\SQLtempdb。所有共享磁盘都需要呈现给群集中的所有节点。故障转移是自动的，在我的生产环境中大约需要 20 秒。它很强大，但如果您缺乏经验，设置起来可能会很棘手。

虚拟化 SQL 服务器

您尚未探索的一个选项是使用 vmware ESX 服务器来托管您的数据库服务器。我真的很喜欢这个选项，但还没有信心在生产环境中部署它。我已经在非生产环境中非常成功地部署了它，而且这项技术非常出色。我认为它只适用于中等到轻负载的 SQL Server，如果性能至关重要或您的工作量很大，则不应使用它。SQL Server 到 ESX 主机的一对一映射是一种非常理想的配置。vmware VMotion 是一项很棒的技术，其停机时间比故障转移群集短得多。我曾经看过一个演示，视频在服务器上播放，服务器故障转移后视频运行顺畅。现在，这令人印象深刻！

SQL Server 复制

这可能不适用于第三方应用程序，因为它可能需要更改架构。SQL Server 复制并非为高可用性而设计，而是为在其他位置提供数据副本而设计。由于其复杂性，我不建议将其用于高可用性。但是，由于它提供的粒度级别较低，因此在某些情况下它可能很有用 - 例如，您可以对数据进行水平和垂直分区。

第三方磁盘复制

也可以考虑使用诸如 NSI 的 double take 之类的解决方案来实现高可用性，但我更喜欢将其用于非基于 SAN 的系统的灾难恢复。它基本上将数据以块级别复制到目标服务器，目标服务器监视源服务器的可用性。如果源服务器不可用，它会触发故障转移条件，您可以将其设置为自动故障转移或警报以进行手动故障转移。故障转移时间与 SQL Server 群集相似。优点是您不需要任何特殊硬件即可完成此操作，但软件许可证可能很昂贵。

备份还原

这不是真正的高可用性解决方案，但对于要求较宽松的人来说，这个非常简单的解决方案可能满足您的所有需求。只需按计划将数据库备份到备份服务器，并确保备份文件在目标计算机上可用。设置一个作业来恢复备份的文件，这样您就可以以低成本获得一个粗糙的高可用性解决方案。

Question 2

日志传送：

概述：主服务器上的事务排队到磁盘，然后根据复制计划发送到镜像服务器。日志根据计划应用于镜像数据库。

SQL版本：标准版、企业版

管理员工作：在镜像上设置网络共享作为事务日志的放置位置，运行 SQL 向导进行设置

自动故障转移：除非有见证服务器，否则不可能

手动故障转移：涉及将未提交的事务日志文件应用于数据库

故障问题：中等，因为它依赖 Windows 在镜像上呈现网络共享。如果镜像上的事务日志应用程序停止，它们将累积

I/O：高于镜像

镜像：

概述：主体上的事务在主体上提交并发送到镜像。当镜像提交事务时，它会告诉主体它已准备好进行另一项事务。

SQL 版本：企业版

自动故障转移：除非有见证服务器，否则无法实现

手动故障转移：如果存在连接，则将镜像模式切换为同步。如果没有连接，则发出 SQL 语句以执行强制服务还原。然后可以重新同步对

性能：与日志传送相比较低

个人实验室工作：

使用 SQL 2005 Standard 和 Enterprise 进行。

我发现日志传送在理论上是个好主意，但在我的实验室中设置和执行故障转移却很复杂。镜像非常优雅，而且我确实知道事务已提交给两对。

当需要将目标服务器作为主服务器启动时，我不想不得不修改应用事务日志文件。如果您需要较短的 RTO，我会尝试镜像。

您需要详细了解同步（在标记为完成之前将事务提交给两个对）与异步（在主体上提交，然后发送到目标）复制模式的镜像对。使用 LAN，您可以在同步模式下运行它们，但在 WAN 上，您必须在同步模式下观察延迟（低于 10-20 毫秒），否则您对应用程序的响应时间会变慢。

注意只有 SQL 2005 企业版支持异步，也称为“高性能模式”或在 SQL 服务器上将 SAFETY 属性“关闭”。

抱歉，我没有任何集群经验。

MSDN 来源

数据库镜像概述 http://msdn.microsoft.com/en-us/library/ms189852%28SQL.90%29.aspx

Answer