在开发我当前的开发产品时，我已经在主数据中心和辅助数据中心之间设置了 SQL 服务器镜像。在主数据中心，SQL .mdf 和 .ldf 文件存储在 SAN 上。
现在诚然，我们失去 SAN 的可能性很小，但是如果与 SAN 的连接丢失并且数据库完整性丢失。镜像还会发生吗？即 SQL 现在会镜像损坏的数据库，现在两者都同样损坏了吗？
从谷歌搜索不清楚镜像何时会发生和不会发生，所以我希望社区可以分享一些经验。
我还设置了备份计划，这将是最终的故障保险，但实际上我希望镜像数据库将是我们让所有内容恢复在线的最快方式。
在这种情况下，目前在镜像过程中没有见证服务器，尽管我正在考虑添加一个自动故障转移的好处。
谢谢
就 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 保持在单用户待机模式下。这使我可以DBCC CHECKDB针对 SECONDARY 运行标准命令，也可以查询 SECONDARY 以进行数据核对。我也可以延迟恢复，因此在主要逻辑数据错误到达 SECONDARY之前，我有一些故障转移的余地（尽管这实际上取决于 RDO）。
如果我有高可用性要求，我可能只在主站点上进行镜像——即两台服务器+见证。过去，见证环境提供的相对快速的几秒钟自动故障转移时间为我节省了几个深夜电话。
希望这可以帮助。
J。