我正在研究一个使用 SQL Server 2012 SP2 的解决方案，但没有使用 AlwaysOn 可用性组。这是由于跨数据库事务，它不适用于此场景。
注意：我们正在解决这个问题，但将其作为背景信息添加到我的问题中。
我们正在使用 HP 3PAR StoreServ 解决方案通过 SAN 实现站点到站点的同步复制。这允许 DR 方案跨站点运行，因此我们可以将故障转移到辅助服务器。
我担心的是 RPO 为 0，因为在某些情况下数据可能会丢失并发生损坏。例如，站点之间的链接被切断，然后主服务器瘫痪。
我的问题如下：
- 在同步完成之前，SAN 是否会拒绝将数据写入 I/O？
或者
如果链接断开，SAN 是否会缓冲块更改直到连接恢复？
如果在 TL 日志写入期间链接被切断，并且发生 DR，这是否意味着我们将向辅助站点写入可能损坏的 TL，从而导致数据丢失？数据丢失只是因为主站点能够提交，但辅助站点无法同步。
零 RPO 是否可以保证整个堆栈（SQL Server / 内存 / 网络 / SAN / IO）？
摘自 HP 3PAR StorageServ 白皮书：适用于苛刻的容灾环境的复制解决方案，第 6 页：
对于同步复制解决方案，解决方案的 RPO 始终为零。但是对于异步复制解决方案，RPO 始终大于零。异步定期模式是异步复制。因此，在设计使用异步定期复制的解决方案时，RPO 成为一个问题。
SAN 保证 0 容忍度的 RPO，那么当网络中断时，SAN 是否会允许变化渗透到 I/O？
更新：
我在上述参考资料的第 12 页找到了此信息：
同步长距离拓扑
远程复制同步长距离 (SLD) 拓扑是目前唯一支持的拓扑，它允许将远程复制卷组中的卷从一个源 StoreServ 阵列复制到两个不同的目标 StoreServ 阵列。它通过在两个 StoreServ 阵列（“源”和“同步目标”阵列）之间同步复制数据，同时通过定期异步模式将相同数据复制到第三个 StoreServ 阵列（灾难恢复或“异步目标”阵列）来实现此目的。用户可以选择以主动-主动方式处理两个同步阵列，如果/当数据中心的故障指示需要进行故障转移时，在它们之间进行故障转移，并恢复“同步目标”阵列上的操作。这提供了一种故障转移解决方案，由于同步阵列之间发生的复制具有同步性质，因此可提供等于零的 RPO。
在故障转移到同步目标阵列时，该阵列与异步目标阵列之间的被动异步周期性链接将变为活动状态，并且已复制到同步目标但尚未到达异步目标阵列的任何数据都将从同步目标阵列发送到异步目标，从而使异步目标阵列与同步目标的最后一次写入保持同步。然后，操作将在同步目标数据中心继续进行，并继续将数据复制到异步目标阵列。
从这些信息来看，您确实需要第三个端点来参与异步复制，以便在网络链接中断时辅助站点能够收到有关更改的通知。
答案1
我无法对 3PAR 做出具体评论，但我对 EMC Symmetrix 阵列确实有很多经验。
我的建议是：另辟蹊径。同步复制是这些技术之一，它在纸面上看起来很棒，在最佳情况下也很好，但在现实世界中却会带来巨大的麻烦。
其工作方式如下：
- 传入的写入进入阵列上的缓存。
- 写入操作通过同步链接复制到远程站点。
- 写入已提交至远程阵列上的缓存。
- 确认信息被发送回主服务器。
- 写入 IO 成功并通知主机。
它的“RPO 0”是指如果数据在磁盘上，则数据在远程站点上。大多数应用程序使用内存缓存，而这些缓存在 DR 中会丢失。但是，这样做的代价很高：
您需要为远程站点提供足够的总带宽，以便始终能够满足复制要求 - 否则，您的主系统将受到严重影响，因为磁盘延迟将急剧上升。如果您曾经使此链接饱和，您将会受到影响，并且您的主要服务可能会崩溃。
您将始终面临延迟负担，并且您的性能将因此受到影响。
现在，这两件事可能都“没问题”。但根据我的经验，RPO0 和“同步复制”通常只有在有真正重要的事情时才会被讨论。
不过，直接回答你的问题吧：
Does the SAN deny data writes to the I/O until synchronisation has completed?
否 - 它会在异步模式下“赶上”，然后进入同步模式。这可能需要一段时间，具体取决于带宽，并且在同步之前，您不会获得“0 RPO”。
If a link is severed, does the SAN buffer the block changes until the connection is restored?
有点取决于您的配置。通常，它会将链接暂停/恢复视为需要异步重新同步的事件。当链接“断开”时，您的 RPO 不再为零。您可以在链接故障时“阻止” IO，但这可能只会使您的应用程序崩溃。
If a link is severed during a TL log write, and a DR occurs, doesn't this mean that we will have a potentially corrupt TL written to the secondary site, and therefore incur data loss? The data loss is only because the primary was able to commit, but the secondary was not able to synchronise.
否 - 同步意味着同步。如果同步，磁盘上的所有 IO 也都在远程。任何 IO不是但是磁盘上的数据丢失了，因此您可能会丢失最后的 translog。
Is RPO of zero ever a guarantee across the stack (SQL Server / Memory / Network / SAN / IO)?
RPO 是恢复点目标。如果你的目标（确实）为零，那么...你需要认真考虑你的架构。这是可以实现的，但成本非常高昂。
就我个人而言，我建议不要使用同步：
异步运行主数据存储，并依靠日志提供“同步”位。实际上，您的“RPO0”无论如何都只是“您提交的 translog”。因此，NFS（CIFS？）安装远程驱动器，并通过网络以及“本地”存储写入 translog，然后将它们重放到您的（几分钟不同步的）数据库中。
无论如何，您都会获得相同的恢复点 - 因为我非常怀疑您是否想要使用未记录的数据 - 而且您无需昂贵的同步操作即可这样做。