【MySQL】PMM如何帮忙找出MySQL服务停止的原因

没有人希望，但数据库服务器可能会在某个时间停止处理连接。从而导致应用程序变慢，甚至停止响应。

在这种情况下，PMM是一个很大的帮助。如果查看监控图表并注意到其中许多开始显示异常行为，你需要做出反应。在卡顿的情况下，你会看到某些活动变为 0；或者，它会增加到很高的数字。

让我们看一下仪表板“MySQL Instance Summary”和它的图表“MySQL Client Thread Activity”在正常操作期间：

如你所见，活跃线程的数量会波动，这对于任何健康的应用程序来说都是正常的：即使所有连接都请求数据，MySQL也会将一些在存储引擎在为它们准备数据的线程、或对应的客户端应用程序在处理检索到的数据的线程置于空闲状态。

 

下一个屏幕截图是在服务器卡顿时截取的：​

在这张图片中，可以看到活跃线程的数量接近最大值。与此同时，“MySQL Temporary Objects”的数量降至零。这本身就表明发生了一些不寻常的事情。但是为了更好地理解图片，让我们检查一下存储引擎图。

 

大多数MySQL用户一样，我在这个例子中使用了InnoDB。 因此，弄清楚发生了什么的下一步是检查“MySQL InnoDB Details”仪表板中的图表。

首先，我们看到InnoDB每秒读取的行数以及写入的行数都下降到了零。这意味着某些东西阻止了InnoDB执行操作。

 

更重要的是，我们看到所有I/O操作都停止了。即使在不处理任何用户连接的服务器上，这也是不寻常的：InnoDB总是执行后台操作并且永远不会完全空闲。

 

可能会在“InnoDB Logging Performance”图中看到这一点：InnoDB仍然使用日志文件，但仅用于后台操作。

 

 

InnoDB缓冲池活动也停止了。这里有趣的是脏页的数量降到了零。这在“InnoDB Buffer Pool Data”图上可见：脏页以黄色着色。这实际上表明，当InnoDB停止处理用户查询时，InnoDB能够从缓冲池中刷新所有脏页。

此时我们可以得出第一个结论，即我们的卡顿是由一些外部锁引起的，导致MySQL和InnoDB无法处理用户请求。

“Transaction History”图证实了这一猜测：没有新事务，InnoDB能够在卡顿发生之前刷新队列中等待的所有事务。

 

我们可以得出结论：我们没有遇到硬件问题。

这个组图展示了我们为什么会遇到这种卡顿。正如在“InnoDB Row Lock Wait Time”图中看到的那样，等待时间在14:02 左右升至最大值，然后降至零。在卡顿期间没有注册行锁等待。

这意味着在某些时候，所有InnoDB事务都在等待行锁，然后因超时而失败。不过，他们必须等待一些事情。由于没有硬件问题并且InnoDB在后台运行正常，这意味着所有线程都在等待由服务器创建的全局MDL锁。

如果我们启用了查询分析 (QAN)，我们可以轻松找到这样的命令。

对于选定的时间范围，我们可以看到许多查询一直在运行，直到某个时间发出id为2的查询，然后其他查询停止运行并在几分钟后重新启动。id为2的查询是FLUSH TABLES WITH READ LOCK，一旦表被刷新，它会阻止任何写入活动。

这是导致服务器完全停止的命令。

一旦我们知道原因，我们就可以采取措施防止将来出现类似问题。