在站点冗余的 galera 集群上，只有在法定数量的数据库节点接受了事务后，才能返回提交。如果一个数据库节点宕机，所有的提交将被集群的其余部分保留，并且宕机的数据库节点将在再次启动数据库时与集群的其余部分同步。如果数据库应该已经损坏，可以随时核对 mysql 数据目录并从一个空数据库开始，它最终会赶上集群的其余部分。因此，听起来我们可以通过关闭确保本地 ACID 合规性的选项来调整性能。
所以这里的问题真的是......“可能会出什么问题？”
:-)
根据评论，我将提供有关我们特定设置的一些信息：
集群由三个节点组成。其中两个在生产中被积极使用，其中一个比另一个使用得更频繁。第三个节点仅用于仲裁和备份目的。
站点冗余意味着节点位于不同的服务器中心。我发现很难想到会导致两个节点同时关闭的任何事情——除了一个严重的 mysql 错误，这有多大可能？诚然，其中两个节点相距不到 10 公里（备份/仲裁节点相隔数百公里，外加国界）。一枚中型核弹可能会同时摧毁两个节点……再说一次，在这种情况下，“我们的数据库有问题”可能是我们最不关心的问题。太阳风暴可能同时摧毁两个或所有服务器吗？
我们的性能问题是主要的，因为我们的 SAN 上的写入缓存有时会满。我们正在努力缓解这个问题，但我们不能保证它不会再次发生。我们时不时地会遇到“打嗝”，我们的交易等待大约 10-30 秒。
在这个特定的设置中，30 秒的延迟实际上可能是生死攸关的问题。好吧，很可能不是，但如果客户这样认为，那就够糟糕了。如果整个集群出现故障，合理的低延迟和快速恢复是最紧迫的优先事项。丢失一些交易可能已经够糟糕了，但这不是生死攸关的问题。
我们看到的性能问题是写入事务卡在“wsrep in pre-commit”状态。这不是流量控制问题，只是一个节点有问题。我对它进行了一些研究，显然是所有本地写入查询都在等待锁定，而节点正在将远程变更集写入数据库。这个问题应该在 galera 4 中修复，但升级目前不是一个选项。
我们的性能问题只在一个节点上，所以它只在一个节点上我正在考虑关闭那些东西。我会在我们的文档中添加无论发生什么，所说的节点都不应该用于引导集群。
我们不做分片，也不打算做任何分片。除了那些打嗝，我们没有任何性能问题。