"/g5_visit' is marked as crashed and last (automatic?) repair failed" 에러 조치 > 에필로그

그누보드 기반 쇼핑몰이었다.

g5_visit라는 테이블이 깨진거다.

깨진 테이블은 이뿐만이 아니었다.

복구에 myisamchk 툴을 쓰기로 했다.

먼저 데이터베이스 데이터 경로를 확인하고 다음을 실행했다.

myisamchk -r /home/mysql/xxxxx/*.MYI

백업 파일로 간단히 복구할까 했는데 어쩐지 백업 파일들의 크기가 생각보다 작았다.

테이블들에 이상이 생기면서 한동안 백업이 온전하게 되지 않았던 모양이다.

이런 백업 파일로 복구를 진행했다가는 돌이킬 수없는 사고가 날 수 있다.

원인은 시스템의 inode 소진이었다.

어떤 서비스의 로그 파일들이 inode를 다 차지했었다.

inode가 없으니 SQL이 뭘 쓰다쓰다 못 쓰고만 에러가 테이블을 손상시켰다.

inode의 소진시 쌓여있는 미실행 프로세스들을 주의해야 한다.

예를 들어 주기적인 백업과 백업본 삭제가 크론에 등록돼 있으면 경우에 따라 백업을 다 날리는 수가 있다.

inode를 소진하는 서비스의 로그 파일은 주기적으로 삭제되도록 logrotate에 등록했다.