☰

什么可能导致 MySQL 5.0.67 安装突然崩溃？

tag-icon • tag-icon mysql
什么可能导致 MySQL 5.0.67 安装突然崩溃？

我有一个旧的 32 位 Ubuntu 8.10，带有 MySQL 5.0.67。

其中有 5.7GB 的数据，并且每天增加约 100MB。

大约 3 天前，MySQL 实例在夜间 mysqldump 期间突然安静地死亡（没有日志条目）。

这可能是什么原因造成的？

升级 MySQL 对我来说是一个长期项目，除非 5.0.67 中恰好出现特定的错误，那么我想我只需要重新调整优先级。

我希望有人可能熟悉这个问题，因为这是与 Ubuntu 8.10 捆绑的一个相当流行的版本。

谢谢

答案1

正在转储的表是否非常大，或者一堆中等大小的表？您是否在 mysqldump 中使用 -q 选项？您正在转储的表是否正在写入？如果是这样，锁定大表将阻止任何其他线程执行，因为锁定可能导致您的 Web 服务器/脚本等待，直到机器资源匮乏。

有可能您在 mysql 或 mysqldump 进程上用完了所有可用内存，导致内核中的 OOM（内存不足）终止程序终止该进程。为此，您可以查看 kern.log、syslog、字符串 OOM 的消息或类似内容：

Mar 29 16:51:10 xxxxxx kernel: 160688 total pagecache pages
Mar 29 16:51:10 xxxxxx kernel: 2048 pages in swap cache
Mar 29 16:51:10 xxxxxx kernel: Swap cache stats: add 25966, delete 23918, find 150791/151181
Mar 29 16:51:10 xxxxxx kernel: Free swap  = 8228916kB
Mar 29 16:51:10 xxxxxx kernel: Total swap = 8297564kB
Mar 29 16:51:10 xxxxxx kernel: 2228208 pages RAM
Mar 29 16:51:10 xxxxxx kernel: 183093 pages reserved
Mar 29 16:51:10 xxxxxx kernel: 2208385 pages shared
Mar 29 16:51:10 xxxxxx kernel: 1864656 pages non-shared
Mar 29 16:51:10 xxxxxx kernel: mysqld: page allocation failure. order:1, mode:0x20

答案2

如果日志中没有条目，我建议您尝试 strace mysqldump。

strace -f -o strace.output mysqldump your_mysqldump_options

然后查看文件 strace.output 的最后几行。这通常会启发思路，并且是开始调试这些问题的好方法。

另一方面，Cacti、Ganglia 或 Munin 等趋势应用程序在解决此类问题时也很有用，因为您可以观察服务器有关重要指标（例如 tcp 连接、cpu、内存和交换）的行为。

希望这可以帮助。

相关内容