9.6.1 Using myisamchk for Crash Recovery

9.6.1 Using myisamchk for Crash Recovery

이 절에서는 MySQL 데이터베이스에서 데이터 손상을 점검하고 처리하는 방법을 설명합니다. 테이블이 자주 손상된다면, 그 원인을 찾아보아야 합니다. Section B.3.3.3, “What to Do If MySQL Keeps Crashing”를 참조하십시오.

MyISAM 테이블이 어떻게 손상될 수 있는지에 대한 설명은 Section 18.2.4, “MyISAM Table Problems”를 참조하십시오.

외부 로킹이 비활성화된 상태(기본값)로 mysqld를 실행하는 경우, mysqld가 동일한 테이블을 사용 중일 때는 myisamchk를 사용하여 테이블을 신뢰성 있게 검사할 수 없습니다. myisamchk를 실행하는 동안 아무도 mysqld를 통해 해당 테이블에 접근하지 않는다는 것을 확실히 보장할 수 있다면, 테이블 검사를 시작하기 전에 mysqladmin flush-tables만 실행하면 됩니다. 이를 보장할 수 없다면, 테이블을 검사하는 동안 mysqld를 중지해야 합니다. mysqld가 동시에 갱신하고 있는 테이블에 대해 myisamchk를 실행하면, 실제로는 손상되지 않았더라도 테이블이 손상되었다는 경고를 받게 될 수 있습니다.

서버가 외부 로킹 활성화 상태로 실행되는 경우에는 언제든지 myisamchk를 사용하여 테이블을 검사할 수 있습니다. 이 경우, 서버가 myisamchk가 사용 중인 테이블을 갱신하려고 하면, 서버는 myisamchk가 끝날 때까지 기다렸다가 계속 진행합니다.

myisamchk를 사용하여 테이블을 리페어하거나 최적화하는 경우, (외부 로킹이 비활성화된 경우에도 마찬가지로) mysqld 서버가 해당 테이블을 사용하고 있지 않도록 항상 반드시 보장해야 합니다. mysqld를 중지하지 않는 경우, 적어도 myisamchk를 실행하기 전에 mysqladmin flush-tables를 수행해야 합니다. 서버와 myisamchk가 동시에 테이블에 접근하면, 테이블이 손상될 수 있습니다.

크래시 복구를 수행할 때는, 데이터베이스 내의 각 MyISAM 테이블 _tbl_name_이 데이터베이스 디렉터리 안의 다음 표에 나오는 세 개의 파일에 각각 대응한다는 점을 이해하는 것이 중요합니다.

File	Purpose
tbl_name.MYD	Data file
tbl_name.MYI	Index file

이 세 가지 파일 형식 각각은 여러 방식으로 손상될 수 있지만, 문제는 대부분 데이터 파일과 인덱스 파일에서 가장 자주 발생합니다.

myisamchk는 .MYD 데이터 파일을 로우 단위로 복사본을 생성하는 방식으로 동작합니다. 리페어 단계의 마지막에는, 이전 .MYD 파일을 삭제하고 새 파일의 이름을 원래 파일 이름으로 변경합니다. --quick를 사용하면, myisamchk는 임시 .MYD 파일을 생성하지 않고, 대신 .MYD 파일이 올바르다고 가정하고 .MYD 파일에는 손대지 않은 채 새 인덱스 파일만 생성합니다. 이는 안전한데, 그 이유는 myisamchk가 .MYD 파일이 손상되었는지를 자동으로 감지하고, 손상된 경우 리페어를 중단하기 때문입니다.

또한 --quick 옵션을 myisamchk에 두 번 지정할 수도 있습니다. 이 경우, myisamchk는 (중복 키 에러와 같은) 일부 에러에서 중단하지 않고, 대신 .MYD 파일을 수정하여 에러를 해결하려고 시도합니다.

일반적으로 --quick 옵션을 두 번 사용하는 것은 정상적인 리페어를 수행할 수 있을 만큼의 자유 디스크 공간이 부족한 경우에만 유용합니다. 이 경우, myisamchk를 실행하기 전에 적어도 해당 테이블의 백업을 만들어 두어야 합니다.