我想考虑使用 DRBD 在主位置和辅助位置之间进行数据复制。初步计划是在两者之间建立 VPN 隧道；主端使用双 T1 链路的一部分，辅助位置设置在电缆/ dsl 线路上。
辅助数据库仅用于 DR - 它“永远不会”复制回主数据库。
有人做过/试过/使用过类似的东西吗？你的使用体验如何？
Linbit 还有一款（付费）DRBD 代理产品，据说是为跨 WAN 类型链路（压缩、多个对等点）运行而设计的。有人试过吗？
答案1
我不能代表 DRBD Proxy 发言，但是常规 DRBD 不会太喜欢这个。
即使活动有限，您也很容易使双 T1（2x 1.5Mbps；整数为 300KB/s）饱和。仅应用程序日志记录就可能占用 300KB/s，更不用说在服务器上执行任何有趣的操作了。这排除了同步复制（议定书C)，更不用说将跨 VPN 延迟添加到公式中了。
异步复制（议定书A）可能在技术上可行，但我认为辅助服务器可能已经过时，在发生故障时无法使用（副本在白天可能会落后几个小时）
内存同步 (议定书B) 不会有帮助，因为它仍然受到带宽问题的限制。
我预计 DRBD Proxy 仍将面临类似的问题，主要由于带宽有限而导致复制延迟。
我建议您重新评估您的 DR 策略，以找出您要缓解的问题：硬件故障或站点故障。
在防止站点故障的情况下，如果一个（或两个）站点带宽受限，那么较低带宽/较高密度传输可能会带来更好的效果。这种技术的一些示例是 rsync（通过网络传输仅限于运行之间的文件更改 - 而不是每次更改都进行更改 - 加上一些协议开销；可以通过 SSH 运行以进一步加密和压缩流量）和数据库日志传送（将压缩的数据库日志传输到 DR 盒上重放可能比传输完整的数据库转储使用更少的带宽）。
如果您要防范硬件故障，使用 GigE 交叉连接本地 DRBD 副本即可正常工作，允许完全同步更新，并允许在线验证以证明两个节点上的数据一致。您仍然可以将此选项与有限文件复制到 DR 站点相结合，以防止主站点发生故障。
答案2
只要您不一直让 T1 链路饱和，DRBD-Proxy 就能正常工作。我们通过 DRBD-Proxy 连接（授予 100 兆位链路）发送了大量 2TB 文件，没有任何问题。只要您有足够的 RAM 用于代理，并且写入量不是太高以至于 T1 无法处理，这应该可以正常工作。不过，您可能希望使用异步模式进行复制。