Group Replication and Percona XtraDB Cluster: Overview of Common Operations

Group Replication and Percona XtraDB Cluster: Overview of Common Operations

在这篇博客文章中，我将概述使用MySQL Group Replication 8.0.19 (aka GR 国内爱叫MGR发现国外还是习惯叫GR)和Percona XtraDB Cluster 8 (PXC)(基于Galera)时最常见的故障转移场景和操作，并解释每种技术如何处理每种情况。我已经创建了一个包含三个节点的集群，使用一个主节点和一个包含三个节点的PXC进行组复制，它们均使用默认参数配置。 我还将使用ProxySQL与两个群集进行交互。

在这两个群集中，节点的名称分别为mysql1，mysql2和mysql3。 在组复制中，如果我们使用单主模式，则主节点处理写请求。 在PXC中，我也将使用相同的术语，并将在发送写操作的节点称为Primary。 请注意，在PXC中没有主节点的概念，所有节点都是相等的。

这是两种解决方案的设置示意图。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3WKR7xbC-1588479875109)(https://www.percona.com/blog/wp-content/uploads/2020/04/blogpost1-1.png)]

Primary Server Crashes

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OGTRgw2o-1588479875111)(https://www.percona.com/blog/wp-content/uploads/2020/04/blogpost2.png)]

Group Replication – Writing

在此测试中，我仅向集群发送写请求。 当我杀死GR上的主节点时，重新组织拓扑需要花费5到15秒的时间，ProxySQL识别新的拓扑结构后将写入发送到新的主节点。 启动旧的主数据库并将其重新添加到集群中不会导致任何中断(不会影响业务)。

Group Replication – Reading

如果我仅向集群发送读取请求，主节点崩溃将导致读取中断吗？ ProxySQL只会将流量重定向到其他节点。 重组期间不会阻塞查询。

Percona XtraDB Cluster – Writing/Reading

在PXC中，读取和写入之间没有区别，一旦节点崩溃/消失/分离(crashes/goes away/gets separated)，群集必须重新创建群集视图并检查仲裁。 这样做时，它不接受任何读取或写入。 通常，这需要3到10秒，在此时间范围内，应用程序会受到影响。

Removing/Adding Node

如果我们删除或添加一个新节点，集群会如何做。

Group Replication

在GR中，添加或删除节点不会影响或导致应用程序中断。 如果我们使用克隆插件添加新节点，则集群会将数据传播到新节点。

Percona XtraDB Cluster

删除或添加节点不会导致任何中断。 类似地，就像在GR中添加新节点时一样，它将执行SST（State Snapshot Transfer状态快照传输）以从另一个节点获取所有数据。

Partial Network Failure

如果读节点与主节点分离，但仍能够看到其他节点，则群集会发生什么情况？

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-h4BScvFu-1588479875113)(https://www.percona.com/blog/wp-content/uploads/2020/04/blogpost3.png)]

在这种情况下，mysql2（主）和mysql3之间存在网络中断。

Group Replication

在我之前的一篇博文MySQL Group Replication – Partial Network Failure Performance Impact中我更详细地解释了这个特殊情况。基本上，部分网络中断会严重影响集群中的写性能，从而导致应用程序问题和/或停机。

8.0.19有bug,官方已经复现并确认bug, 但是一个朋友没有复现

目前最新版本为8.0.20, 在release note没有看到修复此bug

Percona XtraDB Cluster

在PXC中，当群集重新创建群集视图并开始将流量中继到可看到该服务器的节点时，将发生3-5秒的中断。 之后，它将像以前一样继续工作，而不会对性能造成任何严重影响。

In PXC there is going to be a 3-5s outage while the cluster re-creates the cluster view and begins relaying the traffic to a node that sees that server. After that, it will continue working just like before without any serious performance impact.

Total Network Isolation

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9TsdZK39-1588479875115)(https://www.percona.com/blog/wp-content/uploads/2020/04/blogpost5.png)]

现在，mysql3与所有其他节点完全分离。

Group Replication

群集可以接受读取和写入而不会发生任何中断，ProxySQL会将读取重定向到其他节点。

Percona XtraDB Cluster

在PXC上，将有3-5秒的停机时间，而群集意识到一个节点不可用，并将如上所述重新创建群集视图。 在那之后，它能够处理读写。

Local Applications

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TlhizUg0-1588479875116)(https://www.percona.com/blog/wp-content/uploads/2020/04/blogpost6.png)]

如果一个节点或部分节点与集群分开(网络分区, 5节点集群,形成3, 2结构), 那个对于分区中的2个节点, 可能应用仍然能和它们通信, 此时会发生什么情况?

What happens if a node or part of the nodes are separated and they do not have the quorum, but they have the application server in the same network segments which could still connect to the server.

Group Replication

分离的节点仍将接受读取流量，因此应用程序可以根据过时的数据做出决策。 这是默认设置，但是您可以使用名为group_replication_exit_state_action的参数做出调整

group_replication_exit_state_action

Property	Value
Command-Line Format	--group-replication-exit-state-action=value
Introduced	8.0.12
System Variable	group_replication_exit_state_action
Scope	Global
Dynamic	Yes
SET_VAR Hint Applies	No
Type	Enumeration
Default Value (≥ 8.0.16)	READ_ONLY
Default Value (≥ 8.0.12, ≤ 8.0.15)	ABORT_SERVER
Valid Values (≥ 8.0.18)	ABORT_SERVER``OFFLINE_MODE``READ_ONLY
Valid Values (≥ 8.0.12, ≤ 8.0.17)	ABORT_SERVER``READ_ONLY

ABORT_SERVER节点实例会被shutdown

OFFLINE_MODE连接的客户端用户在下一个请求时断开连接，不再接受连接

READ_ONLY 实例变为只读模式

Percona XtraDB Cluster

在PXC中，如果节点分离，则它将不接受任何读取或写入。 优先级是数据一致性，只有具有quorum的segment才能接受任何读取和写入。

In PXC, if a node gets separated, it is not going to accept any reads or writes. The priority is the data consistency and only the segment which has the quorum will accept any reads and writes.

Changing Primary

Group Replication

If you would like to use a new Primary node you have to promote a reader to be the new primary:

cluster.setPrimaryInstance("mysql2:3306")

ProxySQL将遵循这些更改，但是在群集重新组织自身时，它将导致几秒钟的中断。

Percona XtraDB Cluster

在PXC上没有Primary的概念，任何节点都可以在任何时间进行写操作，因此我们只需要将流量重定向到负载均衡器中的另一个节点（即ProxySQL）。 PXC中还有一个pxc_maint_mode变量。 将其更改为MAINTENANCE可以从节点上软删除该连接，即使该连接是Primary，也是如此，但是ProxySQL Native Galera支持对此的支持很差。 I would recommend using the 1.4 scheduler which respects this variable.

Summary

	Group Replication	Percona XtraDB Cluster
Primary Crashes	5-15s outage	5-10s outage
Reader Crashes	No impact	3-5s outage
Adding a Node	No impact	No impact
Removing a Node	No impact	No impact
Partial Network Failure	Performance Impact	3-5s outage, than normal performance
Total Network Isolation	No impact	3-5s outage
Changing Primary	1-3s outage	No impact on the cluster

如果读取节点发生故障或分离，则组复制的影响较小。 在PXC中，由于所有节点都是相同的，因此没有专用的主节点。 如果任何节点发生任何事情，则集群必须投票并重新创建集群视图，这可能会对应用程序产生一些影响。 但是，PXC可以更好地处理主节点切换(primary promotions)和网络故障。

如我们所见，这两种集群解决方案都有各自的优缺点。 希望本摘要将帮助您对它们有更多的了解，并使您对使用哪种技术的决策更加容易。