MySQL 매개 변수에 대한 간단한 설명 delaykey_write、myisam_recover_options 사용 경험

최근 데이터베이스 인스턴스 마이그레이션을 수행하면서 다음과 같은 몇 가지 이상한 문제가 발생했습니다.

MyISAM 실례가 정상적인 shutdown 후 rsync 데이터 파일을 다른 기계에 실례한 후, 테이블에 접근할 때 알림표가 자동으로 복구되지 않으면 Repair table가 필요합니다.팁 정보: Table'./test/record_03' is marked as crashed and last (automatic?) repair failed

시계가 파손된 후 리페어 테이블 명령을 이용하여 시계를 복구할 때 시계에 많은duplicate 키가 존재한다는 것을 알립니다.

     warning  : Duplicate key for record at 129584986 against record at 62008769
     warning  : Duplicate key for record at 104678355 against record at 61426294
     warning  : Duplicate key for record at 297493788 against record at 61697778
     warning  : Duplicate key for record at 209950328 against record at 61548867
     warning  : Duplicate key for record at 105894968 against record at 61866949
...
...
그 당시의 환경 정보를 보충해 보자.
1. MySQL 버전은 공식 버전 5.5.12, 테이블 엔진은 MyISAM
2. 이전 절차:stop slave->flush tables->정상 shutdown 실례->rsync표 파일->새 기계에서 실례.rsync 앞뒤 테이블 파일 MD5 값은 같습니다.
3. 표의 구조는 다음과 같다.

create table test (
id int auto_increment primary key,
a varchar(100) not null,
b int not null,
c int,
unique key (a,b)
)

먼저 첫 번째 문제를 말하자면, 여기는 두 가지로 나뉜다.왜 복구가 필요합니까?2. 자동 복구 실패 이유

저는 정상적으로 닫힌 실례입니다. 시계를 복원해야 하는 이유를 모르겠습니다. 그래서 타오바오딩치에게 데이터 파일을 분석해 달라고 부탁했습니다. 파일 헤더에 시계가 닫혔는데도 6개의 라인이 방문하고 있음을 기록했습니다.그러나 나는 당시 rsync 데이터 파일 앞에 정상적인 shutdown 실례가 있었다는 것을 확신할 수 있다. 이것은 MyISAM 자체의 문제일 수도 있고 그 자체의 데이터 파일에 문제가 존재했는지 알 수 없다. 한마디로 내가 이전한 후에 방문표를 복원해야 한다는 점은 합리적이다. 왜냐하면 시계가 닫혔을 때 라인이 방문하고 있기 때문에 이것은 MySQL에 의해 시계가 정상적으로 닫히지 않았다고 여겨진다.복구가 필요합니다.

왜 자동으로 복구가 실패했는지, 이것은 내가 파라미터 myisam 을 설정했기 때문입니다.recover_옵션s=default, 이 설정은 MyISAM 테이블에 접근할 때마다 복구가 필요한지 확인하고 필요하면 자동으로 진행합니다. 이것은 바로 앞에 보이는 정보last (automatic?) 입니다.repair failed.복구 실패는 이 매개 변수가 가져온 복구 행위는 기본적으로 키 캐치에서 복구해야 할 데이터를 찾았기 때문입니다. 저는 shutdown 실례였고 rsync가 새로운 환경에서부터 실례를 찾았습니다. 이때는 당시의 현장(key cache 환경)이 없습니다.더욱이default는 강제 복구를 하지 않습니다. (강제 복구표는 색인 파일과 데이터 파일의 데이터가 일치하지 않으면 자동으로 삭제하거나 줄을 추가합니다.)(myisam recover options=force라면 키 캐치가 존재하지 않아도 강제 복구를 할 수 있습니다. 이때 데이터 파일과 인덱스 파일을 비교한 다음 데이터 파일의 여분의 줄을 삭제하면 데이터를 잃어버릴 수 있습니다.자동 복구 시 error log에서 다음과 같은 정보를 볼 수 있습니다:

130410  9:31:23 [ERROR]/usr/local/mysql55/bin/mysqld: Table './image_0/record_00' is marked as crashed and should be repaired
130410  9:31:23 [Warning] Checking table:   './image_0/record_00'
130410  9:31:24 [ERROR] Got an error from unknown thread,/export/home/pb2/build/sb_0-3198286-1302530066.93/mysql-
5.5.12/storage/myisam/ha_myisam.cc:868
130410  9:31:24 [Warning] Recovering table: './image_0/record_00'
130410  9:31:28 [Note] Retrying repair of: './image_0/record_00' with keycache
130410  9:31:37 [ERROR] Couldn't repair table: image_0.record_00
이어서 두 번째 문제, 첫 번째 문제에서 제시표가 파손되면 수동으로 Repair table이 필요합니다. 제가 이 명령을 실행한 후에 제시표에 중복 키 데이터가 많이 존재합니다.
warning  : Duplicate key for record at 129584986 against record at 62008769
warning  : Duplicate key for record at 104678355 against record at 61426294
warning  : Duplicate key for record at 297493788 against record at 61697778
warning  : Duplicate key for record at 209950328 against record at 61548867
warning  : Duplicate key for record at 105894968 against record at 61866949
이 중복 키는 유일한 키(a, b)를 가리키며 데이터 파일에 중복된 줄이 있다는 작은 테스트 검증을 실시했다.논리적 그림은 대략 이렇다

id a b c
1  1 2 3
2  1 2 4
3  2 3 55
4  2 3 54

위의 이 목록은 내가 시뮬레이션한 것으로 (a, b)에 유일한 키 제약이 있지만 데이터 파일에 (a, b) 중복된 줄이 존재한다.간편한 검증 방법:
/* 전체 테이블 스캔 강제 */select* from test where a=val1 and b=val2;
결과 집합이 두 줄이에요.
/* 색인 강제 실행 */select * from test where a=val1 and b=val2;
결과 집합이 한 줄밖에 없어요.
당시 문제에 부딪혔을 때 첫 번째 반응은 개발자 쪽에서 데이터를 도출하고 도출할 때 유일한 제약 검사를 금지한 것이 아니냐는 것이었다. 그러나 사실상 개발은 자신이 이렇게 한 적이 없다고 해서 MySQL의 버그라고 개발했다. 나는 아무리 생각해도 MySQL에 이렇게 큰 버그가 존재하지 않을 것 같아서 MySQL에 대한 사용 방법이 옳지 않다고 생각했다.그래서 이전 전후의 환경을 비교 검사한 결과 드디어 의문점을 발견했다. 오래된 환경에 delay 를 배치했다.key_write=ALL,myisam_recover_options=OFF(기본값은 OFF)나의 새로운 환경은 delaykey_write=ON,myisam_recover_options=default .
간단한 설명 delaykey_write, MyISAM 테이블 인덱스를 업데이트할 때마다 flush를 물리 디스크에 업데이트하지 않습니다. 이 수정은 메모리에 남아 있으며, 이 테이블이 닫힐 때까지flush를 사용합니다. ALLL은 모든 테이블에 이 행동을 사용합니다. ON은 테이블을 만들 때 delay 를 사용합니다.key_write의 시계는 이 기능을 사용합니다.OFF는 delay key write를 실행하지 않음을 나타냅니다.공식적으로는 delaykey_write 시 myisamrecover_옵션스는 이렇게 해야만 데이터의 일치성을 확보할 수 있다. 그렇지 않으면 가장 간단한 예를 들어 인덱스 데이터가 일치하지 않아서 디스크에 flush가 없다. 갑자기 테이블이 정상적으로 닫히고 다음 테이블이 방문되면 해당하는 검사 복구를 하지 않으면 데이터 파일과 인덱스가 일치하지 않는 상황이 발생하고 데이터가 일치하지 않게 된다.
다시 한 번 간단히 설명해 주세요myisamrecover_options,default는 매번 방문표에 접근할 때마다 복구가 필요한지 판단하지만 강제 복구를 시도하지 않습니다(키 캐치에서만 복구를 시도함). 백업은 복구를 시도할 때 오래된 데이터 파일을 먼저 백업하고 force는 강제 복구를 표시합니다. 구체적인 사용법은 아래 그림을 보십시오.
이때 MySQL 매개 변수의 불합리한 사용으로 인한 데이터 불일치 문제가 대체적으로 확인되므로 MyISAM을 사용할 때 delay 를 설정하면key_write, myisam을 동시에 설정하는 것을 잊지 마세요recover_options는 이렇게 해야만 데이터의 불일치성을 방지할 수 있다.그렇다면 나는 어떻게 이 문제를 해결했을까?현재로서는 마이그레이션 후의 MySQL 구성 매개 변수 환경을 통해 이전 환경과 일치하도록 유지해야 합니다. 그렇지 않으면 제가 지금 매개 변수 myisam을 강제로 추가하면recover_options, 그러면 모든 시계가 손상되고 손상된 후에 복구되는 유일한 방법은 리페어 테이블입니다. 데이터를 잃어버리거나 (myisam recover options=force,backup을 설정합니다. 이 효과는 리페어 테이블과 같고 수정할 MYD 파일을 백업하는 것입니다). 중복 키의 줄에 대해 리페어 테이블을 이용하면나는 MySQL이 남긴 구체적인 줄에 관여할 수 없기 때문에 리페어 테이블을 강행하면 중복 키 오류를 해결할 수 있지만 최종적으로 남긴 줄이 반드시 사용자가 원하는 줄 데이터가 아니다.물론 두 가지 방법이 있다. 첫째, 업무 담당자에게 문의한 후 중복 키에서 필요하지 않은 줄을 수동으로 삭제하는 것이다.둘째, 리페어 테이블을 강제로 하고 오래된 데이터를 백업한 다음에 사용자 측에서 이상을 발견하면 다시 데이터 복구를 한다. 그러나 이 방법은 바람직하지 않다. 그렇지 않으면 사용자 고소로 죽을 것이다.
한 마디로 하면 21세기인데 5.6이 되었으니 MyISAM을 쓰지 마세요. 저는 역사 시스템이기 때문에 어쩔 수 없어요. 후기에 업그레이드하고 개조하는 것도 반드시 해야 해요.