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

Question

我正在为我的论文研究 SQL Server 上的高可用性。我了解到有几种解决方案可以存档：

• 故障转移集群
• 日志传送
• 复制

据我所知，以前版本的 SQL Server 2008 支持这些解决方案。 SQLS 2008 提供了数据库镜像，这被认为是更好的解决方案。我真的很怀疑这一点。您能否告诉我这些解决方案的优缺点，应该使用哪些策略，不应该使用哪些策略。详细信息和解释对我有很大帮助

非常感谢。

Answer 1

Brent 很好地介绍了日志传送和数据库镜像，因此我不会详细介绍。有关此主题的必读书籍是 Allan Hirt 的书Pro SQL Server 2005 High Availability。我知道这是 2005 年的情况，但它也与 SQL Server 2008 95% 相关。您必须阅读本文才能充分了解可用的选项。以下是我对布伦特回应的补充：

故障转移集群

如果财务、电力和服务器机房资源不是限制，那么这是我实现 SQL Server 高可用性的首选。您需要共享磁盘存储，通常是 SAN 才能正常工作，我更喜欢将 C 驱动器也放置在 SAN 上，以便于灾难恢复。我的设置方法是为集群中的每个 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 集群类似。优点是您不需要任何特殊的硬件来完成此操作，但软件许可证可能很昂贵。

备份还原

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