☰

什麼可能導致 MySQL 5.0.67 安裝突然崩潰？

tag-icon • tag-icon mysql
什麼可能導致 MySQL 5.0.67 安裝突然崩潰？

我有一個舊的 Ubuntu 8.10 32 位元和 MySQL 5.0.67。

其中有 5.7GB 的數據，並且每天以約 100MB 的速度成長。

大約 3 天前，MySQL 實例在夜間 mysqldump 期間開始突然安靜地死亡（沒有日誌條目）。

可能是什麼原因造成的？

升級 MySQL 對我來說是一個長期項目，除非 5.0.67 中碰巧存在特定錯誤，否則我想我只需要重新確定優先順序。

我希望有人可能熟悉這個問題，因為這是與 Ubuntu 8.10 捆綁在一起的相當流行的版本。

謝謝

答案1

是否有一張非常大的桌子正在被傾倒，或者有一堆中等大小的桌子？您是否在 mysqldump 中使用 -q 選項？您正在轉儲正在寫入的大表嗎？如果是這樣，鎖定一個大表將阻止任何其他執行緒執行，因為所持有的鎖可能會導致您的網頁伺服器/腳本等待，直到機器缺乏資源。

您可能會用完 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

如果日誌中沒有條目，我建議您嘗試追蹤 mysqldump。

strace -f -o strace.output mysqldump your_mysqldump_options

然後看一下 strace.output 檔案的最後幾行。這通常會啟發我們的方法，並且是調試這些問題的好方法。

另一方面，像 Cacti、Ganglia 或 Munin 這樣的趨勢應用程式在解決此類問題時也很有用，因為您可以觀察有關 TCP 連線、CPU、記憶體和交換等重要指標的伺服器行為。

希望這可以幫助。

相關內容