17

今天早上，我注意到我们的 MySQL 服务器负载飙升。Max 应该是 8，但它在某一时刻达到了 100 以上。当我检查进程列表时，我发现大量处于query end状态的更新查询（简单的，递增“hitcounter”）。我们无法杀死他们（好吧，我们可以，但他们会killed无限期地留在该州）并且我们的网站陷入停顿。

我们在重新启动服务时遇到了很多问题，不得不强行终止一些进程。当我们这样做时，我们能够让 MySQLd 重新启动，但进程立即又开始建立起来。据我们所知，此时尚未更改任何配置。

因此，我们innodb_flush_log_at_trx_commit从 2 更改为 1（请注意，我们需要符合 ACID），希望这可以解决问题，并将 PHP/PDO 中的连接设置为持久。这似乎工作了一个小时左右，然后连接再次开始耗尽。

幸运的是，我在几个月前建立了一个从服务器，并且能够对其进行推广，现在它正在填补空缺，但我需要了解为什么会发生这种情况以及如何阻止它，因为从服务器的功能严重不足和主人相比，所以我需要尽快切换回来。

有人有什么想法吗？莫非是有什么需要清理的？我不知道是什么，也许是二进制日志之类的？有什么想法吗？我们可以尽快将这台服务器恢复为主服务器，这一点非常重要，但坦率地说，我不知道去哪里看，到目前为止我所做的一切都只是临时修复。

帮助！:)

4

4 回答 4

30

我会在这里回答我自己的问题。我用一个简单的命令检查了分区大小，df我可以看到 /var 是 100% 满的。我找到了一个有人留下的档案，大小为 10GB。删除它，启动 MySQL，运行PURGE LOGS BEFORE '2012-10-01 00:00:00'查询以清除大量空间并将 /var/lib/mysql 目录大小从 346GB 减少到 169GB。改回大师，一切都再次运行良好。

从这里我了解到我们的日志文件变得非常大，非常快。因此，我将建立一个维护例程，不仅可以保持日志文件的关闭，还可以在我们接近完整分区时提醒我。

我希望这对将来遇到同样问题的人有所帮助。检查您的驱动器空间！:)

于 2012-11-05T15:37:16.910 回答
7

我们遇到了一个非常相似的问题，mysql 进程列表显示我们几乎所有的连接都停留在“查询结束”状态。我们的问题也与复制和写入二进制日志有关。

我们将 sync_binlog 变量从 1 更改为 0，这意味着不是在每次提交时将 binlog 更改刷新到磁盘，而是允许操作系统决定何时将 fsync() 写入 binlog。这完全解决了我们的“查询结束”问题。

根据Mats Kindahl 的这篇文章，在 MySQL 5.6 版本中写入 binlog 不会成为问题。

于 2013-01-12T23:22:50.723 回答
3

就我而言，这表明磁盘上的 I/O 已达到极限。我已经将 fsyncs 减少到最低限度，所以不是这样。另一个症状是“log*.tokulog*”文件开始累积，因为系统无法赶上所有写入。

于 2016-10-26T01:55:53.967 回答
0

我在生产用例中遇到了这个问题。我在表格中使用 replace into select 进行归档，它有 100 万条记录 init 。我在中间打断了查询，它进入了killed状态。

我已经将 innodb_flush_log_at_trx_commit 设置为 1 以及 sync_binlog=1 并且在我的情况下它完全恢复了。而且我再次触发了我的存档脚本，没有任何问题。

于 2021-03-29T21:31:38.617 回答