多用途故障转移服务器？

Question

我不是 DBA，所以这可能是一个愚蠢的问题，但我还是会问。我们正在将我们的 SQL Server 从 2000 年升级到 2005 年，我们可能会使用数据库复制或数据库镜像。我们的 DBA 想要“多用途”备用服务器，这意味着他想通过在备用服务器上运行其他数据库应用程序来增加我们的能力和容量，因为“它无论如何都会坐在那里”（他的话，不是我的话） .这是个好主意吗？目前，我们的主应用服务器只使用一个包含 50 多个数据库的实例。据我了解，我们现在正在做的事情以及我们的 DBA 为故障转移服务器提出的建议是一个坏主意，因为所有这些数据库都共享内存、CPU 和工作区域。如果一个应用程序开始表现不佳，其他数据库可能会受到影响。

有什么想法吗？

Answer 1

这真的是一个需要回答的商业问题？？如果您负担不起额外硬件的费用，那么一个缓慢的应用程序是否比没有应用程序更好？

备用数据库和镜像数据库可用于报告。如果您有足够的空间，可以将其用作故障转移数据库（即两个数据库都可以在服务器上轻松运行）

Answer 2

您会依赖这些额外的应用程序吗？它们在故障转移情况下运行在哪里？

Answer 3

你真的需要了解你的失败模式。

如果您将其视为基本的资源数学，那么这通常没有意义，除非您在故障场景中运行的资源可以处理整个预期负载。有时是这样，但并非总是如此。在这种情况下，要处理实际负载，您可能需要另一台服务器进入（例如 RAID - 也许您的负载需要至少 5 台服务器，但您有 6 台服务器场，那么您需要 1 台备用服务器来运行服务器1）以上失败。有时农场可能会退化，但有时它们会呕吐并死亡。

在运行不正常的情况下，您经常会发生事故级联，其中合法事件会导致一连串问题 - 例如您的备份磁带正忙于从备份恢复服务器（甚至 - 没有真正的“故障”），现在您的 sql 服务器或 exhcange 服务器（或两者）没有备份并且您的日志已满。

Answer 4

在我看来，数据库镜像不适合这样做，因为它仅在数据库级别提供冗余。因此，您需要根据您提供的信息为多达 50 个数据库配置数据库镜像。如果一个 DB 全部发生故障，则可能会出现 50 个故障，因为故障通常发生在硬件级别，而不是特定数据库。

在我看来，您应该使用 SQL Server 群集技术。您可以创建一个 Active/Active 集群来支持您的要求。

什么是 Active/Active 集群？

Active/Active SQL Server 集群意味着 SQL Server 在双向集群的两个节点上运行。每个 SQL Server 副本独立运行，用户看到两个不同的 SQL Server。如果群集中的一个 SQL Server 发生故障，则故障的 SQL Server 实例将故障转移到其余服务器。这意味着 SQL Server 的两个实例都将在一台物理服务器上运行，而不是两台。

将此应用到您的场景中

然后，您可以在两个 SQL Server 实例之间拆分数据库，每个节点上都有一个活动实例。如果一个节点发生故障，另一个节点将接手，反之亦然。

进一步阅读

An introduction to SQL Server Clustering

I suspect that you will find the following MSDN thread useful reading also

Answer 5

“无论如何它都会坐在那里”

它将坐在那里应用事务...

注意 John Sansom 的建议。请记住，Active/Active 集群需要两个 sql server 许可证，而故障转移集群/镜像只需要一个。

为大量数据库设置镜像可能会变得很痛苦。您还需要任何工作/维护来转移 - 这可以通过 WMI 故障转移事件的警报来实现。可能还有更多需要考虑的事情可能会使事情复杂化。