운영 중인 MySQL 테이블이 깨졌을 때 빠르게 복구하는 방법 실제 장애 사례

리눅스 정보실

운영 중인 MySQL 테이블이 깨졌을 때 빠르게 복구하는 방법 실제 장애 사례

고지존 2025. 11. 19. 17:15

운영 환경에서 MySQL 테이블이 갑자기 깨지는 문제는 서비스 중단으로 이어질 수 있는 심각한 장애입니다. 이번 글에서는 실제로 운영하던 MySQL 환경에서 gojizone_id 테이블이 손상되며 발생한 장애를 어떻게 진단하고 복구했는지 과정 전체를 정리합니다.

로그 내용은

251119 15:30:36 [ ERROR] /usr/libexec/mysqld: Table './gojizone_db/gojizone_id' is marked as crashed and last (automatic?) repair failed 에러 관련 내용 정리

1. 장애 발생 – MySQL 로그에서 첫 에러 발견

평소처럼 서비스 로그를 점검하던 중, MySQL 에러 로그(/var/log/mysqld.log)에서 다음과 같은 메시지가 발견되었습니다.

[ERROR] /usr/libexec/mysqld: Table './gojizone_db/gojizone_id' is marked as crashed and last (automatic?) repair failed

이는 MyISAM 테이블이 손상되었고 자동 복구까지 실패했다는 의미입니다. 즉, 수동 복구가 필요한 상황이었습니다.

2. 복구 전 테이블 파일 존재 여부 확인

복구를 시작하기 전에 실제 테이블 파일(gojizone_id.MYD, gojizone_id.MYI, gojizone_id.frm)이 MySQL 데이터 디렉터리에 존재하는지 반드시 확인해야 합니다. 대부분의 CentOS·RHEL 기반 시스템에서는 기본 경로가 다음과 같습니다:

cd /var/lib/mysql/gojizone_db/
ls -al gojizone_id.*

위 명령을 통해 아래 세 파일이 모두 존재하는지 확인합니다:

gojizone_id.frm — 테이블 구조 파일
gojizone_id.MYD — 데이터 파일
gojizone_id.MYI — 인덱스 파일

파일이 정상적으로 존재하는 것을 확인한 후 테이블 상태 체크 및 복구 절차로 넘어갑니다.

3. 테이블 상태 확인

먼저 MyISAM 테이블 상태를 확인하기 위해 myisamchk 명령어를 실행했습니다.

myisamchk gojizone_id.MYI

결과는 예상대로 테이블이 crash 상태였으며, 인덱스 관련 오류가 복구를 막고 있었습니다.

4. 수동 복구 작업 진행 (MySQL 서비스 중지 필수)

myisamchk는 MySQL이 실행 중인 상태에서 사용하면 안 됩니다.
MyISAM 테이블을 직접 파일 단위로 조작하는 명령이기 때문에, MySQL 서비스가 살아있는 상태에서 실행하면 추가 손상이 발생할 수 있습니다.

4-1. MySQL 서비스 중지

service mysqld stop
# 또는
systemctl stop mysqld

서비스가 완전히 종료되었는지 확인합니다.

ps -ef | grep mysqld

여기에서 mysqld 프로세스가 보이지 않아야 안전하게 복구를 진행할 수 있습니다.

4-2. myisamchk 복구 실행

MySQL이 완전히 종료된 것을 확인한 뒤, 아래 명령어로 복구 작업을 진행합니다.

myisamchk --recover gojizone_id.MYI

복구 도중 출력되는 메시지는 다음과 같습니다.

- recovering (with sort) MyISAM-table 'gojizone_id.MYI'
- Fixing index 1
- Fixing index 2
...

테이블 복구를 위해 아래 명령어로 강력한 복구 옵션을 적용했습니다.

myisamchk --recover gojizone_id.MYI

복구 과정에서는 다음과 같은 단계가 표시되며 디스크 I/O를 크게 사용합니다.

- recovering (with sort) MyISAM-table 'gojizone_id.MYI'
- Fixing index 1
- Fixing index 2
720070312
Data records: 720070312 → 복구 이후 실제 데이터 수 다시 계산됨

CPU 사용률과 I/O가 높게 나타났으며 테이블 크기에 따라 수 분에서 수십 분까지 소요될 수 있습니다. 복구 완료 후 메시지는 아래와 같습니다.

Data records: 720070312

5. 복구 완료 후 MySQL 서비스 재시작 및 정상 접근 확인

5-1. MySQL 서비스 시작

복구가 정상적으로 끝났다면 MySQL 서비스를 다시 시작합니다.

service mysqld start
# 또는
systemctl start mysqld

5-2. 테이블 정상 작동 여부 확인

MySQL 재시작 후 테이블 SELECT 테스트를 진행합니다.

mysql -u root -p
USE gojizone_db;
SELECT COUNT(*) FROM gojizone_id;

정상적인 데이터 건수가 출력되면 복구가 성공적으로 완료된 것입니다.

복구 작업이 끝난 후 MySQL을 통해 테이블 접근 테스트를 진행했습니다.

SELECT COUNT(*) FROM gojizone_id;

데이터 조회가 정상적으로 이루어졌으며 애플리케이션에서도 오류 없이 데이터를 불러오는 것을 확인했습니다.

6. 장애 원인 및 예방 방안

이번 장애의 원인은 MyISAM 엔진의 구조적 특성(락 기반, 장애 시 인덱스 손상 가능성)에 따른 테이블 손상으로 추정됩니다.

예방 방법:

정기적인 백업 수행 (mysqldump 또는 rsync 기반 파일 백업)
MyISAM 테이블을 InnoDB로 마이그레이션 고려
서버 비정상 종료 방지
디스크 I/O 및 파일 시스템 상태 점검

gojizone_id 테이블이 손상되어 서비스 오류가 발생했으며, myisamchk 복구 작업을 통해 정상적으로 복구 완료하였습니다.

운영 환경에서 MyISAM 사용 시 테이블 손상은 언제든지 발생할 수 있으므로, 복구 절차를 숙지하고 정기 백업을 유지하는 것이 중요합니다.