SQL Server 镜像有多智能？

Posted 2023-03-23

【中文标题】SQL Server 镜像有多智能？

【英文标题】：How intelligent is SQL Server Mirroring?

【发布时间】：2013-09-05 15:27:35

【问题描述】：

在开发我当前的开发产品时，我已经在主数据中心和辅助数据中心之间设置了 SQL 服务器镜像。在主数据中心，SQL .mdf 和 .ldf 文件存储在 SAN 上。

现在我们承认丢失 SAN 的可能性很小，但是如果与 SAN 的连接丢失并且数据库完整性丢失。镜像还会发生吗？ IE。 SQL 现在会镜像损坏的数据库，现在两者都同样损坏了吗？

通过谷歌搜索不清楚镜像何时会发生和不会发生，所以我希望社区能够分享其中的一些经验。

我还设置了备份计划，这将是最终的故障保险，但实际上我希望镜像数据库将是我们让所有内容恢复在线的最快方式。

在这种情况下，目前在镜像过程中没有见证服务器，尽管我正在考虑添加一个自动故障转移的好处。

谢谢

【参考方案1】：

就 PRIMARY 和 SECONDARY 之间的镜像损坏而言：不幸的是，这取决于。如果损坏是即时的和物理的，那么通常不会 - 通常在事务结束时进行的检查会发现损坏并回滚。

但是，数据库可能会以损坏状态存在一段时间，然后才会意识到它已损坏。如果底层数据页没有被触及，引擎永远没有理由去检查它们。因此，潜在的存储问题可能意味着任一数据库都可能损坏，并且在您尝试访问受影响的页面之前您不会知道。传统上，这将是一个写操作，因为您的客户端连接只会从当前活动的数据库（而不是合作伙伴）中读取。

这就是对数据库执行定期维护检查很重要的原因（例如DBCC CHECKDB）。这在镜像环境中变得更加困难，因为通常只能检查 PRIMARY，因此您确实必须引发手动故障转移来测试您的 SECONDARY（除非您正在运行 Enterprise，您可能镜像并检查——我没试过）。

从 SQL Server 2008 开始，引擎将尝试称为“自动页面修复”的操作，尝试自动恢复在镜像过程中遇到的损坏页面。如果这是您担心的事情，您可能应该关注sys.dm_db_mirroring_auto_page_repair。

如果是逻辑损坏，输入了错误的数据，这将推送到 SECONDARY 而没有任何阻止它的方法。

但是，我应该指出，您的方法可能会给您带来其他问题。镜像不是备份。而且镜像在 WAN 链接上也不是很好。

在同步模式下，它接收客户端请求，然后写入 PRIMARY，然后写入 SECONDARY，从 SECONDARY 获取 OK，然后将 OK 发送回客户端。如果它无法写入 SECONDARY，或者没有得到 SECONDARY 的响应，它会回滚 PRIMARY 上的操作（即使它是成功的）并将失败发送回客户端。

失败的 WAN 链接（即使是暂时的）可能会导致 PRIMARY 选择不接受连接（因为它看不到 SECONDARY）。故障转移中间连接可能会使您处于无效的逻辑数据状态，因此请确保您的事务是健全的。

使用 WITNESS 服务器，这可以更强大一些 - 将见证服务器与 PRIMARY 放在同一个 LAN 中允许 WITNESS 和 PRIMARY 形成仲裁并同意 PRIMARY 仍在工作，即使它看不到 SECONDARY （因此不会将您锁定在功能完善的数据库之外）。

相反，通过较慢的站点到站点链接，我更喜欢在 PRIMARY 和 SECONDARY 之间使用日志传送。通过一些努力，我可以控制站点之间的传输，以便对 WAN 链接进行速率限制，并且可以将日志传送的 SECONDARY 保持在单用户待机模式下。这使我可以针对 SECONDARY 运行标准的 DBCC CHECKDB 命令，也可以查询 SECONDARY 以进行数据核对。我也可以延迟恢复，所以我有一些余地来进行故障转移在一个主要的逻辑数据错误到达 SECONDARY（虽然这真的取决于 RDO）。

如果我有高可用性要求，我可能只在主站点上进行镜像——即两台服务器 + 见证。过去，见证环境提供的相对快速的几秒钟自动故障转移时间为我节省了几个深夜电话。

希望这会有所帮助。

J.