MySQL故障诊断工作流

Question

在最近的几次采访中，我被要求解释我的工作流程，以解决或解决与MySQL有关的问题。以下是他们提出这个问题的方式：

1. 解释您为响应、排除故障和解决数据库问题而采取的步骤或措施。
2. 您是否使用监视和绘图工具？解释一下你在什么情况下使用它们？

就个人而言，如果出现了问题，比如过多的线程，或者对性能或服务(不是db崩溃)有影响的数据库中的任何问题，我做的第一件事就是使用或mytop检查该DB上正在运行的进程。这通常会让我了解数据库服务器上正在进行的活动。然后我还会查看我们的xymon监控系统，看看它是否检测到了该服务器的任何问题，例如磁盘问题、Raid问题、内存问题(例如交换)、高CPU使用率等。因此，这是我在处理第一个问题时的工作流程。

我想从其他DBA那里获得一些关于他们在生产环境中处理数据库事件的工作流程的好主意。所以，请用你自己的工作流程来回答我上面的两个问题。

Answer 1

为了发现性能问题并开始着手，我最喜欢的工具是SlowLog。通过保持它的开启和long_query_time的低价值，我可以回顾过去，看看过去是什么导致了经济放缓。此外，它还将指向应该调查的特定查询(或多个查询)。

我认为，大多数非崩溃问题将在某种程度上反映在慢速日志中。

有时候有些事情是很难调查的。一个奴隶跑得比其他奴隶慢得多，尽管没有任何迹象表明流量激增等等。即使是慢日志也更令人困惑，而不是有帮助。过了一会儿，问题就解决了。有几个人在调查。问题在于RAID控制器‘循环’它的电池，在此期间，它禁用了“电池支持的写缓存”。

Monyog和MEB是一个工具($$)，它提供了对许多度量标准的大量持续监视。然后问题就变成了知道该看什么。

很多时候，我遇到过一些客户端，它们很高兴地连接到MySQL。(例如:MaxClients值很高的Apache。)通常这并不是一个问题，因为MySQL很快就完成了任务。但有时MySQL会不知所措。解决方法是(在我看来)控制客户端将与MySQL建立多少连接。仅在几十个活动连接之后，MySQL就开始蹒跚而行(锁、互斥、I/O、CPU等)。解决方案可能是加速查询(请参阅SlowLog)，也可能是限制客户端。Threads_running (目前)和Max_used_connections (事后，但没有给出时间)是这种情况可能发生的线索。

在这种情况下，SlowLog将显示通常速度较快的缓慢查询。在特定的时间，它会显示出许多缓慢的查询--来自许多不同的连接(客户端)。

我有几百个公式(状态和变量)和推荐的范围。这偶尔会派上用场。其中一些人说缓存(查询、Buffer_pool、Key_buffer、Table_open等)是有效的还是低效的。不幸的是，他们很少说“把xx改为yy”。

一个项目在一小时开始时就出现了尖峰。很明显的答案是“cron”。当然，有超过100个cron工作，每一个在你的顶端，可能在其他时间。解决方案:而不是

*/5 * * * * do_something.sh

做

(3-59)/5 * * * * do_something.sh

(并将不同cron作业的“3”更改为各种值。)摩根士丹利( MySQL EVENTs )也可以成为一名制穗者。

许多监控工具可以发现这样一个小时的尖峰。即使是一个警觉的人也能注意到这一点。但是，很少有监控工具会告诉你该怎么做。

真正的问题是工具给你线索，而不是答案。这是人类需要介入的地方。人类需要对“系统”、可调性、查询、模式、如何创建好的索引等方面的知识。