![什么可能导致 MySQL 5.0.67 安装突然崩溃?](https://linux22.com/image/516554/%E4%BB%80%E4%B9%88%E5%8F%AF%E8%83%BD%E5%AF%BC%E8%87%B4%20MySQL%205.0.67%20%E5%AE%89%E8%A3%85%E7%AA%81%E7%84%B6%E5%B4%A9%E6%BA%83%EF%BC%9F.png)
我有一个旧的 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、内存和交换)的行为。
希望这可以帮助。