MySQL 5.0.67 설치가 갑자기 중단되는 원인은 무엇입니까?

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 옵션을 사용하고 있습니까? 쓰고 있는 큰 테이블이 있습니까? 그렇다면 큰 테이블을 잠그면 잠금으로 인해 다른 스레드가 실행되는 것을 방지할 수 있으며 이로 인해 시스템에 리소스가 부족할 때까지 웹 서버/스크립트가 대기하게 될 수 있습니다.

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, 메모리 및 스왑과 같은 중요한 지표와 관련된 서버 동작을 관찰할 수 있으므로 이러한 종류의 문제에도 유용합니다.

도움이 되었기를 바랍니다.

관련 정보