我有一个旧的Ubuntu 8.10 32位与MySQL 5.0.67。
其中有5.7GB的数据，每天增长大约100MB。
大约3天前，MySQL实例在夜间mysqldump期间突然死亡（无日志条目）。
什么可能导致它？
升级MySQL对我来说是一个长期的项目，除非5.0.67中有一个特定的错误，那么我想我只需要重新设置优先级。
我希望有人可能会熟悉这个问题，因为这是一个相当受欢迎的版本与Ubuntu 8.10捆绑在一起。
谢谢
有一个非常大的桌子被倾倒或一堆中等大小的桌子吗？ 你使用mysqldump的-q选项？ 有没有一张正在写入的大表格？ 如果是这样，locking一个大表将阻止任何其他线程执行，由于锁的持有可能会导致您的Web服务器/脚本等待，直到机器饥饿的资源。
有可能你在mysql或mysqldump进程中用尽所有可用的内存，导致内核中的OOM（内存不足）杀手结束进程。 为此，您可以查看kern.log，syslog，stringOOM的消息或类似的东西：
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 如果日志中没有条目，我build议您尝试使用mysqldump。
strace -f -o strace.output mysqldump your_mysqldump_options
然后看看文件strace.output的最后几行。 这通常是启迪的方式，这是明星debugging这些问题的上帝之路。
另一方面，像Cacti，Ganglia或Munin这样的趋势应用程序在这类问题中也很有用，因为您可以观察服务器的行为，例如关于tcp连接，cpu，内存和交换等重要指标。
希望这可以帮助。