Mysql MariaDb故障切换在CPU上运行速度很快，即使在没有流量的情况下也很健谈

我们有一个用scala 2.12.x和Play framework 2.5.x编写的API。API使用MariaDb连接器/J 2.5.4连接到AWS aurora群集，例如

jdbc:mysql:aurora://some-aurora-cluster

功能上一切正常，除了我们注意到即使没有流量，CPU使用率也很高。一些研究表明：

[ec2-user@ip-xxx-xxx-xxx-xxx ~]$ top -H

    …
 6373 root      20   0 4644452 990888  21540 S 14.6 12.6   1:15.68 MariaDb-failove
 6374 root      20   0 4644452 990888  21540 S 13.6 12.6   1:16.11 MariaDb-failove
 6305 root      20   0 4644452 990888  21540 S 13.3 12.6   1:14.31 MariaDb-failove
 6375 root      20   0 4644452 990888  21540 S 12.3 12.6   1:14.59 MariaDb-failove
 6372 root      20   0 4644452 990888  21540 S 11.3 12.6   1:15.78 MariaDb-failove
    …

上面的cmd显示了许多故障转移。我不知道它是做什么的，也不知道为什么会有多个CPU占用率高而繁忙

[ec2-user@ip-xxx-xxx-xxx-xxx ~]$ netstat -a | less

…
tcp6       0      0 ip-xxx-xxx-xxx-31.:37446 ip-xxx-xxx-xxx-129:mysql TIME_WAIT
tcp6       0      0 ip-xxx-xxx-xxx-31.:37108 ip-xxx-xxx-xxx-129:mysql TIME_WAIT
tcp6       0      0 ip-xxx-xxx-xxx-31.:37648 ip-xxx-xxx-xxx-129:mysql TIME_WAIT
tcp6       0      0 ip-xxx-xxx-xxx-31.:36934 ip-xxx-xxx-xxx-129:mysql TIME_WAIT
tcp6       0      0 ip-xxx-xxx-xxx-31.:36870 ip-xxx-xxx-xxx-129:mysql TIME_WAIT
tcp6       0      0 ip-xxx-xxx-xxx-31.:37254 ip-xxx-xxx-xxx-129:mysql TIME_WAIT
tcp6       0      0 ip-xxx-xxx-xxx-31.:37902 ip-xxx-xxx-xxx-129:mysql TIME_WAIT
…

还有很多时间等你。这也很奇怪，因为在我执行这个命令的时候没有流量

[ec2-user@ip-xxx-xxx-xxx-xxx ~]$ netstat -nat | awk '{print $6}' | sort | uniq -c | sort -n

      1 established)
      1 Foreign
      1 SYN_SENT
      6 LISTEN
     37 ESTABLISHED
    851 TIME_WAIT

等待的时间有上百次；每次我执行命令时，数字都在变化

有人知道这是正常的还是我需要担心的事情吗

如果您还有其他问题，请告诉我

========== 更多信息

ps -aux | grep java

得到PID:2655

jstack 2655 > threaddump.log

以下是内容（删减）：

十六进制LWP的PID：

6373 18e5
6374 18e6
6305 18a1
6375 18e7
6372 18e4

========== 更多信息

ps -aux | grep java

我们的API有5种不同的db配置—5种不同的数据库。每个都有一个连接字符串，例如

jdbc:mysql:aurora://some-aurora-cluster

请注意，

aurora

模式用于更好地体验故障转移，因此它解释了5个轻量级流程。但是它们很健谈，导致很多时间等待，可能是CPU使用率提高的原因

[ec2-user@ip-xxx-xxx-xxx-xxx ~]$ netstat -a | less

…
tcp6       0      0 ip-xxx-xxx-xxx-31.:37446 ip-xxx-xxx-xxx-129:mysql TIME_WAIT
tcp6       0      0 ip-xxx-xxx-xxx-31.:37108 ip-xxx-xxx-xxx-129:mysql TIME_WAIT
tcp6       0      0 ip-xxx-xxx-xxx-31.:37648 ip-xxx-xxx-xxx-129:mysql TIME_WAIT
tcp6       0      0 ip-xxx-xxx-xxx-31.:36934 ip-xxx-xxx-xxx-129:mysql TIME_WAIT
tcp6       0      0 ip-xxx-xxx-xxx-31.:36870 ip-xxx-xxx-xxx-129:mysql TIME_WAIT
tcp6       0      0 ip-xxx-xxx-xxx-31.:37254 ip-xxx-xxx-xxx-129:mysql TIME_WAIT
tcp6       0      0 ip-xxx-xxx-xxx-31.:37902 ip-xxx-xxx-xxx-129:mysql TIME_WAIT
…

---

以前有人遇到过这种情况吗？您是如何缓解这种情况的？我仍然希望使用aurora模式（或类似的模式），这样我们就不必在db发生故障时重新启动应用程序。

经过几天的搜索和研究，我终于深入研究了MariaDb驱动程序代码，特别是在线程转储显示的区域，并继续跟踪代码堆栈

我找到了一个对设置

retriesAllDown

的引用，该设置的默认值为120。进一步阅读MariaDb驱动程序知识库页面，我还发现了另一个设置

failoverLoopRetries

，它具有相同的默认值120

在此处，您可以阅读有关MariaDb驱动程序设置的更多信息：

对于我们的团队和API，我们对值12（默认值的10%）感到满意，并决定在两种设置中都使用该值，因此下面是修改后的连接字符串：

jdbc:mysql:aurora://some-aurora-cluster?retriesAllDown=12&failoverLoopRetries=12

这大大简化了CPU的使用，并且仍然保持了我们所需要的故障转移功能

---

希望这个答案能帮助其他人。我不会把它作为我原来问题的答案，直到它至少帮助了10个人。

经过几天的搜索和研究，我终于深入研究了MariaDb驱动程序代码，特别是在线程转储显示的区域，并继续跟踪代码堆栈

我找到了一个对设置

retriesAllDown

的引用，该设置的默认值为120。进一步阅读MariaDb驱动程序知识库页面，我还发现了另一个设置

failoverLoopRetries

，它具有相同的默认值120

在此处，您可以阅读有关MariaDb驱动程序设置的更多信息：

对于我们的团队和API，我们对值12（默认值的10%）感到满意，并决定在两种设置中都使用该值，因此下面是修改后的连接字符串：

jdbc:mysql:aurora://some-aurora-cluster?retriesAllDown=12&failoverLoopRetries=12

这大大简化了CPU的使用，并且仍然保持了我们所需要的故障转移功能

希望这个答案能帮助其他人。我不会把它作为我原来问题的答案，除非它至少帮助了10个人