데브러너 (DevRunner)

9.6.3 How to Repair MyISAM Tables

이 절에서는 MyISAM 테이블(확장자 .MYI 및 .MYD)에서 myisamchk를 사용하는 방법을 설명합니다.

또한 CHECK TABLE 및 REPAIR TABLE 구문을 사용하여 MyISAM 테이블을 검사하고 복구할 수도 있습니다. Section 15.7.3.2, “CHECK TABLE Statement” 및 Section 15.7.3.5, “REPAIR TABLE Statement”를 참조하십시오.

손상된 테이블의 증상에는 예기치 않게 중단되는 쿼리와 다음과 같은 관찰 가능한 오류가 포함됩니다:

Can't find file tbl_name.MYI (Errcode: nnn)
Unexpected end of file
Record file is crashed
Got error nnn from table handler

오류에 대한 더 많은 정보를 얻으려면 _nnn_이 오류 번호일 때 perror _nnn_을 실행하십시오. 다음 예제는 테이블에 문제가 있음을 나타내는 가장 일반적인 오류 번호의 의미를 찾기 위해 perror를 사용하는 방법을 보여 줍니다:

1$> perror 126 127 132 134 135 136 141 144 145
2MySQL error code 126 = Index file is crashed
3MySQL error code 127 = Record-file is crashed
4MySQL error code 132 = Old database file
5MySQL error code 134 = Record was already deleted (or record file crashed)
6MySQL error code 135 = No more room in record file
7MySQL error code 136 = No more room in index file
8MySQL error code 141 = Duplicate unique key or constraint on write or update
9MySQL error code 144 = Table is crashed and last repair failed
10MySQL error code 145 = Table was marked as crashed and should be repaired

오류 135(no more room in record file)와 오류 136(no more room in index file)은 간단한 복구로 고칠 수 있는 오류가 아님에 유의하십시오. 이 경우에는 ALTER TABLE을 사용하여 MAX_ROWS 및 AVG_ROW_LENGTH 테이블 옵션 값을 증가시켜야 합니다:

1ALTER TABLE tbl_name MAX_ROWS=xxx AVG_ROW_LENGTH=yyy;

현재 테이블 옵션 값을 모르는 경우에는 SHOW CREATE TABLE을 사용하십시오.

나머지 오류의 경우에는 테이블을 복구해야 합니다. myisamchk는 일반적으로 발생하는 대부분의 문제를 감지하고 수정할 수 있습니다.

복구 과정은 여기에서 설명하는 최대 세 단계로 구성됩니다. 시작하기 전에 데이터베이스 디렉터리로 위치를 변경하고 테이블 파일의 권한을 확인해야 합니다. Unix에서는 mysqld가 실행되는 사용자(및 파일에 접근해야 하는 당신)에게 파일이 읽기 가능하도록 되어 있는지 확인하십시오. 파일을 수정해야 하는 것으로 판명되면, 해당 파일은 당신에게 쓰기 가능해야 합니다.

이 절은 테이블 검사에 실패하는 경우(예: Section 9.6.2, “How to Check MyISAM Tables for Errors”에 설명된 경우)나 myisamchk가 제공하는 확장 기능을 사용하려는 경우를 대상으로 합니다.

테이블 유지 관리에 사용되는 myisamchk 옵션은 Section 6.6.4, “myisamchk — MyISAM Table-Maintenance Utility”에 설명되어 있습니다. 또한 myisamchk에는 메모리 할당을 제어하여 성능을 향상시킬 수 있는 변수가 있습니다. Section 6.6.4.6, “myisamchk Memory Usage”를 참조하십시오.

커맨드라인에서 테이블을 복구하려면 먼저 mysqld 서버를 중지해야 합니다. 원격 서버에서 mysqladmin shutdown을 수행할 때, 모든 구문 처리 중지가 완료되고 모든 인덱스 변경 사항이 디스크에 플러시될 때까지는 mysqladmin이 반환된 후에도 mysqld 서버가 여전히 사용 가능하다는 점에 유의하십시오.

Stage 1: Checking your tables

myisamchk *.MYI 또는 시간이 더 있다면 myisamchk -e *.MYI를 실행하십시오. 불필요한 정보를 억제하려면 -s(silent) 옵션을 사용하십시오.

mysqld 서버가 중지된 경우에는 --update-state 옵션을 사용하여 myisamchk에게 테이블이 “checked”로 표시되도록 해야 합니다.

myisamchk가 오류를 보고하는 테이블만 복구하면 됩니다. 이러한 테이블에 대해서는 Stage 2로 진행하십시오.

검사 중에 out of memory 오류와 같은 예기치 않은 오류가 발생하거나 myisamchk가 크래시되면 Stage 3으로 이동하십시오.

Stage 2: Easy safe repair

먼저 myisamchk -r -q tbl_name를 시도하십시오 (-r -q는 “빠른 복구 모드(quick recovery mode)”를 의미합니다). 이는 데이터 파일에는 손대지 않고 인덱스 파일을 복구하려고 시도합니다. 데이터 파일에 있어야 할 모든 것이 포함되어 있고 삭제 링크가 데이터 파일 내의 올바른 위치를 가리키는 경우에는 이 방법이 성공하며, 테이블이 수정됩니다. 다음 테이블 복구를 시작하십시오. 그렇지 않은 경우 다음 절차를 사용하십시오:

계속 진행하기 전에 데이터 파일의 백업을 만드십시오.
myisamchk -r tbl_name (-r은 “복구 모드(recovery mode)”를 의미합니다)를 사용하십시오. 이는 잘못된 레코드와 삭제된 레코드를 데이터 파일에서 제거하고 인덱스 파일을 재구성합니다.
앞 단계가 실패하면 myisamchk --safe-recover tbl_name를 사용하십시오. 안전 복구 모드(safe recovery mode)는 일반 복구 모드에서 처리하지 못하는 몇 가지 경우를 처리하는 오래된 복구 방법을 사용합니다 (그러나 더 느립니다).

참고

복구 작업을 훨씬 더 빠르게 수행하려면 myisamchk를 실행할 때 sort_buffer_size 및 key_buffer_size 변수 값을 각각 사용 가능한 메모리의 약 25%로 설정해야 합니다.

복구 중에 out of memory 오류와 같은 예기치 않은 오류가 발생하거나 myisamchk가 크래시되면 Stage 3으로 이동하십시오.

Stage 3: Difficult repair

이 단계에 도달하는 경우는 인덱스 파일의 첫 16KB 블록이 손상되었거나 잘못된 정보를 포함하고 있거나, 인덱스 파일이 없는 경우에 한해야 합니다. 이 경우에는 새 인덱스 파일을 생성해야 합니다. 다음과 같이 하십시오:

데이터 파일을 안전한 위치로 이동합니다.
테이블 정의 파일을 사용하여 새로운(빈) 데이터 및 인덱스 파일을 생성합니다:

1$> mysql db_name

1mysql> SET autocommit=1;
2mysql> TRUNCATE TABLE tbl_name;
3mysql> quit

기존 데이터 파일을 새로 생성한 데이터 파일에 다시 복사합니다. (예전 파일을 새 파일 위로 그냥 이동시키지는 마십시오. 문제가 발생할 경우를 대비해 복사본을 보존해야 합니다.)

주의

레플리케이션을 사용 중인 경우에는 위 절차를 수행하기 전에 반드시 레플리케이션을 중지해야 합니다. 이 절차에는 파일 시스템 작업이 포함되며, 이러한 작업은 MySQL에 의해 로그되지 않기 때문입니다.

Stage 2로 돌아가십시오. myisamchk -r -q가 동작해야 합니다. (이는 끝없는 반복이 아닙니다.)

또한 전체 절차를 자동으로 수행하는 REPAIR TABLE tbl_name USE_FRM SQL 구문을 사용할 수도 있습니다. REPAIR TABLE를 사용할 때에는 서버가 모든 작업을 수행하므로, 유틸리티와 서버 간의 원치 않는 상호 작용이 발생할 가능성도 없습니다. Section 15.7.3.5, “REPAIR TABLE Statement”를 참조하십시오.