设计 XtraDB 集群
Designing XtraDB cluster
我们有一个应用程序，其中包含所有连接到同一个 Percona 数据库实例的微服务。目前它只是一个具有 16 cores/32 GB 内存且没有复制的实例。我们的一个问题是，有时我们的一个微服务会对数据库造成如此高的负载（甚至只是读取），这使得所有微服务都无法使用。
我们正在考虑创建一个由三个节点组成的 Percona 集群，并为每个微服务选择节点。大多数 "write" 的服务将连接到一个实例，其余服务将连接到另外两个实例。这样，如果某些微服务导致高读取负载，它不应该完全淹没我们的基础设施。
我的问题：
- 这是个好主意吗？难道我们不应该让 ProxySQL 处理拆分流量吗？ ProxySQL 可能意味着没有隔离。
- 我们是应该拥有更多 CPU 更少的实例，还是拥有更多 CPU 的更少实例？在高负载的情况下，拥有更多实例意味着 运行 微服务有更多隔离。
- 让节点具有不同的 CPU 是个好主意吗？例如，与 "reading instances".
相比，让 "writing instance" 具有更多 CPU
- 如果我们将微服务指向 "their Percona instance"，当它们的实例完全死亡时，我们是否仍然可以拥有某种 HA？
注意：我们可能会在 GCE 中使用 Percona XtraDB 单击部署：https://console.cloud.google.com/marketplace/details/click-to-deploy-images/percona?project=goout-cloud&folder&organizationId=74390800864
是的，这是个好主意。将 ProxySQL 与 PXC 一起使用也是一个好主意。通过使用 ProxySQL，您可以： A) 通过将两个节点放入同一主机组来实现 "writer" HA，一个具有超高权重 (10000000)，另一个具有低权重 (10)。如果高权重节点下线，ProxySQL 将无缝开始向其他节点发送流量。 B) 将所有节点放入一个单独的 "reader" 具有相同权重的主机组，从而负载平衡写入流量。 C) 如果需要，创建一个只有 1 个节点的第三个主机组，并创建一个查询规则以模式匹配模式、用户或您的 "high load" 查询的查询模式，并直接执行到该特定节点。 ProxySQL 还可以让您缓存一些重要的查询。
就个人而言，除非您知道您的网络坚如磐石，否则我会选择较少的 CPU 实例。在 PXC 中，所有节点必须同步确认所有交易。您拥有的节点越多，这些操作的延迟时间就越长。您可以提交的最快时间是两个最慢节点之间的时间。请确保您的节点数始终为奇数，除非您使用 pc.weight 设置进行了高级设置（但这很难正确设置）。
与MySQL一般来说，所有节点应该是相同的配置。如果你的主人比奴隶厉害，一般来说，奴隶的音量是跟不上的。使用 PXC，这意味着您将更频繁地体验流量控制事件，这可能会转化为应用程序停顿。如果 node2 不能写得像 node1 一样快，node2 发出流量控制消息，（求救），要求其他节点在它赶上时慢下来。
是的，使用 #1 中描述的 ProxySQL。
旁注，查询优化是解决问题的第一方法"speed things up." 不要总是用硬件来解决问题。花时间检查您的慢速查询日志并尝试改进查询是值得的。有时，单个索引可以产生 night/day 差异。
免责声明：我是 Percona 的高级讲师，已经讲过无数次全天的 PXC 和 ProxySQL 强化教程课程。
看来问题出在你的 尖刺 上。而且您需要尽快处理洪水，因为用户期望获得那些热票。
添加队列只会增加复杂性并在操作快速时减慢处理速度。所以 "Don't queue it, just do it." 进一步注意队列将被过渡复制到其他节点，从而使 enqueue/dequeue 可能比简单地响应请求更慢！
连接 - 做点什么 - 断开连接需要时间。很多时候并没有真正参与 "something"，而是围绕它进行开销。我发现如果活动连接少于 10 个，事情 运行 会很顺利。但是如果超过 10 个设法开始，那么 InnoDB 就会开始绊倒自己。
曾经去过拥挤的商店吗？假设在所有过道中都有可容纳 200 人和手推车的空间。但是，如果您尝试拥有 210 名购物者，那么每个人都会放慢脚步，只是想争夺一个位置。吞吐量下降，可能到了人们想要放弃购物车离开的地步。见过前面排长队的商店吗？他们通过不允许超过 200 名同时购物者解决了这个问题！
因此，您的问题的解决方案可能在 MySQL 之外。如果您有一个网页前端 MySQL，请限制它以限制它正在使用的 'threads' 的数量。例如，Apache 有这样的功能，加上一个 "backlog" 用于在连接到 Apache 级别排队。 MySQL 有 max_connections 和 backlog 可能以相同的方式工作，但 max_connections (151) 的默认值太高了。 151名学生挤在便利店的汽水机周围可能是一个更好的比喻。
更多 个节点/更多 CPU 可能 也可能不会 成为答案的一部分；这取决于 "something".
取出了什么锁
监控Threads_running;如果它增长到几十个以上，那么我怀疑我的评论适用。如果监控程序无法连接以检查 GLOBAL STATUS，那么我知道它适用。
我们有一个应用程序，其中包含所有连接到同一个 Percona 数据库实例的微服务。目前它只是一个具有 16 cores/32 GB 内存且没有复制的实例。我们的一个问题是，有时我们的一个微服务会对数据库造成如此高的负载（甚至只是读取），这使得所有微服务都无法使用。
我们正在考虑创建一个由三个节点组成的 Percona 集群，并为每个微服务选择节点。大多数 "write" 的服务将连接到一个实例，其余服务将连接到另外两个实例。这样，如果某些微服务导致高读取负载，它不应该完全淹没我们的基础设施。
我的问题：
- 这是个好主意吗？难道我们不应该让 ProxySQL 处理拆分流量吗？ ProxySQL 可能意味着没有隔离。
- 我们是应该拥有更多 CPU 更少的实例，还是拥有更多 CPU 的更少实例？在高负载的情况下，拥有更多实例意味着 运行 微服务有更多隔离。
- 让节点具有不同的 CPU 是个好主意吗？例如，与 "reading instances". 相比，让 "writing instance" 具有更多 CPU
- 如果我们将微服务指向 "their Percona instance"，当它们的实例完全死亡时，我们是否仍然可以拥有某种 HA？
注意：我们可能会在 GCE 中使用 Percona XtraDB 单击部署：https://console.cloud.google.com/marketplace/details/click-to-deploy-images/percona?project=goout-cloud&folder&organizationId=74390800864
是的，这是个好主意。将 ProxySQL 与 PXC 一起使用也是一个好主意。通过使用 ProxySQL，您可以： A) 通过将两个节点放入同一主机组来实现 "writer" HA，一个具有超高权重 (10000000)，另一个具有低权重 (10)。如果高权重节点下线，ProxySQL 将无缝开始向其他节点发送流量。 B) 将所有节点放入一个单独的 "reader" 具有相同权重的主机组，从而负载平衡写入流量。 C) 如果需要，创建一个只有 1 个节点的第三个主机组，并创建一个查询规则以模式匹配模式、用户或您的 "high load" 查询的查询模式，并直接执行到该特定节点。 ProxySQL 还可以让您缓存一些重要的查询。
就个人而言，除非您知道您的网络坚如磐石，否则我会选择较少的 CPU 实例。在 PXC 中，所有节点必须同步确认所有交易。您拥有的节点越多，这些操作的延迟时间就越长。您可以提交的最快时间是两个最慢节点之间的时间。请确保您的节点数始终为奇数，除非您使用 pc.weight 设置进行了高级设置（但这很难正确设置）。
与MySQL一般来说，所有节点应该是相同的配置。如果你的主人比奴隶厉害，一般来说，奴隶的音量是跟不上的。使用 PXC，这意味着您将更频繁地体验流量控制事件，这可能会转化为应用程序停顿。如果 node2 不能写得像 node1 一样快，node2 发出流量控制消息，（求救），要求其他节点在它赶上时慢下来。
是的，使用 #1 中描述的 ProxySQL。
旁注，查询优化是解决问题的第一方法"speed things up." 不要总是用硬件来解决问题。花时间检查您的慢速查询日志并尝试改进查询是值得的。有时，单个索引可以产生 night/day 差异。
免责声明：我是 Percona 的高级讲师，已经讲过无数次全天的 PXC 和 ProxySQL 强化教程课程。
看来问题出在你的 尖刺 上。而且您需要尽快处理洪水，因为用户期望获得那些热票。
添加队列只会增加复杂性并在操作快速时减慢处理速度。所以 "Don't queue it, just do it." 进一步注意队列将被过渡复制到其他节点，从而使 enqueue/dequeue 可能比简单地响应请求更慢！
连接 - 做点什么 - 断开连接需要时间。很多时候并没有真正参与 "something"，而是围绕它进行开销。我发现如果活动连接少于 10 个，事情 运行 会很顺利。但是如果超过 10 个设法开始，那么 InnoDB 就会开始绊倒自己。
曾经去过拥挤的商店吗？假设在所有过道中都有可容纳 200 人和手推车的空间。但是，如果您尝试拥有 210 名购物者，那么每个人都会放慢脚步，只是想争夺一个位置。吞吐量下降，可能到了人们想要放弃购物车离开的地步。见过前面排长队的商店吗？他们通过不允许超过 200 名同时购物者解决了这个问题！
因此，您的问题的解决方案可能在 MySQL 之外。如果您有一个网页前端 MySQL，请限制它以限制它正在使用的 'threads' 的数量。例如，Apache 有这样的功能，加上一个 "backlog" 用于在连接到 Apache 级别排队。 MySQL 有 max_connections 和 backlog 可能以相同的方式工作，但 max_connections (151) 的默认值太高了。 151名学生挤在便利店的汽水机周围可能是一个更好的比喻。
更多 个节点/更多 CPU 可能 也可能不会 成为答案的一部分；这取决于 "something".
取出了什么锁监控Threads_running;如果它增长到几十个以上，那么我怀疑我的评论适用。如果监控程序无法连接以检查 GLOBAL STATUS，那么我知道它适用。