Percona XtraDB Cluster多主复制(PXC 5.7)

Percona XtraDB Cluster(下称PXC)集群是一种支持多主方式的集群模式,也就是说多个不同的节点均可提供读写功能,并且确保写入对群集中的所有节点都是一致的。这极大的解决了单点IO性能瓶颈,以及单点宕机故障。本文描述的是PXC多主复制的逻辑结构,供大家参考。

一、什么是多主复制

多主复制
  多主复制意味着您可以可以在任何节点写入,并确保写入对群集中的所有节点都是一致的。
  这与常规MySQL复制不同,在这种情况下,您必须将写入操作应用到Master,以确保它将被同步。
  使用多主复制时,任何写操作都会在所有节点上提交,或者根本不提交。

二、多主复制示意图

下图显示了它是如何工作的两个节点,但相同的逻辑适用于任意数目的PXC群集中。

Percona XtraDB Cluster多主复制(PXC 5.7)

  图片来源: 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查询上的响应。

https://www.percona.com/doc/percona-xtradb-cluster/LATEST/features/multimaster-replication.html

上一篇:Percona XtraDB Cluster Perfomance Schema Instrumentation


下一篇:一些上流的CSS3图片样式