1.4.BDR︰ 弱耦合多主机复制

考虑到聚类的多主机或复制 （以 BDR 或另一种技术） 时，重要的是理解什么涉及，和并不是所有的多主系统相等。

注意︰ 你不需要为多主机使用 BDR。是很有道理，写入只有一个节点，像一种改进的只读副本系统使用 BDR。它也是可能确保，任何给定的表/架构只写到在一个特定节点上，所以不可以会出现冲突。你还要考虑复制滞后，但没有更多或更少比正常热备用。当您的应用程序写入相同的表在多个节点上一次的时候，它只获取复杂。如果你需要这样做，请继续阅读。

一些多主系统是紧密耦合的;这些往往使所有节点似乎是相同的虚拟数据库外部客户，完成与跨节点锁定，事务隔离等的一部分。他们也通常-但不是总是-使用共享的存储，在那里每个节点连接到相同的底层数据库文件通过 SAN 或类似。这样的生活更容易为应用程序开发人员习惯于独立或单主机数据库一起工作，因为他们可以做的就是像以前那样。像任何事情是有代价的虽然︰ 紧密耦合的多主系统不能扩展出很好，尤其是对于写操作，并不是很宽容的延迟、 节点停机或网络分区。

其他系统是松散耦合的。他们不要试图看上去像是单个的无缝虚拟数据库，和应用程序可以看到哪个节点根据它们连接到一些差异。最松散耦合的系统不共享存储;而每个节点本地有整个数据库的一个副本或它的一个子集。如果它们存储的数据的一个子集他们可能支持路由查询到正确的节点，或者他们可能希望应用程序以确定哪个节点上查找的数据。一般来说是没有全局锁管理器或事务管理器，所以在一个节点上的交易不受采取其他节点上的锁。松散耦合有许多系统是异步和最终一致 (见︰ 概念) 所以在同一时间在一个节点上的变化不是立即可见的所有其他节点上。这可以使应用程序开发更困难，但在 exchange 使系统的节点、 临时网络分区或节点停机等之间的延迟很宽容和使 scale-out 更高效。

BDR 是松散耦合的无共享的多主设计。

这是广泛和过于简化的复制，但这足以解释为什么使用 BDR 为多主机写操作的应用程序需要了解异常可以介绍的异步多主机复制的特性。它还应有助于说明应用程序交换得到一些明显的好处︰

使用 BDR 的应用程序可以自由地写入任何节点，所以只要他们很小心，以防止或应付冲突。

如果节点出现故障或网络问题出现，没有复杂的选举的一个新的主人。有是无需等待故障转移。每个节点始终是一位大师，总是直接可写。

应用程序可以按地理位置分布使应用程序数据和用户提供更好的性能和可用性。可以在本地满足读取。

应用程序可以分区容错︰ 应用程序可以保存这份工作即使它失去与某些或所有其他节点的通信，然后重新同步自动恢复连接后。一个关键的 VPN 隧道或广域网的损失不会使整个商店或卫星办公室停止。

优点来挑战。

BDR 异步复制，因为并非所有节点都有相同的数据视图在任何给定的时刻。在单个节点上保证已提交的事务更改成为立即对新开工的交易记录 （或在读致力模式中，语句） 可见。这不是真的在 BDR-如果您提交更改行在一个节点上的事务，然后选择另一个节点上的那行，你仍然可以得到的旧值。因此，必须要宽容的陈旧数据或被"粘"到节点上，他们在哪做读取的数据从他们写给它的同一节点设计应用程序。这也是真正的应用程序使用 PostgreSQL 的物理复制功能，除非它用于在同步模式下使用只有一个副本，所以它是一个挑战，并不是唯一 BDR。

锁定操作不复制到其他节点。如果您锁定行或表中的一个节点其他节点都不知道它锁着的其他地方。如果他们的写入和读取锁定发生在单个节点上的应用程序依赖于行或表锁的正确性只将正常工作。应用程序可能会依赖于显式锁定通过锁表或选择...更新 / 份额，但大多数应用程序依赖于它隐式地通过更新和删除行锁定，所以没有显式锁定并不意味着应用程序是自动多主机的安全。

由于异步复制和缺少全球锁定，它有可能要执行可能不会发生，如果两个事务在单个节点上运行的操作的不同节点上的交易记录。这些被称为冲突和分开; 详细讨论了请参阅多主冲突。BDR 可以解决冲突使用一个简单的最后更新 wins 策略或使用用户定义的冲突处理程序。不管是哪种应用程序的设计需要考虑可能会发生冲突，并可能最小化它们。Naïive 应用程序忽略冲突时写入多个母版的可能性可能遭受失去了更新和其他不良数据异常。

BDR 提供一些工具来帮助简化应用程序的设计。最重要的是全球的序列，提供 BDR 组全发电机的唯一值，用于合成键。其他人在多主机冲突节讨论。