SQL Server镜像的智能程度如何？

Question

在使用当前开发产品时，我在主数据中心和辅助数据中心之间设置了SQL Server镜像。 在主数据中心中，SQL .mdf和.ldf文件存储在SAN中。

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

由于不清楚何时以及何时会发生镜像，因此我希望社区可以分享其中的一些经验。

我也有备份计划设置，这将是最终的故障保护措施，但实际上，我希望镜像数据库将是我们使所有内容恢复在线的最快方法。

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

谢谢

Answer 1

至于PRIMARY和SECONDARY之间的镜像损坏：不幸的是，这取决于情况。 如果损坏是立即发生的且是物理损坏，则通常不是正常情况 -损坏通常是在事务结束时通过检查得到的，然后回滚。

但是，在任何人意识到它已损坏之前，数据库可能会以损坏状态存在一段时间。 如果未触及基础数据页，则引擎永远不会检查它们。 因此，潜在的存储问题可能意味着这两个数据库都可能损坏，并且直到您决定访问受影响的页面时您才知道。 传统上，这将是一个写操作，因为您的客户端连接将仅从当前活动数据库（而非伙伴）中读取。

这就是为什么对数据库（例如DBCC CHECKDB ）执行定期维护检查很重要的原因。 这在镜像环境变得困难，因为只有PRIMARY通常可以被检查，所以你真的要诱导手动故障转移来测试您的辅助（除非你正在运行的企业，你也许能够快照照镜子，检查-我尚未尝试）。

从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.