与独立的 mariaDB 服务器相比，使用 galera 获得非常糟糕的性能答案

【问题标题】：Getting a very bad performance with galera as compared to a standalone mariaDB server与独立的 mariaDB 服务器相比，使用 galera 获得非常糟糕的性能
【发布时间】：2017-05-27 09:56:08
【问题描述】：

使用我创建的 galera 设置，我得到了无法接受的低性能。在我的设置中，有 2 个节点处于主动-主动状态，我正在使用 HA-proxy 负载均衡器以循环方式在两个节点上进行读/写。

使用具有以下配置的单个 mariadb 服务器，我可以轻松地在我的应用程序上获得超过 10000 TPS： 36 vpcu、60 GB RAM、SSD、10Gig 专用管道

虽然我使用 2 个节点（36vcpu，60 GB RAM）的数据库负载由 ha-proxy 平衡，但使用 galera，我几乎无法获得 3500 TPS。有关信息，ha-proxy 作为独立节点托管在不同的服务器上。到目前为止，我已经删除了 ha-proxy，但性能没有任何改善。

有人可以建议 my.cnf 中的一些调整参数，我应该考虑调整这个性能严重不足的设置。

我正在使用下面的 my.cnf 文件：

【问题讨论】：

首先，这个问题应该在dba.stackexchange.com上。此外，告诉我们您的配置比列出所有可能的一般性能提示更容易。通常，galera 集群的写入/事务性能比单个实例慢（因为节点必须通信）。 35% 低于预期，但这取决于您实际在做什么（表设计/查询）来判断它是否在配置中。另请注意，双节点集群实际上会增加集群失败的可能性（因为如果这两个节点中的任何一个失败，则两者都会失败）。
感谢 Solarflare，将在 dba.stackexchange.com 上发布此内容。我还在问题中提供了 my.cnf 参数。

标签： mysql mariadb database-administration percona galera

【解决方案1】：

关闭 QC：

query_cache_size = 0  -- not 22 bytes
query_cache_type = OFF -- QC is incompatible with Galera

增加innodb_io_capacity

两个节点相距多远（ping 时间）？

建议你假装它是主从。也就是说，让 HAProxy 将所有流量发送到一个节点，将另一个作为热备份。在这种模式下，某些事情可以运行得更快；我不知道你的应用。

【讨论】：

嗨 rick，节点在同一个 vpc 和同一个子网中，我猜 ping 时间小于 50 毫秒。我使用 galera 的唯一目的是查看我是否可以在保留公共数据的同时利用两台机器的 CPU，以便我的应用程序可以虚拟地读取和写入一组数据。我有一种感觉，galera 可能不是我这样做的最佳选择。你怎么看？有什么建议，NDB 怎么样？
50 毫秒约为 1500 英里/2500 公里。 50ms 会显着降低性能。您实际上是否在一台机器上消耗了一半以上的内核？请记住，需要 CPU 处理来处理接收端的复制。
NDB 还有很多其他问题，包括在 SQL 中可以/不可以做什么的重大变化。
请注意，建议的配置更改中的 cmets 不再准确。 Galera 现在支持查询缓存，从 MariaDB 版本“5.5.40-galera”、“10.0.14-galera”和“10.1.2”开始。 mariadb.com/kb/en/library/query-cache/#limitations
@DaveSherohman - 嗯......那个参考页面很模糊。即使支持 QC，我想知道它在 Galera 环境中是否有额外的开销。对于 90+% 的生产系统，实际上最好关闭 QC。

【解决方案2】：

使用具有以下配置的单个 mariadb 服务器：36 vpcu，60 GB RAM、SSD、10Gig 专用管道

虽然我使用的是 2，但使用 galera 我几乎无法获得 3500 TPS 由 ha-proxy 负载均衡的 DB 节点（36vcpu，60 GB RAM）。

基于 Galera 的集群并非旨在扩展写入，我认为您打算这样做；事实上，正如 Rick 上面提到的：为同一个表发送写入到多个节点最终会导致认证冲突，这将反映为您的应用程序的死锁，从而增加了巨大的开销。

我在 galera 设置中得到了令人无法接受的低性能创建的。在我的设置中，有 2 个节点处于活动状态，我正在做使用 HA-proxy 以循环方式在两个节点上读/写负载均衡器。

请将所有写入发送到单个节点，看看这是否会提高性能；由于 Galera 使用的虚拟同步复制的性质，总会有一些开销，这实际上会为您执行的每次写入增加网络开销（尽管真正的基于时钟的并行复制会在很大程度上抵消这种影响，但您仍然必须看到吞吐量略低）。

此外，请确保您的事务保持简短，并在完成原子工作单元后立即提交，因为复制验证过程是单线程的，并且会停止其他节点上的写入（如果您看到您的编写器节点显示事务 wsrep 预提交阶段，这意味着其他节点正在为大型事务进行认证，或者该节点正在遭受某种性能问题 - 交换、磁盘满、滥用大读取等。

希望对您有所帮助，并让我们知道您迁移到单节点时的情况。

【讨论】：

实际上在product page of the galera cluster website 上，他们非常清楚地表明它现在旨在扩展写入