☰

MySQL 5.0.67 インストールが突然クラッシュする原因は何でしょうか?

tag-icon • tag-icon mysql
MySQL 5.0.67 インストールが突然クラッシュする原因は何でしょうか?

私は MySQL 5.0.67 を搭載した古い Ubuntu 8.10 32 ビットを持っています。

そこには 5.7GB のデータがあり、毎日約 100MB ずつ増加しています。

約 3 日前、夜間の mysqldump 中に MySQL インスタンスが突然静かに (ログ エントリなしで) 停止し始めました。

何が原因なのでしょうか?

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

ログにエントリがない場合は、mysqldump の strace を試すことをお勧めします。

strace -f -o strace.output mysqldump your_mysqldump_options

次に、strace.output ファイルの最後の数行を見てください。通常、これによって道筋が明らかになり、これらの問題のデバッグを開始するのに適した方法になります。

一方、Cacti、Ganglia、Munin などのトレンドのアプリケーションも、TCP 接続、CPU、メモリ、スワップなどの重要なメトリックに関するサーバーの動作を監視できるため、この種の問題に役立ちます。

お役に立てれば。

関連情報