摘要: 出处：黑洞中的奇点 的博客 http://www.cnblogs.com/kelvin19840813/ 您的支持是对博主最大的鼓励，感谢您的认真阅读。本文版权归作者所有，欢迎转载，但请保留该声明。

 

3.2 Multi-Master Replication

多主复制意味着您可以写入任何节点并确保写入对所有节点都是一致的在集群中。

这与常规MySQL复制不同，在常规MySQL复制中，您必须将写入应用于master以确保它将被同步。

对于多主复制，任何写入都在所有节点上提交或根本不提交。

下图显示了它如何适用于两个节点，但是相同的逻辑适用于集群中的任意数量的节点：

Figure 3.1: Image source: Galera documentation - HOW CERTIFICATION-BASED REPLICATION WORKS

所有查询都在节点上本地执行，并且仅在COMMIT上有特殊处理。

当COMMIT查询发出时，事务必须通过所有节点上的认证。

如果它没有通过，你会收到ERROR作为响应。之后，事务在本地节点上应用。

COMMIT的响应时间包括以下内容：

•网络往返时间

•认证时间

•本地申请

注意：在远程节点上应用事务不会影响COMMIT的响应时间，因为它发生在背景后的认证反应。

这种架构有两个重要的后果：

•可以并行使用几个应用程序。这实现了真正的并行复制。

使用 wsrep_slave_threads 变量配置的线程从机可以有多个并行。

•slave可能有一个小的时间段不同步。这是因为master可以申请事件比slave更快。

如果你从slave读取,您可以读取尚未更改的数据。你可以从图中看到。

但是， 可以通过设置 wsrep_causal_reads = ON 变量来更改此行为。

在这种情况下，在slave上读取将等待，直到事件被应用（这将明显增加读取的响应时间）。

Slave和Master之间的差距是这种复制被称为这个复制被称为虚拟同步的原因，而不是真正的同步复制。

所描述的COMMIT行为也有另一个严重的暗示。如果你运行写事务到两个不同的节点，

集群将使用乐观锁模型。这意味着事务在个别查询期间不会检查可能的锁定的冲突，

而是在COMMIT阶段，您可能会在COMMIT上收到ERROR响应。

这是因为它是与您可能会遇到的常规InnoDB不兼容之一。

在InnoDB，DEADLOCK和LOCK TIMEOUT错误通常发生在特定查询，而不是COMMIT。

优良做法是在COMMIT后检查错误代码，但仍有许多应用程序不能做那个。

如果计划在多个节点上使用多主复制并运行写事务，你可能需要确保您处理COMMIT查询的响应。