设计 XtraDB 集群

Question

我们有一个应用程序，它由所有连接到同一个 Percona 数据库实例的微服务组成。目前它只是一个没有复制的 16 核/32 GB 内存的实例。我们的问题之一是，有时我们的一个微服务会导致数据库负载如此之高（甚至只是读取），这使得所有微服务都无法使用。

我们正在考虑创建一个由三个节点组成的 Percona 集群，并为每个微服务选择节点。大多数“写入”的服务将连接到一个实例，其余的将连接到其他两个实例。这样，如果某些微服务导致读取负载过高，它不应该完全压垮我们的基础架构。

我的问题：

1. 这是个好主意吗？我们不应该让 ProxySQL 处理流量拆分吗？ ProxySQL 可能意味着没有隔离。
2. 我们应该有更多的 CPU 更少的实例，还是更少的 CPU 更多的实例？拥有更多实例意味着在高负载情况下运行微服务的隔离度更高。
3. 拥有不同 CPU 的节点是个好主意吗？比如让“写实例”比“读实例”有更多的CPU。
4. 如果我们将微服务定向到“他们的 Percona 实例”，当他们的实例完全死机时，我们还能拥有某种 HA 吗？

注意：我们可能会在 GCE 中使用 Percona XtraDB click-to-deploy：https://console.cloud.google.com/marketplace/details/click-to-deploy-images/percona?project=goout-cloud&folder&organizationId=74390800864

Answer 1

您的尖峰似乎是问题所在。而且您需要尽快处理泛滥，因为用户期望获得这些热门票证。

添加队列只会增加复杂性并在动作快速时减慢处理速度。所以“不要排队，就去做吧。”进一步注意，队列将被过渡复制到其他节点，从而使入队/出队可能比简单地处理请求更慢！

连接 - 做某事 - 断开连接需要时间。很多时候并没有真正参与“某事”，而是围绕它的开销。我发现如果少于大约 10 个连接处于活动状态，事情就会顺利进行。但是如果超过 10 人设法开始，那么 InnoDB 就会开始绊倒自己。

去过拥挤的商店吗？假设所有过道都有可容纳 200 人和推车的空间。但是，如果您尝试拥有 210 名购物者，那么每个人都只是为了争夺一个位置而放慢了速度。吞吐量下降，可能到了人们想要放弃购物车的地步。见过前面排着长队的商店吗？他们通过不允许超过 200 名同时购物者解决了这个问题！

因此，您的问题的解决方案可能在 MySQL 之外。如果您有一个面向 MySQL 的网页，请限制它以限制它正在使用的“线程”数量。例如，Apache 就有这样的功能，外加一个用于在连接到 Apache 级别排队的“积压”。 MySQL 有 max_connections 和 backlog 可能以相同的方式工作，但 max_connections (151) 的默认值太高。 151 名学生围在便利店的汽水机旁可能是一个更好的类比。

更多节点/更多 CPU 可能也可能不是答案的一部分；这取决于“某物”取出了哪些锁。

监控 Threads_running;如果它增长到几十个以上，那么我怀疑我的 cmets 适用。如果监控程序无法连接以检查GLOBAL STATUS，那么我知道它适用。

Answer 2

1. 是的，这是个好主意。将 ProxySQL 与 PXC 一起使用也是一个好主意。通过使用 ProxySQL，您可以： A) 通过将两个节点放入同一个主机组来实现“编写器”HA，一个具有超高权重 (10000000)，另一个具有低权重 (10)。如果高权重节点下线，ProxySQL 将无缝开始向其他节点发送流量。 B）将所有节点放入具有相同权重的单独“读取器”主机组中，从而负载平衡写入流量。 C）如果需要，创建一个只有 1 个节点的第三个主机组，并创建一个查询规则以模式匹配模式、用户或查询模式，以用于“高负载”查询并直接执行到该特定节点。 ProxySQL 还可以让您缓存一些重要的查询。

2. 就个人而言，除非您知道您的网络坚如磐石，否则我会选择较少的 CPU 较高的实例。在 PXC 中，所有节点必须同步 ACK 所有事务。您拥有的节点越多，这些操作所需的延迟就越长。您可以提交的最快的是两个最慢节点之间的时间。请确保您始终拥有奇数个节点，除非您使用 pc.weight 设置进阶（但要正确设置非常棘手）。

3. 一般来说，对于 MySQL，所有节点都应该是相同的配置。如果你的主人比奴隶更强大，一般来说奴隶会跟不上音量。使用 PXC，这意味着您将更频繁地遇到流控制事件，这可能会导致应用程序停顿。如果 node2 不能像 node1 那样快速写入，则 node2 发送流控制消息，（求救），要求其他节点在它赶上时减速。

4. 是的，使用 #1 中描述的 ProxySQL。

旁注，查询优化是“加快速度”的第一方法。不要总是在问题上扔硬件。值得花时间检查您的慢查询日志并尝试改进查询。有时，一个索引就可以产生昼夜差异。

免责声明：我是 Percona 的高级讲师，已经提供了许多全天的 PXC 和 ProxySQL 密集型教程课程。