我想考虑使用 DRBD 在主要和次要位置之间进行数据复制。初步计划是在两者之间建立VPN隧道；主要端使用双 T1 链路的切片和电缆/dsl 线路上的次要位置设置。
辅助节点仅用于 DR - 它“永远不会”复制回主节点。
有没有人做过/厌倦/使用这样的东西，你有什么经验。
Linbit 还有一个（付费）DRBD 代理产品，该产品设计用于跨 WAN 类型链接（压缩、多个对等点）运行。有人试过这个吗？
我不能说 DRBD 代理，但普通的 DRBD 不会那么喜欢这个。
即使活动有限，您也可以轻松使双 T1 饱和（2x 1.5Mbps；对于整数，300KB/s）。仅应用程序日志记录就可以占用 300KB/s，更不用说在您的服务器上做任何有趣的事情了。这排除了同步复制（协议 C），更不用说在等式中添加 over-the-vpn 延迟了。
异步复制（协议 A）在技术上可能有效，但我希望辅助节点已经过时，在出现故障时无法使用（副本可能在白天落后几个小时）
内存同步（协议 B）无济于事，因为它仍然受到带宽问题的限制。
我预计 DRBD 代理仍然会遇到类似的问题，主要是由于带宽有限而导致复制延迟。
我建议您重新评估您的 DR 策略以找出您要缓解的问题；硬件故障或站点故障。
在防止站点故障的情况下，在一个（或两个）带宽受限站点的情况下，您可能会从较低带宽/较高密度传输中获得更好的里程。这种技术的一些例子是 rsync（在线传输仅限于运行之间的文件更改 - 而不是每次更改的每次更改 - 加上一些协议开销；可以通过 SSH 运行以进一步加密和压缩流量）和数据库日志传送（传输压缩的数据库日志以在 DR 盒上重播可能比传输完整的数据库转储使用更少的带宽）。
如果您要防止硬件故障，则与 GigE 交叉连接的本地 DRBD 副本将正常工作，允许完全同步更新，并允许在线验证以证明两个节点上的数据是一致的。您仍然可以将此选项与有限的文件复制结合到 DR 站点，以防止主站点发生故障。