地理数据库同步镜像

Question

我们公司的一位架构师设计了一个基于64位SQL2005标准版同步镜像的解决方案，在物理（4个四核，32GB RAM）服务器和虚拟DR服务器（4个虚拟CPU，16GB RAM）之间的两个地理远程数据中心之间见证服务器（1 个虚拟 CPU）。两个数据中心的存储都是企业级 SAN。

前端应用程序面向 Web，具有混合读/写用法。

作为一名 DBA（在设计阶段没有咨询过他），我担心这种配置的设计以最大限度地减少冗余为主要标准，并且它不会作为现实世界的解决方案工作 - 网络延迟和虚拟性能box 会导致不可接受的响应时间吗？如果调用故障转移，则性能甚至会更差。

有没有人有类似设置的经验？

Answer 1

Microsoft 发布了一份关于数据库镜像的非常好的白皮书，其中包含一些很好的示例，说明同步镜像对性能的影响有多大。您完全正确，因为性能会受到影响。执行从主框到数据库镜像的 ping 操作，并查看以毫秒为单位的往返时间：这将是同步镜像将添加的绝对最小开销。ping 甚至不考虑远程服务器处理每个传入事务所需的时间 - 这纯粹是网络延迟时间。

您添加的网络延迟越多，性能就越慢，硬件只是闲置：

替代文本 http://i.technet.microsoft.com/Cc917681.dbm_fig09(en-us,TechNet.10).gif

我是异步镜像的忠实粉丝，因为这是添加一些保护的简单方法，但保护可能会落后。这是一件好事也是一件坏事：它是好的，因为它可以处理网络延迟，但它是坏的，因为您可能会丢失任何尚未转移到故障转移站点的数据。

此外，当您设计数据库镜像解决方案（无论是同步还是异步）时，请务必考虑您的索引维护操作。如果您每周进行索引重建，那绝对会杀死您的镜像积压，因为它们会产生大量必须通过网络传输的记录活动。

Answer 2

虽然网络带宽发挥了很大的作用，但绝对要考虑的首要因素是主体上的事务日志生成率是多少？

如果应用程序和您的维护没有生成任何事务日志，那么网络带宽就真的无关紧要了。如果确实生成日志，则网络带宽必须能够处理生成的日志量。

为了回答您的实际问题，如果主体上没有大量 OLTP 工作负载，您的硬件配置可能会起作用（网络问题除外）。如果有，并且您有 4x4 处理器内核生成事务日志，那么您的镜像服务器很可能无法跟上重放日志的速度，无论您的网络是否可以处理日志流量。在标准版上，有一个线程处理镜像上日志的重做 - 因此您的重做队列在重负载下会变得非常大。

REDO 队列是已在镜像上强化但尚未在镜像数据库中重放的日志量 - 它越大，在发生故障转移时，镜像数据库作为主体上线的时间就越长. 这在标准版中尤其麻烦，因为您没有并行重做和快速恢复（数据库在 REDO 之后和 UNDO 之前联机）等功能可用。

而且，当然，在从主体到镜像的故障转移之后，镜像将无法为与主体服务器相同的工作负载提供服务——所以你会在那里，但运行速度可能会慢很多。

希望这可以帮助。