多用途故障转移服务器？

Question

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

有什么想法吗？

Answer 1

这真的是一个需要回答的商业问题吗？如果您无法承担额外硬件的费用，那么它是一个比app更慢的应用程序吗？

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

Answer 2

您会依赖这些额外的申请吗？他们在故障转移案例中运行在哪里？

Answer 3

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

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

如果出现正常操作，您通常会在合法事件导致一连串问题的情况下发生事故级联 - 例如您的备份磁带正忙于从备份恢复服务器（甚至是 - 没有真正的“失败”），现在您的sql server或exhcange服务器（或两者）都没有备份，您的日志已满。< / p>

Answer 4

数据库镜像不是我认为的方式，因为它仅在数据库级别提供冗余。因此，您需要根据您提供的信息为最多50个数据库配置数据库镜像。很可能如果一个数据库在哪里失败，那么50可能会跟随，因为失败通常发生在硬件级而不是特定数据库。

听起来我应该使用SQL Server群集技术。您可以创建一个主动/主动群集来支持您的要求。

什么是主动/主动群集？

主动/主动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的建议。请记住，主动/主动群集需要两个sql server许可证，而故障转移群集/镜像只需要一个。

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