Percona XtraDB Cluster(下称PXC)集群是一种支持多主方式的集群模式，也就是说多个不同的节点均可提供读写功能，并且确保写入对群集中的所有节点都是一致的。这极大的解决了单点IO性能瓶颈，以及单点宕机故障。本文描述的是PXC多主复制的逻辑结构，供大家参考。
一、什么是多主复制
多主复制
多主复制意味着您可以可以在任何节点写入，并确保写入对群集中的所有节点都是一致的。
这与常规MySQL复制不同，在这种情况下，您必须将写入操作应用到Master，以确保它将被同步。
使用多主复制时，任何写操作都会在所有节点上提交，或者根本不提交。
二、多主复制示意图
下图显示了它是如何工作的两个节点，但相同的逻辑适用于任意数目的PXC群集中。
图片来源： Galera文档 - 如何进行基于认证的复制工作
三、多主复制机制
所有的查询都在节点本地执行，只有COMMIT需要特殊的处理。当COMMIT发出后，事务必须通过所有节点上的认证。
如果没有通过，您将收到ERROR作为该查询的答复。之后，事务被应用在本地节点上。
响应时间COMMIT包括以下内容：
网络往返时间
认证时间
本地Apply
注意
在远程节点上应用事务不会影响COMMIT响应时间，因为它发生在认证响应后的后台。
这种架构有两个重要的后果：
可以并行同时使用多个appliers。这使真正的并行复制成为可能。从机slave可以使用wsrep_slave_threads变量配置许多并行线程。
slave从机可能会有一小段时间不同步。发生这种情况是因为主节点可能比从站更快地应用事件。如果你从slave读取，可以从图中看到，你可能读取尚未改变的数据。
但是，这个行为可以通过设置变量wsrep_causal_reads=ON来改变。在这种情况下，从节点上的读操作将一直等到事件被应用（这显然会增加读操作的响应时间）。从机和主机之间的差距就是为什么这个复制被称为虚拟同步复制，而不是真正的同步复制。
这里描述的行为COMMIT也蕴含着一个严重的含义。如果您将写入事务运行到两个不同的节点，则群集将使用乐观锁定模型。这意味着一个事务不会在个别查询期间检查可能的锁定冲突，而是在COMMIT阶段，您可能会得到ERROR回应COMMIT。
之所以提到这一点，是因为它可能会遇到与InnoDB不兼容的问题。对于InnoDB，死锁DEADLOCK和锁超时(LOCK TIME)错误误通常发生在针对特定查询，而不是在COMMIT阶段。在COMMIT之后检查错误代码是一个很好的做法，但仍有许多应用程序不这样做。
如果您计划使用多主复制并在多个节点上运行写入事务，则可能需要确保处理COMMIT查询上的响应。
