【译】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

此外,在 PXC8 中,所有节点都报告了相同的群集状态,甚至连 mysql2 也不例外。

结论

由于组复制和 Galera 的实施和方法不同,因此对性能的影响也不同。与组复制相比,Galera 对网络问题的容忍度更高。

  • 9
    点赞
  • 21
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

markvivv

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值