问XtraDB集群的设计

EN

1. 是的，这是个好主意。在PXC中使用ProxySQL也是一个好主意。通过使用ProxySQL，您可以: A)通过将两个节点放入同一个主机组来实现“写器”HA，一个节点具有超高的权重(10000000)，另一个节点位于低的主机组(10)中。如果高权重节点脱机，ProxySQL将无缝地开始向另一个节点发送通信量.将所有节点放入一个独立的具有相同权重的“读取器”主机组中，从而实现负载平衡写入通信量。C)如果需要，创建一个只包含1个节点的第三个主机组，并在模式、用户或查询模式上为您的“高负载”查询创建一个查询规则到模式匹配，并直接执行到该特定节点。ProxySQL还将允许您缓存其中一些非常重要的查询。
2. 就我个人而言，除非你知道你的网络是坚如磐石的，否则我会选择更少的CPU实例。在PXC中，所有节点必须同步地ACK所有事务。节点越多，这些操作所需的等待时间就越长。最快的提交时间是两个最慢的节点之间的时间。请确保总是有一个奇数的节点，除非您使用pc.weight设置进行了高级处理(但这是非常困难的)。
3. 对于一般的MySQL，所有节点都应该是相同的配置。如果你的主人比奴隶更强大，一般来说，奴隶将无法跟上音量。使用PXC，这意味着您将更频繁地体验流控制事件，这些事件可以转换为应用程序停止。如果node2无法以最快的速度编写node1，则node2发送流控制消息(呼救)，要求其他节点在追赶时减速。
4. 是的，如#1所述，使用ProxySQL。

附带注意，查询优化是“加快速度”的第一种方式。不要总是用硬件来解决问题。检查缓慢的查询日志并尝试改进查询是值得的。有时，一个单一的指数可以使夜间/白天的变化。

免责声明:我是Percona的高级讲师，并提供了许多全天的PXC和ProxySQL强化教程课程。

看来你的尖峰是问题所在。而且你需要尽可能快地处理洪水，因为用户希望得到那些热票。

添加队列只会增加复杂性，并在动作快时减慢处理速度。所以“不要排队，只管去做。”进一步注意，队列将被传递到其他节点，从而使得enqueue/dequeue可能比简单地处理请求慢一些！

连接--做某事--断开连接需要时间。很多时候并不是真正涉及到“某物”，而是围绕在它周围的开销。我发现，如果只有不到10个连接处于活动状态，事情就会顺利进行。但如果有10多家公司成功起步，那么InnoDB就会开始自食其力。

去过拥挤的商店吗？比方说，所有过道上都有200人和大车的空间。但是，如果你想拥有210名购物者，那么每个人都会放慢脚步，只是想找个位置。吞吐量下降，也许到了人们想要放弃他们的手推车休假的地步。你看过前面排队的商店吗？他们解决了这个问题，不允许200多人同时购物！

因此，您的问题的解决方案可能是以外的MySQL。如果您有一个面向MySQL的网页，请将其节流以限制它使用的“线程”的数量。例如，Apache有这样的功能，加上在连接到Apache级别排队的“待办事项”。MySQL的max_connections和backlog可能以同样的方式工作，但是max_connections (151)的默认值太高了。在便利店里聚集在汽水机周围的151名学生可能是一个更好的比喻。

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

Monitor Threads_running；如果它增长到几十个，那么我想我的评论也适用。如果监视器程序无法连接到检查该GLOBAL STATUS，那么我知道它适用。