【译】MySQL 组复制 - 部分网络故障对性能的影响

原文地址：MySQL Group Replication – Partial Network Failure Performance Impact

在这个由两部分组成的博客系列中，我想介绍一些使用组复制的故障转移场景。在第一部分中，我将讨论我在撰写这些文章时发现的一种有趣的行为和性能下降。在第二部分中，我将展示几个故障转移场景，并演示 Group Replication 如何处理每种情况。

测试环境非常简单，是在 MySQL 8.0.19 上使用默认设置的三节点 Group Replication（mysql1,mysql2,myslq3），mysql2 是主节点。

在这种情况下，我测试的是当一个节点与主节点分离，但其他节点仍能看到它时发生的部分网络故障。
在这里插入图片描述
你会认为 mysql3 会失去法定节点数并退出集群，但事实并非如此。在集群内部，所有节点都在不断相互通信，不仅主节点在与 mysql3 通信，mysql1 也在与 mysql3 通信。

如果我们从主服务器询问群集状态，它将显示 mysql3 不可达。

MySQL mysql2:3306 ssl JS > cluster.status();
{
"clusterName": "my_innodb_cluster",
"defaultReplicaSet": {
"name": "default",
"primary": "mysql2-T1:3306",
"ssl": "DISABLED",
"status": "OK_NO_TOLERANCE",
"statusText": "Cluster is NOT tolerant to any failures. 1 member is not active",
"topology": {
"mysql1-T1:3306": {
"address": "mysql1-T1:3306",
"mode": "R/O",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.19"
},
"mysql2-T1:3306": {
"address": "mysql2-T1:3306",
"mode": "R/W",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.19"
},
"mysql3-T1:3306": {
"address": "mysql3-T1:3306",
"mode": "n/a",
"readReplicas": {},
"role": "HA",
"shellConnectError": "MySQL Error 2003 (HY000): Can't connect to MySQL server on 'mysql3-T1' (110)",
"status": "UNREACHABLE",
"version": "8.0.19"
}
},
"topologyMode": "Single-Primary"
},
"groupInformationSourceMember": "mysql2-T1:3306"

但如果我们询问 mysql1 的状态，它会说一切正常：

MySQL mysql1:3306 ssl JS > cluster.status();
{
"clusterName": "my_innodb_cluster",
"defaultReplicaSet": {
"name": "default",
"primary": "mysql2-T1:3306",
"ssl": "DISABLED",
"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
"topology": {
"mysql1-T1:3306": {
"address": "mysql1-T1:3306",
"mode": "R/O",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.19"
},
"mysql2-T1:3306": {
"address": "mysql2-T1:3306",
"mode": "R/W",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.19"
},
"mysql3-T1:3306": {
"address": "mysql3-T1:3306",
"mode": "R/O",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.19"
}
},
"topologyMode": "Single-Primary"
},
"groupInformationSourceMember": "mysql2-T1:3306"

对我来说，这有点令人困惑，因为我询问的是同一个集群的两个成员，但报告的状态却不同，我希望在所有节点上看到相同的集群状态。

但这意味着什么？

我还能向集群写入数据吗？mysql3 是否也会获得新的更改？为了回答这些问题，让我们做一些简单的测试。

我创建了一个简单的表：

CREATE TABLE `lab` (
`id` int NOT NULL AUTO_INCREMENT,
`hostname` varchar(20) DEFAULT NULL,
`created_at` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `idx_created` (`created_at`)
) ENGINE=InnoDB

现在，我在主服务器上启动了以下循环写入数据：

while true;do mysql -usbtest -pxxxxx -P3306 -h127.0.0.1 -e "INSERT INTO sysbench.lab (hostname) VALUES ( @@hostname)"; done 2>/dev/null

它将打印输出每秒在 mysql2 和 mysql3 上插入的行数。

我使用 iptables 切断了 mysql2 和 mysql3 之间的网络：

mysql3# iptables -A INPUT -s mysql2 -j DROP; iptables -A OUTPUT -s mysql2 -j DROP

在此之后，mysql3 仍能获取更改，但如何获取？它无法连接 mysql2。但它仍能连接到 mysql1，而 mysql1 将充当 mysql2 和 mysql3 之间的中继节点。这听起来很不错，因为即使在部分网络中断的情况下，我们仍然可以使用 mysql3，因为它会获取更改。但是，这种行为在任何地方都没有记录。所以我不知道它在引擎盖下是如何工作的。我打开了一个错误报告，以更新文档。

查阅上述错误报告，最后的结论是非Bug

性能严重下降

不过，我也注意到性能因此严重下降。当所有节点都连接在一起时，我每秒可以插入 60-80 行。一旦我切断网络，这个数字就会下降到每秒插入 2-5 行，下降了 80-90%。这可能会严重影响任何应用程序的性能，这意味着使用组复制时，即使是部分网络中断，或错误实施 Iptables 规则等，都可能导致生产问题。

在这里插入图片描述
由于记录不全，我无法确定发生这种情况的原因。在组复制中，多数人确认事务就足够了，因此理论上，mysql2 和 mysql1 就足够了，所以我们不能用网络延迟来解释这种性能下降，因为多了一跳。

如何与 Percona XtraDB Cluster 协同工作？

Percona XtraDB Cluster 基于 Galera，后者是另一种 MySQL 集群解决方案。在 Galera 中，这种行为是众所周知的；节点甚至可以充当数据中心之间的中继节点。我在一个三节点 PXC8 集群上也重复了同样的测试。当我切断主节点（我写程序的地方）和 mysql3 之间的网络时，有 3 秒钟的间隙，直到集群重新计算集群视图并重新路由流量，之后一切恢复正常，没有明显的性能影响，mysql3 通过 mysql1 获得所有更改：

mysql3 62 2020-03-31 14:13:12
mysql3 65 2020-03-31 14:13:13
mysql3 67 2020-03-31 14:13:14
mysql3 69 2020-03-31 14:13:15
mysql3 47 2020-03-31 14:13:16
mysql3 0 2020-03-31 14:13:17
mysql3 0 2020-03-31 14:13:18
mysql3 0 2020-03-31 14:13:19
mysql3 41 2020-03-31 14:13:20
mysql3 71 2020-03-31 14:13:21
mysql3 72 2020-03-31 14:13:22