Loading...
MySQL 9.5 Reference Manual 9.5의 17.18.2 InnoDB Recovery의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
이 절에서는 InnoDB 복구에 대해 설명합니다. 포함되는 주제는 다음과 같습니다:
물리적 백업이 생성된 시점부터 현재까지 InnoDB 데이터베이스를 복구하려면, 백업을 수행하기 전이라도 MySQL 서버를 바이너리 로깅이 활성화된 상태로 실행해야 합니다. 백업을 복원한 후 point-in-time 복구를 수행하려면, 백업 이후에 발생한 변경 사항을 바이너리 로그에서 적용하면 됩니다. 자세한 내용은 Section 9.5, “Point-in-Time (Incremental) Recovery”를 참조하십시오.
데이터베이스가 손상되었거나 디스크 장애가 발생한 경우, 백업을 사용하여 복구를 수행해야 합니다. 손상이 발생한 경우, 먼저 손상되지 않은 백업을 찾습니다. 기본 백업을 복원한 후, 바이너리 로그 파일에서 mysqlbinlog와 mysql을 사용하여 백업 이후에 발생한 변경 사항을 복원하여 point-in-time 복구를 수행합니다.
일부 데이터베이스 손상 사례에서는 하나 또는 소수의 손상된 테이블을 덤프, 드롭, 재생성하는 것으로 충분할 수 있습니다. CHECK TABLE 문을 사용하여 테이블이 손상되었는지 확인할 수 있지만, CHECK TABLE로 모든 가능한 유형의 손상을 감지할 수는 없습니다.
일부 경우, 겉보기에 데이터베이스 페이지 손상처럼 보이는 문제가 실제로는 운영 체제가 자체 파일 캐시를 손상시킨 것이고, 디스크의 데이터는 정상일 수 있습니다. 우선 컴퓨터를 재시작해 보는 것이 가장 좋습니다. 이렇게 하면 데이터베이스 페이지 손상처럼 보이던 오류가 제거될 수 있습니다. InnoDB 일관성 문제로 인해 MySQL이 여전히 시작에 어려움을 겪는다면, 인스턴스를 복구 모드로 시작하여 데이터를 덤프할 수 있는 절차는 Section 17.20.3, “Forcing InnoDB Recovery”를 참조하십시오.
예기치 않은 MySQL 서버 종료로부터 복구하려면 MySQL 서버를 다시 시작하는 것만 필요합니다. InnoDB는 자동으로 로그를 확인하고 데이터베이스를 현재 시점까지 롤포워드합니다. InnoDB는 크래시 시점에 존재하던 커밋되지 않은 트랜잭션을 자동으로 롤백합니다.
InnoDB 크래시 복구는 여러 단계로 구성됩니다:
Tablespace discovery는 복구 중 redo 로그 적용이 필요한 테이블스페이스를 식별하기 위해 InnoDB가 사용하는 프로세스입니다. 자세한 내용은 Tablespace Discovery During Crash Recovery를 참조하십시오.
Redo 로그 적용은 커넥션을 허용하기 전에 초기화 중에 수행됩니다. 셧다운 또는 크래시 시점에 버퍼 풀의 모든 변경 사항이 테이블스페이스 (ibdata* 및 *.ibd 파일)로 플러시되었다면, redo 로그 적용은 생략됩니다. 또한 시작 시 redo 로그 파일이 없는 경우에도 InnoDB는 redo 로그 적용을 생략합니다.
현재 최대 auto-increment 카운터 값은 값이 변경될 때마다 redo 로그에 기록되므로 크래시 세이프합니다. 복구 동안 InnoDB는 redo 로그를 스캔하여 카운터 값 변경 사항을 수집하고 변경 사항을 인메모리 테이블 객체에 적용합니다.
InnoDB가 auto-increment 값을 처리하는 방식에 대한 자세한 내용은 Section 17.6.1.6, “AUTO_INCREMENT Handling in InnoDB” 및 InnoDB AUTO_INCREMENT Counter Initialization을 참조하십시오.
인덱스 트리 손상이 발생하면, InnoDB는 손상 플래그를 redo 로그에 기록하며, 이를 통해 손상 플래그는 크래시 세이프하게 됩니다. 또한 InnoDB는 각 체크포인트 시 인메모리 손상 플래그 데이터를 엔진 전용 시스템 테이블에 기록합니다. 복구 동안 InnoDB는 두 위치에서 손상 플래그를 읽어 결과를 병합한 후 인메모리 테이블 및 인덱스 객체를 손상된 상태로 표시합니다.
일부 데이터 손실이 허용되는 경우라도, 복구를 빠르게 하기 위해 redo 로그를 제거하는 것은 권장되지 않습니다. redo 로그 제거는 innodb_fast_shutdown이 0 또는 1로 설정된 클린 셧다운 이후에만 고려해야 합니다.
불완전한 transaction rollback
불완전한 트랜잭션은 예기치 않은 종료 또는 fast shutdown 시점에 active 상태였던 모든 트랜잭션을 의미합니다. 불완전한 트랜잭션을 롤백하는 데 걸리는 시간은, 서버 부하에 따라, 트랜잭션이 중단되기 전 active 상태였던 시간의 세 배 또는 네 배가 될 수 있습니다.
Rollback 중인 트랜잭션은 취소할 수 없습니다. 극단적인 경우, 트랜잭션 롤백에 매우 오랜 시간이 걸릴 것으로 예상되면, innodb_force_recovery 설정을 3 이상으로 하여 InnoDB를 시작하는 편이 더 빠를 수 있습니다. 자세한 내용은 Section 17.20.3, “Forcing InnoDB Recovery”를 참조하십시오.
Change buffer ( system tablespace의 일부 )에서 비롯된 변경 사항을, 인덱스 페이지가 버퍼 풀로 읽혀질 때 세컨더리 인덱스의 리프 페이지에 적용합니다.
Active 트랜잭션에 더 이상 보이지 않는 delete-marked 레코드를 삭제합니다.
Redo 로그 적용 이후의 단계는 (쓰기 작업을 로깅하는 경우를 제외하면) redo 로그에 의존하지 않으며, 정상 처리와 병렬로 수행됩니다. 이 중 불완전한 트랜잭션 롤백만 크래시 복구에 특화되어 있습니다. Insert 버퍼 머지와 purge는 정상 처리 동안 수행됩니다.
Redo 로그 적용 후, InnoDB는 다운타임을 줄이기 위해 가능한 한 빨리 커넥션을 허용하려고 시도합니다. 크래시 복구의 일부로, InnoDB는 서버가 종료되었을 때 커밋되지 않았거나 XA PREPARE 상태였던 트랜잭션을 롤백합니다. 롤백은 백그라운드 스레드에 의해 수행되며, 새 커넥션의 트랜잭션과 병렬로 실행됩니다. 롤백 작업이 완료될 때까지, 새 커넥션은 복구된 트랜잭션과 잠금 충돌을 겪을 수 있습니다.
대부분의 상황에서, MySQL 서버가 높은 액티비티 중간에 예기치 않게 종료되더라도, 복구 프로세스는 자동으로 진행되며 DBA가 할 일은 없습니다. 하드웨어 장애 또는 심각한 시스템 오류로 인해 InnoDB 데이터가 손상된 경우 MySQL이 시작을 거부할 수 있습니다. 이러한 경우, Section 17.20.3, “Forcing InnoDB Recovery”를 참조하십시오.
바이너리 로그와 InnoDB 크래시 복구에 대한 정보는 Section 7.4.4, “The Binary Log”를 참조하십시오.
복구 도중 InnoDB가 마지막 체크포인트 이후에 기록된 redo 로그를 발견하면, 해당 redo 로그는 영향을 받는 테이블스페이스에 적용되어야 합니다. 복구 중 영향을 받는 테이블스페이스를 식별하는 프로세스를 _tablespace discovery_라고 합니다.
Tablespace discovery는 시작 시 테이블스페이스 파일을 스캔할 디렉터리를 정의하는 innodb_directories 설정에 의존합니다. innodb_directories의 기본값은 NULL이지만, InnoDB가 시작 시 스캔할 디렉터리 목록을 구성할 때 innodb_data_home_dir, innodb_undo_directory, datadir에 의해 정의된 디렉터리는 항상 innodb_directories 인자 값에 추가됩니다. 이러한 디렉터리는 innodb_directories 설정을 명시적으로 지정했는지 여부와 관계없이 추가됩니다. 절대 경로로 정의되었거나 innodb_directories에 추가된 디렉터리 밖에 위치한 테이블스페이스 파일은 innodb_directories 설정에 추가해야 합니다. Redo 로그에서 참조되는 테이블스페이스 파일이 하나라도 사전에 발견되지 않은 경우 복구는 종료됩니다.
17.18.1 InnoDB Backup
17.19 InnoDB and MySQL Replication
