哪些因素会对mysql数据库服务器性能造成影响

网络宽带也会有所影响。

网络是数据库基础架构的主要部分。但是，通常性能基准测试是在本地计算机上完成的，客户端和服务器并置在一起。这样做是为了简化结构并排除一个以上的变量（网络部分），但是我们也忽略了网络对性能的影响。对于像 MySQL Group Replication 这样的产品集群来说，网络更为重要。在这篇文章中，我将介绍网络设置。这些都是简单而微不足道的，但却是让我们更了解复杂网络设置效果的基石。

安装我将使用两台裸机服务器，通过专用的 10Gb 网络连接。我将通过使用 ethtool-s eth1 speed1000duplex full autoneg off 命令更改网络接口速度来模拟 1Gb 网络。

我将运行一个简单的基准：sysbench oltp_read_only --mysql-ssl=on --mysql-host=172.16.0.1 --tables=20 --table-size=10000000 --mysql-user=sbtest --mysql-password=sbtest --threads=$i --time=300 --report-interval=1 --rand-type=pareto

运行时线程数从 1 到 2048 不等。所有数据都适合内存 -innodb_buffer_pool_size 足够大。因此工作负载在内存中占用大量 CPU：没有 IO 开销。 *** 作系统：Ubuntu 16.04

N1 基准-网络带宽在第一个实验中，我将比较 1Gb 网络和 10Gb 网络。显然，1Gb 网络性能是这里的瓶颈，如果我们迁移到 10Gb 网络，我们可以显着改善我们的结果。要查看 1Gb 网络是瓶颈，我们可以检查 PMM（percona 的数据库监控管理开源工具） 中的网络流量图表：

我们可以看到我们的吞吐量达到了 116 MiB/s（或 928 Mb/s)，这非常接近网络带宽。但是，如果我们的网络基础设施仅限于 1Gb，我们可以做些什么？

N2 基准-协议压缩MySQL 协议中有一个功能，您可以看到客户端和服务器之间的网络交换压缩：--mysql-compression=on。让我们看看它将如何影响我们的结果。

这是一个有趣的结果。当我们使用所有可用的网络带宽时，协议压缩实际上有助于改善结果。

但是 10Gb 网络不是这种情况。压缩/解压缩所需的 CPU 资源是一个限制因素，通过压缩，吞吐量实际上只达到我们没有压缩的一半。现在让我们谈谈协议加密，以及如何使用 SSL 影响我们的结果。

N3基准-网络加密

对于 1Gb 网络，SSL 加密显示了一些损失 - 单线程约为 10％ - 但是否则我们再次达到带宽限制。我们还看到了大量线程的可扩展性，这在 10Gb 网络案例中更为明显。使用 10Gb 时，SSL 协议在 32 个线程后不会扩展。实际上，它似乎是 MySQL 目前使用的 OpenSSL 1.0 中的可伸缩性问题。在我们的实验中，我们看到 OpenSSL 1.1.1 提供了更好的可伸缩性，但是您需要从链接到OpenSSL 1.1.1 的源代码中获得特殊的 MySQL 构建才能实现这一点。我没有在这里展示它们，因为我们没有生产二进制文件。

结论

1. 网络性能和利用率将影响一般应用程序吞吐量。

2. 检查您是否达到了网络带宽限制。

3. 如果受到网络带宽的限制，协议压缩可以改善结果，但如果不是，则可能会使事情变得更糟。

4. SSL 加密在线程数量较少的情况下会有一些损失（约10％），但对于高并发工作负载，它不会扩展。

背景

在上一篇推文中，我们介绍了 MySQL Group Replication 8.0.16 支持信息碎片化功能来增强大型事务处理能力。

如果您想在组复制中使用该功能，则任何组成员的版本都不能低于 8.0.16！

简单地说就是由于低版本协议上不支持。MySQL 8.0.16 的组通讯开始支持新协议，简称“分段协议”，之前的版本中只有一种“压缩协议”。

如果多个成员想加入复制组，那么在协议匹配上遵循以下原则：

现有复制组成员和新加入成员版本相同，加入成功。

低版本成员想加入高版本的组会被驱逐，加入失败。

高版本的成员想加入低版本的组，单独加入成功，多个加入失败。

例如：

一个 MySQL Server 8.0.16 实例可以成功加入使用通信协议版本 5.7.24 的组。

一个 MySQL Server 5.7.24 实例无法成功加入使用通信协议版本 8.0.16 的组。

两个 MySQL Server 8.0.16 实例无法同时加入使用通信协议版本 5.7.24 的组。

两个 MySQL Server 8.0.16 实例可以同时加入使用通信协议版本 8.0.16 的组。

新增 UDF

为了能让高版本的复制组更便于加入低版本的成员，MySQL 8.0.16 新增两个 UDF。

您可以使用两个新的 UDF 命令去管理组通信协议：

1. group_replication_set_communication_protocol(new_protocol)

设置组复制通讯协议版本

SELECT group_replication_set_communication_protocol("8.0.15")

填入一个所有成员都支持的版本号，即：new_protocol ≤ 所有成员的 MySQL版本。

new_protocol 格式：major.minor.patch （主版本号.次版本号.发布版本号）例如：8.0.15。

2. group_replication_get_communication_protocol()

获取复制中最旧成员的 MySQL 版本号

SELECT group_replication_get_communication_protocol()   +------------------------------------------------+    | group_replication_get_communication_protocol() |    +------------------------------------------------+    | 5.7.14                                         |    +------------------------------------------------+

获取的版本号可能与设置的值不一致，但不一致的版本之间组复制协议是一样的。

返回结果格式：major.minor.patch （主版本号.次版本号.发布版本号）例如：8.0.15。

以上两个 UDF 对全部组成员有效，主机或从机上均可执行。

结论

若想使用信息碎片功能。建议将组复制成员全部升级为 8.0.16。

若组内成员版本仅有部分为 8.0.16，可以用两个新的函数来让高版本的成员保持与其它成员组协议一致。

请点击输入图片描述

---