14.16.1 InnoDB 복구 프로세스
InnoDB
의 충돌 복구 는 다음의 몇 가지 단계로 구성됩니다.
Redo 로그 의 적용 : Redo 로그의 적용은 첫 번째 단계이며 초기화 중 아직 어떤 연결도 허용하지 않을 때 실행됩니다. 종료 또는 중단 시점에서 버퍼 풀 에서 테이블 스페이스 (
ibdata*
그리고*.ibd
파일)에 모든 변경이 플래시 된 경우, Redo 로그의 적용을 생략 할 수 있습니다. 시작시 Redo 로그 파일이 없으면InnoDB
는 Redo 로그의 적용을 생략합니다.일부 데이터 손실이 허용되는 경우에도 복구 프로세스를 가속화하기 위해 Redo 로그를 삭제하는 것은 권장되지 않습니다. Redo 로그 삭제는
innodb_fast_shutdown
가0
또는1
로 설정된 상태에서 완전 종료가 실행 된 후 옵션에 지나지 않는다고 생각합니다.완료되지 않은 트랜잭션 의 롤백 : 충돌 또는 빠른 종료 시점에서 활성화되었던 모든 트랜잭션이 대상입니다. 완료되지 않은 트랜잭션을 롤백하는 데 걸리는 시간은 서버의 부하에 따라 해당 트랜잭션이 중단되기 전에 활성화되었던 기간의 3 또는 4 배가 될 수 있습니다.
롤백되는 동안 트랜잭션을 취소 할 수 없습니다. 극단적 인 경우로 트랜잭션 롤백에 상당한 시간이 걸릴 것으로 예측되는 경우는
innodb_force_recovery
설정을3
이상으로InnoDB
를 시작하는 것이 빠른 수 있습니다. 자세한 내용은 섹션 14.19.2 "InnoDB 복구 강제 실행" 을 참조하십시오.삽입 버퍼 병합 : 인덱스 페이지가 버퍼 풀 읽을 때 삽입 버퍼 ( 시스템 테이블 공간 의 일부)에서 보조 인덱스의 리프 페이지에 변경 사항을 적용합니다.
정화 : 어떤 활성 트랜잭션에 표시되지 않는 삭제 표시된 레코드를 삭제합니다.
Redo 로그의 적용에 따르는 각 단계는 (쓰기 로깅을 제외) Redo 로그에 의존하지 않기 때문에 정상적인 처리가 병렬로 실행됩니다. 이들 중 충돌 복구에 관련된 것은 완료되지 않은 트랜잭션 롤백뿐입니다. 삽입 버퍼 병합 및 삭제는 정상 처리 중에 수행됩니다.
Redo 로그 적용 후, InnoDB
는 다운 타임을 단축하기 위해 연결을 빨리 받아들이려고합니다. 충돌 복구의 일부로 InnoDB
는 서버 충돌시 커밋되지 않았거나 XA PREPARE
상태에 있던 모든 트랜잭션을 롤백합니다. 이 롤백은 새 연결에서 트랜잭션와 병렬로 실행되는 백그라운드 스레드에서 실행됩니다. 새 연결에서 롤백 작업이 완료 될 때까지 복구되는 트랜잭션과 잠금 충돌이 발생할 수 있습니다.
대부분의 상황에서는 부하가 높은 활동 중에 MySQL 서버가 예기치 않게 종료 된 경우에도 복구 프로세스가 자동으로 실행되므로 DBA의 작업이 필요하지 않습니다. 하드웨어 장애 나 심각한 시스템 오류로 인해 InnoDB
데이터가 손상된 경우 MySQL이 시작을 거부 할 수 있습니다. 그 경우는 이러한 문제를 해결하는 방법에 대한 섹션 14.19.2 "InnoDB 복구 강제 실행" 을 참조하십시오.
바이너리 로그와 InnoDB
의 충돌 복구 내용은 섹션 5.2.4 "바이너리 로그" 를 참조하십시오.