MySQL 5.6 한글메뉴얼

13.7.2.5 REPAIR TABLE 구문

REPAIR [NO_WRITE_TO_BINLOG | LOCAL] TABLE
    tbl_name [, tbl_name] ...
    [QUICK] [EXTENDED] [USE_FRM]

REPAIR TABLE 은 특정 스토리지 엔진에서만 손상된 가능성이있는 테이블을 복구합니다. 기본적으로 여기에는 myisamchk --recover tbl_name 것과 같은 효과가 있습니다.

참고

REPAIR TABLE 은 MyISAM , ARCHIVE 및 CSV 의 각 테이블에만 적용됩니다. 섹션 15.2 "MyISAM 스토리지 엔진」 , 섹션 15.5 "ARCHIVE 스토리지 엔진" 과 섹션 15.4 "CSV 저장 엔진" 을 참조하십시오.

이 문은이 테이블에 대한 SELECT 및 INSERT 권한이 필요합니다.

REPAIR TABLE 은 파티션 된 테이블에 대해 지원하고 있습니다. 그러나 파티션 된 테이블에 대해이 문 USE_FRM 옵션을 사용할 수 없습니다.

MySQL 5.6.11에서만이 문을 발행하기 전에 gtid_next 를 AUTOMATIC 으로 설정해야합니다. (Bug # 16062608, Bug # 16715809, Bug # 69045)

ALTER TABLE ... REPAIR PARTITION 을 사용하면 하나 이상의 파티션을 복구 할 수 있습니다. 자세한 내용은 섹션 13.1.7 "ALTER TABLE 구문」 및 섹션 19.3.4 "파티션 관리" 를 참조하십시오.

일반적으로 REPAIR TABLE 을 수행 할 필요가 없지만, 재해가 발생한 경우에는이 문을 사용하면 MyISAM 테이블에서 모든 데이터를 복원 할 수 있습니다. 테이블이 자주 파손되는 경우는 그 원인을 찾을하여 REPAIR TABLE 을 사용할 필요가 없어지게하십시오. 섹션 B.5.4.2 "MySQL이 계속 충돌하는 경우의 대처 방법" 및 섹션 15.2.4 "MyISAM 테이블 문제" 를 참조하십시오.

주의

테이블의 복구 작업을 수행하기 전에 테이블을 백업하십시오. 상황에 따라이 작업을 위해 데이터 손실이 발생할 수 있습니다. 가능한 원인으로는 파일 시스템의 오류 등이 있지만 이에 국한되지 않습니다. 제 7 장 "백업 및 복구" 를 참조하십시오.

경고

REPAIR TABLE 조작 중에 서버가 충돌 한 경우 서버를 다시 시작한 후 그 테이블에서 다른 작업을 수행하기 전에 다시 REPAIR TABLE 문을 즉시 실행하는 것이 중요합니다. 최악의 경우 데이터 파일에 대한 정보가없는 새로운 깨끗한 인덱스 파일이 생성되고 실행하는 다음의 조작에 의해 데이터 파일을 덮어 쓸 수 있습니다. 이 상황은 거의 발생하지 않지만, 처음 백업 할 가치를 강조하고있다, 가능성있는 시나리오입니다.

REPAIR TABLE 은 다음 컬럼을 포함하는 결과 집합을 반환합니다.

컬럼	값
`Table`	테이블 이름
`Op`	항상 `repair`
`Msg_type`	`status` , `error` , `info` , `note` 또는 `warning`
`Msg_text`	정보 메시지

REPAIR TABLE 문에 의해 복구 된 테이블마다 다수의 정보 행이 생성 될 가능성이 있습니다. 마지막 줄에는 status 의 Msg_type 값이 포함되어 Msg_test 는 일반적 OK 입니다. MyISAM 테이블에 OK 가 표시되지 않는 경우, myisamchk --safe-recover를 사용하여 복구 해보십시오. ( REPAIR TABLE 하여 myisamchk의 모든 옵션이 구현되는 것은 아닙니다.) myisamchk --safe-recover은 REPAIR TABLE 이 지원하지 않는 옵션 ( --max-record-length 등)도 사용할 수 있습니다.

QUICK 옵션을 사용하면 REPAIR TABLE 은 데이터 파일이 아닌 인덱스 파일 만 복구하려고합니다. 이 유형의 복구는 myisamchk --recover --quick에 의해 실행되는 복구와 비슷합니다.

EXTENDED 옵션을 사용하면 MySQL은 정렬하면서 한 번에 하나의 인덱스를 작성하는 대신 행당 인덱스를 만듭니다. 이 유형의 복구는 myisamchk --safe-recover 의해 실행되는 복구와 비슷합니다.

USE_FRM 옵션은 .MYI 인덱스 파일이 없거나 헤더가 손상된 경우에 사용할 수 있습니다. 이 옵션은 MySQL에 .MYI 파일 헤더의 정보를 신뢰하지 않고 .frm 파일의 정보를 사용하여 파일 헤더를 다시 작성하도록 지시합니다. 이 종류의 복구는 myisamchk에서는 실행되지 않습니다.

참고

보통의 REPAIR 모드를 사용할 수없는 경우 USE_FRM 옵션 만 사용합니다. 서버에 .MYI 파일을 무시하도록 지시하면 .MYI 에 저장되어있는 중요한 테이블 메타 데이터를 복구 프로세스에서 사용할 수 없게되기 때문에 유해한 결과를 초래할 수 있습니다.

현재 AUTO_INCREMENT 값은 손실됩니다.
테이블에서 삭제 된 레코드에 대한 링크는 손실됩니다. 즉, 삭제 된 레코드의 공간은 그 이후에도 점유되지 않고 남아 있습니다.
.MYI 헤더 테이블이 압축되어 있는지 여부를 나타냅니다. 서버가이 정보를 무시하면 테이블이 압축되어 있는지를 모르기 때문에 복구에 의해 테이블의 내용의 변경 또는 손실이 발생할 수 있습니다. 즉, 압축 테이블에서 USE_FRM 을 사용하지 않도록하십시오. 어쨌든, 이것은 필수가 아닙니다. 압축 테이블은 읽기 전용이기 때문에 손상 될 수는 없습니다.

주의

현재 실행중인 것과 다른 버전의 MySQL 서버에 의해 생성 된 테이블에 대해 USE_FRM 을 사용하는 경우 REPAIR TABLE 은 테이블을 복구하려고하지 않습니다. 이 경우 REPAIR TABLE 에 의해 반환 된 결과 집합에는 Msg_type 값이 error 에서 Msg_text 값이 Failed repairing incompatible .FRM file 인 행이 포함되어 있습니다.

USE_FRM 을 사용하지 않는 경우 REPAIR TABLE 은 테이블을 확인하여 업그레이드가 필요한지 여부를 확인합니다. 업그레이드가 필요한 경우 CHECK TABLE ... FOR UPGRADE 과 같은 규칙에 따라 업그레이드를 실행합니다. 자세한 내용은 섹션 13.7.2.2 "CHECK TABLE 구문" 을 참조하십시오. USE_FRM 없는 REPAIR TABLE 은 .frm 파일을 현재 버전으로 업그레이드합니다.

기본적으로 서버는 REPAIR TABLE 문을 바이너리 로그에 기록하고 또 리플리케이션 슬레이브에 복제되도록합니다. 로깅을하지 않으려면 옵션의 NO_WRITE_TO_BINLOG 키워드 또는 별칭 LOCAL 을 지정합니다.

중요

마스터 테이블이 손상 될 수 있으며 테이블에 REPAIR TABLE 을 실행하면 그 결과로 원래 테이블의 변경 사항은 슬레이브에 전달되지 않습니다.

특정 시스템 변수를 설정하여 REPAIR TABLE 의 성능을 향상시킬 수있는 가능성이 있습니다. 섹션 8.6.3 "REPAIR TABLE 문 속도" 를 참조하십시오.

REPAIR TABLE 테이블은 오래된 손상된 파일에서 새로 생성 된 파일에 테이블 통계 복사 중에 발생한 모든 오류를 포착하여 발생합니다. 예를 들어, .frm , .MYD 또는 .MYI 파일 소유자의 사용자 ID가 mysqld 프로세스의 사용자 ID와 다를 경우, mysqld가 root 사용자에 의해 실행되고 있지 않은 한, REPAIR TABLE 은 "can not change ownership of the file "오류를 생성합니다.