SQL Server 2008 故障转移策略 - 日志传送还是复制？

Question

我们刚刚从 SQL Server 2000 迁移到 SQL Server 2008。

我们在 2000 上使用我们自己的日志传送进行故障转移。对于 2008 年，我们需要决定使用我们自己的日志传送、内置日志传送或复制。

我们的服务器上有很多数据库（400+）；有的小，有的大。

数据库服务器故障应该很少见，我们可以接受 15-30 分钟的数据丢失。更重要的是快速启动第二个数据库服务器。

根据上述标准，我更喜欢使用日志传送还是复制？

如果日志传送，是否有一种简单的方法可以确保它在所有数据库上移动？

Answer 1

对于所有建议镜像的人 - 不可能镜像 400 个数据库。无论是在 32 位还是 64 位上，您都会在达到 400 之前耗尽工作线程。主体上的每个数据库至少有 2 个工作线程，镜像上的每个数据库至少有 3 个。

真的和DBA的技能没有关系。这完全取决于业务或应用程序的 HA 要求是什么——这些是驱动因素，而不是 DBA 可以应付的。如果是一个更复杂的解决方案要求，然后让一名DBA，与它的交易也需要。由于 DBA 的技能而限制您的 HA 解决方案是荒谬的。

数据库镜像也不是快速检测和快速故障转移 - 它完全取决于故障是什么，镜像伙伴超时是什么，SEND 和 REDO 队列是什么。完成镜像决定成为主体的故障转移可能需要很长时间。我曾帮助许多客户实现镜像（包括在 Microsoft 时我拥有数据库镜像以及存储引擎的其余部分），以及自 2007 年离开以来。

忘记为该数量的数据库进行镜像。

在我们为您提供建议之前，您需要先回答一些基本问题：

• 你想要整个数据库的冗余副本还是只是部分？
• 您希望能够使用冗余副本吗？用于写入还是仅用于读取？
• 数据库的事务日志生成率是多少？
• 两个站点之间的网络带宽是多少？

日志传送对您来说可能是最简单的，无论是在设置、监控它还是能够在您的数据丢失限制内快速获取冗余副本。通过日志传送，您可以选择使冗余副本联机，而无需通过接受数据丢失来完成恢复排队等待恢复的所有事务日志备份。

您还可以使用中间层路由技术实现简单的故障转移，甚至可以像 Windows NLB 使用 0/100 配置或切换到 100/0 那样简单。我还看到客户在服务器名称无法更改时使用 DNS 切换来实现故障转移。

通过复制，您必须处理从发布 db 事务日志中获取的事务、命中分发数据库，​​然后由分发代理推/拉到订阅数据库之间的不可预测的延迟。复制也可能使自己陷入困境，并且很难弄清楚和重置 - 日志传送非常简单。

鉴于您一直在使用自己的日志传送，我猜测 tran 日志生成率和网络带宽不是问题 - 我会坚持使用日志传送并避免复制。甚至不要考虑数据库镜像，因为它不适用于您的卷。

希望这会有所帮助 - 当我向 Microsoft 内部的 DBA 教授 HA 时，这真的是两天的讨论时间 - 归结为 5 分钟回答这个问题。请随时在评论中提出更具体的问题。