4.2 아키텍처 (중)

 Mysql 스토리지 엔진 중 가장 많이 사용되는 InnoDB 스토리지 엔진을 간단히 살펴봅시다. 유일하게 레코드 기반의 잠금을 제공하며, 때문에 높은 동시성 처리가 가능하고 안정적이며 성능이 뛰어납니다.

 

1) 프라이머리 키에 의한 클러스터링

: InnoDB 모든 테이블은 기본적으로 프라이머리 키를 기준으로 클러스터링되어 저장한다. 다시말해 프라이머리 키값의 순서대로 디스크에 저장된다는 뜻이며, 모든 세컨더리 인덱스는 레코드의 주소 대신 프라이머리 키의 값을 논리적인 주소로 사용한다. 프라이머리 키가 클러스터링 인덱스이기 때문에 프라이머리 키를 이용한 레인지 스캔은 상당히 빨리 처리된다. 결과적으로 쿼리의 실행 계획에서 프라이머리 키는 기본적으로 다른 보조 인덱스에 비해 비중이 높게 설정된다.

 

2) 외래 키 지원

: 외래 키에 대한 지원은 InnoDB 스토리지 엔진 레벨에서 지원하는 기능으로 MyISAM이나 MEMORY 테이블에서는 사용할 수 없다. InnoDB에서 외래 키는 부모, 자식 테이블 모두 해당 칼럼에 인덱스 생성이 필요하고 변경 시에는 반드시 부모 테이블이나 자식 테이블에 데이터가 있는지 체크하는 작업이 필요하므로 잠금이 여러 테이블로 전파되고, 그로인해 데드락이 발생할 때가 많아서 외래 키의 존재에 주의해야 한다.

 

3) MVCC (Multi version concurrency Control)

: 일반적으로 레코드 레벨의 트랜잭션을 지원하는 DBMS가 제공하는 기능이며, 가장 큰 목적은 잠금을 사용하지 않는 일관된 읽기를 제공하는데 있다. InnoDB는 언두 로그를 이용해 이 기능을 구현하며, 여기서 멀티 버전이라 함은 하나의 레도크에 대해 여러개의 버전이 동시에 관리된다는 의미다. 쉬운 이해를 위해 격리 수준이 READ_COMMITED인 Mysql 서버에서 InnoDB 스토리지 엔진을 사용하는 테이블의 데이터 변경을 확인해보자.

 

Insert 후 데이터베이스 상태

 

update 후 데이터베이스 상태

 Update 실행되면 커밋 실행 여부와 관계없이 InnoDB 버퍼 풀은 새로운 값인 '경기'로 업데이트 된다. 데이터 파일에는 체크 포인트나 InnoDB의 Write 쓰레드에 의해 새로운 값으로 업데이트가 되었있을 수도, 안되어 있을 수도 있다.(InnoDB가 ACID를 보장하기 때문에 일반적으로는 InnoDB의 버퍼 풀과 데이터 파일은 동일한 사태라고 가정해도 무방하다.) 만약 COMMIT, ROLLBACK 되지 않은 상태에서 다른 사용자가 쿼리로 작업중인 레코드를 조회하면 어디에 있는 데이터를 조회할까?

 

 이는 Mysql 서버의 시스템 변수(transaction_isolation)에 설정된 격리 수준(Isolation Level)에 따라 다르다. 

1) 격리 수준이 READ_UNCOMMITED인 경우에는 InnoDB 버퍼 풀이 현재 가지고 있는 변경된 데이터를 읽어서 반환한다. 데이터가 COMMIT 됐든 아니든 변경된 상태의 데이터를 반환한다. 

 

2) 만약 READ_COMMITED, REPEATABLE_READ, SERIALIZABLE 경우 아직 commit 되지 않았기 떄문에 변경되기 이전의 내용을 보관하고 있는 언두 영역의 데이터를 반환한다. 이러한 과정을 DBMS에서 MVCC라고 표현한다. 하나의 레코드에 대해 2개의 버전이 유지되고, 필요에 따라 어느 데이터가 보여지는지 여러가지 상황에 따라 달라지는 구조다.

 

 UPDATE 쿼리가 실행되면 InnoDB 버퍼 풀은 즉시 새로운 데이터로 변경되고 기존 데이터는 언두영역으로 복사되는 과정까지 살펴봤는데, 이 상태에서 COMMIT 명령을 실행하면 InnoDB는 더 이상의 변경 작업 없이 지금의 상태를 영구적인 데이터로 만들어 버린다. 하지만 ROLLBACK을 실행하면 InnoDB는 언두 영역에 있는 백업된 데이터를 InnoDB 버퍼 풀로 다시 복구하고, 언두 영역의 내용을 삭제해버린다. 커밋이 된다고 언두 영역의 백업 데이터가 항상 바로 삭제되는 것은 아니다. 이 언두 영역을 필요로 하는 트랜잭션이 더는 없을 때 비로소 삭제된다.

 

 

4) 잠금 없는 일관된 읽기 (Non-Locking Consistent Read)

: InnoDB 스토리지 엔진은 MVCC 기술을 이용해 잠금을 걸지 않고 읽기 작업을 수행한다. 잠금을 걸지 않기에 InnoDB에서 읽기 작업은 다른 트랜잭션이 가지고 있는 잠금을 기다리지 않고, 읽기 작업이 가능하다. 격리 수준이 SERIALIZABLE 제외하고, 나머지가 기준이라면 INSERT와 연결되지 않은 순수한 읽기(SELECT) 작업은 다른 트랜잭션의 변경과 상관없이 바로 실행된다.

5) 자동 데드락 감지

: InnoDB 스토리지 엔진은 내부적으로 잠금이 교착상태에 빠지지 않았는지 체크하기 위해 잠금 대기 목록을 그래프 형태로 관리한다. 데드락 감지 스레드가 교착 상태에 빠진 트랜잭션들을 찾아서 그중 하나를 강제종료 시킨다. 종료를 선택하는 판단 기준은 (1) 언두 로그 양이며, 언두 로그 레코드를 더 적게 가진 트랜잭션이 일반적으로 롤백의 대상이 된다.

 

* 구글에서는 프라이머리 키 기반의 조회 및 변경이  아주 높은 빈도로 실행되는 서비스가 많았는데, 이는 매우 많은 트랜잭션을 동시에 실행하기 때문에 데드락 감지 스레드가 상당히 성능을 저하시킨다는 것을 알아냈다. 만약 PK 또는 세컨더리 인덱스를 기반으로 매우 높은 동시성 처리를 요구하는 서비스가 있다면 innodb_deadlock_detect를 비활성화해서 성능 비교를 해보는 것도 새로운 기회가 될 수 있다.

 

 

6) 자동화된 장애 복구

: InnoDB에서 손실이나 장애로부터 데이터를 보호하기 위해 여러 메커니즘이 탑재돼 있다. Mysql 서버가 시작될 때 완료되지 못한 트랜잭션이나 디스크에 일부만 기록된 데이터 페이지 등 일련의 복구 작업이 자동으로 진행된다. Mysql 서버의 설정 파일에 innodb_force_recovery 시스템 변수를 설정해서 Mysql 서버를 시작해야 한다. 일단 Mysql 서버가 기동되고 InnoDB 테이블이 인식된다면, 가능한 백업하고 그 데이터로 Mysql 서버의 DB와 테이블을 다시 만드는게 좋다.

 

InnoDB 복구를 위해 innodb_force_recovery 옵션에 설정 가능한 값은 1~6까지고, 각 숫자 값으로 복구되는 장애 상황과 해결방법이 있다. 참고로 0이 아닌 복구 모드에서는 SELECT 외 INSERT, UPDATE, DELETE 같은 쿼리는 수행할 수 없다.

 

 

4.2.7 InnoDB 버퍼 풀

 InnoDB 스토리지 엔진에서 가장 핵심이고, 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간이다. 쓰기 작업을 지연시켜 일괄 작업으로 처리할 수 있게 해주는 버퍼 역할도 같이 한다. 일반적인 애플리케이션에서는 INSERT, UPDATE, DELETE처럼 데이터를 변경하는 쿼리는 데이터 파일의 이곳저곳에 위치한 레코드를 변경하기 때문에 랜덤한 디스크 작업을 발생시킨다. 하지만 버퍼 풀이 이러한 변경된 데이터를 모아서 처리하면 랜덤한 디스크 작업의 횟수를 줄일 수 있다. 

 

1) 버퍼 풀의 구조

:  InnoDB 스토리지 엔진은 버퍼 풀이라는 거대한 메모리 공간을 페이지 크기의 조각으로 쪼개어 InnoDB 스토리지 엔진이 데이터를 필요로 할 때 해당 데이터 페이지를 읽어서 각 조각에 저장한다. 버퍼 풀의 페이지 크기 조각을 관리하기 위해 크게 LRU 리스트, Flush 리스트, Free 리스트라는 3개의 자료구조를 관리한다.

 

1. Free 리스트는 InnoDB 버퍼 풀에서 실제 사용자 데이터로 채워지지 않은 비어 있는 페이지들의 목록이며, 사용자의 쿼리가 새롭게 디스크의 데이터 페이지를 읽어와야 하는 경우 사용 된다.

 

2. LRU 리스트는 LRU와 MRU리스트가 결합된 형태이다. Old 서브리스트 영역은 LRU, New 서브리스트 영역은 MRU라고 이해하자. LRU 리스트를 관리하는 목적은 디스크로부터 한 번 읽어온 페이지를 최대한 오랫동안 InnoDB 버퍼 풀의 메모리에 유지해서 디스크 읽기를 최소화하는 것이다.

 

 그래서 처음 한 번 읽힌 데이터 페이지가 이후 자주 사용되면, 그 데이터 페이지는 InnoDB 버퍼 풀의 MRU 영역에서 계속 살아남고 반대로 거의 사용되지 않으면 새롭게 디스크에서 읽히는 데이터 페이지들에 밀려 LRU 끝으로 밀려 결국 InnoDB 버퍼 풀에서 제거될 것이다.

 

3. Flush 리스트는 디스크로 동기화되지 않은 데이터를 가진 데이터 페이지의 변경 시점 기준의 페이지 목록을 관리한다. 한번 데이터 변경이 가해진 데이터 페이지는 Flush 리스트에 관리되고, 특정 시점이 되면 디스크로 기록되어야 한다. 데이터가 변경되면 InnoDB는 변경 내용을 리두 로그에 기록하고, 버퍼 풀의 데이터페이지에도 반영한다. 리두 로그의 각 엔트리는 특정 데이터 페이지와 연결된다. 하지만 리두 로그가 디스크로 기록됐다고 해서 데이터 페이지가 디스크로 기록됐다는 것을 항상 보장하지 않는다.

 

반대 경우로 InnoDB 스토리지 엔진은 체크포인트를 발생시켜 디스크의 리두 로그와 데이터 페이지의 상태를 동기화한다. 체크포인트는 Mysql 서버가 시작될 때 InnoDB 스토리지 엔진이 리두 로그의 어누 부분부터 복구를 실행해야 할지 판단하는 기준점을 만드는 역할을 한다.

 

2) 버퍼 풀과 리두 로그

: InnoDB 버퍼 풀과 리두 로그는 밀접한 관계가 있다. 버퍼 풀은 서버의 메모리가 허용하는 만큼 크게 설정하면 할수록 쿼리 성능이 빨라진다. 하지만 InnoDB 버퍼 풀은 데이터베이스 서버의 성능 향상을 위해 데이터 캐시와 쓰기 버퍼링이라는 2가지 용도가 있는데, 버퍼 풀의 메모리 공간만 늘리는 것은 데이터 캐시 기능만 향상시키는 것이다. InnoDB 버퍼 풀의 쓰기 버퍼링 기능까지 향상시키려면 버퍼 풀과 리두 로그와의 관계를 먼저 이해해야 한다.

 

 InnoDB 버퍼 풀은 디스크에서 읽은 상태로 전혀 변경되지 않은 클린 페이지와 함께 INSERT, UPDATE, DELETE 명령으로 변경된 데이터를 가진 더티 페이지도 가지고 있다. 더티 페이지는 디스크와 메모리(버퍼 풀)의 데이터 상태가 다르기 때문에 언젠가는 디스크로 기록돼야 한다. 하지만 더티 페이지는 버퍼 풀에 무한정 머무를 수 없고, InnoDB 스토리지 엔진에서 리두 로그는 1개 이상의 고정 크기 파일을 연결해서 순환고리처럼 사용한다. 즉 데이터 변경이 계속 발생하면 리두 로그 파일에 기록됐던 로그 엔트리는 어느 순간 다시 새로운 로그 엔트리로 덮어 쓰인다.

 

 그래서 InnoDB 스토리지 엔진은 전체 리두 로그 파일에서 재사용 가능한 공간과 당장 재사용 불가능한 공간을 구분해서 관리해야 하는데, 재사용 불가능한 공간을 활성 리두 로그라고 한다. 위 그림에서 화살표를 가진 엔트리들이 활성 리두 로그 공간이다. 리두 로그 파일의 공간은 계속 순환되어 재사용되지만, 매번 기록될 때마다 로그 포지션은 계속 증가된 값을 갖게 되는데, 이를 LSN(Log Sequence number)라고 한다. InnoDB 스토리지 엔진은 주기적으로 체크포인트 이벤트를 발생시켜 리두 로그와 버퍼 풀의 더티 페이지를 디스크로 동기화하는데, 이렇게 발생한 체크포인트 중 가장 최근 체크포인트 지점의 LSN의 차이를 체크포인트 에이지(Checkpoint Age)라고 한다. 즉 활성 리두 로그 공간의 크기를 일컫는다.

 

 InnoDB 버퍼 풀의 더티 페이지는 특정 리두 로그 엔트리와 관계를 가지고, 체크포인트가 발생하면 체크포인트 LNS보다 작인 리두 로그 엔트리와 관련된 더티 페이지는 모두 디스크로 동기화돼야 한다. 물론 당연히 체크포인트 LSN보다 작은 LSN 값을 가진 리두 로그 엔트리도 디스크로 동기화돼야 한다.

 

 

3) 버퍼 풀 플러시

: 하지만 MySQl 5.7 버전 이후부터는 위에서의 디스크 쓰기 폭증 현상을 걱정하지 않아도 되는데, 2개의 플러시 기능을 백그라운드로 실행하고 있기 때문이다.

 

1. 플러시 리스트 플러시 -> 리두 로그 공간을 재활용을 위해서는 오래된 리두 로그 공간을 비워야 하는데, 그 이전에 버퍼 풀의 더티 페이지가 먼저 디스크로 동기화되어야 한다. 그리고 여러 시스템 변수들을 제공함으로써 얼마나 많은 더티 페이지를 한번에 디스크로 기록해 동기화할지를 유연하게 조정할 수 있다.

2. LRU 리스트 플러시  -> 사용 빈도가 낮은 데이터 페이지들을 제거해서 새로운 페이지가 들어올 공간을 만드는데 사용된다. LRU 리스트를 innodb_lru_scan_depth 크기 만큼 스캔하면서, 더티 페이지는 디스크에 동기화 시키고 클린 페이지는 즉시 프리 리스트로 옮긴다.

 

*InnoDB 스토리지 엔진에서는 Double-Write 기법을 이용한다. Double write 버퍼는 데이터의 안정성을 위해 자주 사용하는데, 데이터의 무결성이 매우 중요한 서비스에 활성화를 고려하는 것이 좋다.

 

 

4.2.9 언두 로그

 InnoDB 스토리지 엔진은 트랜잭션과 겨리 수준을 보장하기 위해 DML(INSERT, UPDATE, DELETE)로 변경되기 이전 버전의 데이터를 별도로 백업한다. 이렇게 백업된 데이터를 언두 로그(Undo Log)라고 한다.

 

1) 트랜잭션 보장 -> 트랜잭션이 롤백되면 트랜잭션 도중 변경된 데이터를 변경 정으로 복구해야 하는데 이때 언두 로그에 백업해 둔 이전 버전의 데이터를 이용해 복구한다.

 

2) 격리 수준 보장 -> 특정 커넥션에서 데이터를 변경하는 도중에 다른 커넥션에서 데이터를 조회하면 트랜잭션 격리 수준에 맞게 변경중인 레코드를 읽지 않고 언두 로그에 백업해둔 데이터를 읽어서 반환하기도 한다.

 

 Mysql 서버에서 INSERT 문장으로 인한 언두 로그와 UPDATE, DLETE 문장으로 인한 언두 로그는 별도로 관리된다. UPDATE, DELETE는 MVCC와 데이터 복구에 모두 사용되지만, INSERT는 MVCC를 위해 사용되지 않고, 롤백이나 데이터 복구만을 위해서 사용되기 때문이다.

 

 언두 로그가 저장되는 공간을 언두 테이블스페이스라고 한다. 하나의 언두 테이블 스페이스는 1개 이상 128개 이하의 롤백 세그먼트를 가지고, 롤백 세그먼트는 1개 이상의 언두 슬롯을 가진다. 하나의 롤백 세그먼트는 InnoDB의 페이지 크기를 16바이트로 나눈 값의 개수만큼 언두 슬롯을 가진다. 만약 InnoDB의 페이지 크기가 16KB라면 하나의 롤백 세그먼트는 1024개의 언두 슬롯을 가진다.

 

 하나의 트랜잭션이 필요로 하는 언두 슬롯의 개수는 트랜잭션이 실행하는 INSERT, UPDATE, DELETE 문장 특성에 따라 최대 4개 까지 언두 슬롯을 사용하게 된다. 최대 동시 트랜잭션 수 = (InnoDB 페이지 크기) / 16 * (롤백 세그먼트 개수) * (언두 테이블스페이스 개수)

가장 일반적인 설정 16KB InnoDB에서는 대량 131072(= 16 * 1024 / 16 * 128 * 2 / 2)개 정도의 트랜잭션이 동시에 처리 가능하다.

 

 언두 테이블스페이스 공간을 필요한 만큼 남기고 운영체제로 반납하는 것을 'Undo tablespace truncate' 라고 한다. 불필요한 공간을 잘라내는 방법은 자동과 수동 2가지 있고, Mysql8.0부터 지원된다.

 

 

4.2.10 체인지 버퍼

 RDBMS 에서 레코드가 INSERT 되거나 UPDATE될 때는 데이터 파일을 변경하는 작업 뿐 아니라 해당 테이블에 포함된 인덱스를 업데이트하는 작업도 필요합니다. 이때 인덱스를 업데이트 하는 작업은 랜덤하게 디스크를 읽는 작업을 선행해야 하므로 테이블에 인덱스가 많으면 이 작업은 많은 자원을 소모하게 됩니다. InnoDB 는 변경해야 할 인덱스 페이지가 버퍼 풀에 있으면 바로 업데이트를 하지만 그렇지 않고 디스크로 부터 읽어와서 업데이트를 해야 한다면 즉시 실행하지 않고 임시 공간에 저장해 두고 바로 사용자에게 결과를 반환하는 형태로 성능을 향상 시킵니다. 이때 사용하는 임시 메모리 공간을 체인지 버퍼 라고 합니다.

 

 하지만 유니크 인덱스의 경우 중복 여부를 체크해야 하기 때문에 체인지 버퍼를 사용할 수 없습니다. 체인지 버퍼에 임시로 저장된 인덱스 레코드 조각은 이후 백그라운드 스레드에 의해 병합됩니다. 이 스레드는 체인지 버퍼 머지 스레드라고 합니다. MySQL 5.5 부터 조금씩 개선되면서 MySQL 8.0 에서는 INSERT, DELETE, UPDATE로 인해 키를 추가하거나 삭제하는 작업에 대해서도 버퍼링이 될 수 있게 개선되었습니다.

 

 

4.2.11 리두 로그 및 로그 버퍼

 리두 로그는 트랜잭션의 4가지 요소인 ACID 중에서 D(영속성)와 가장 연관이 크다. 리두 로그는 하드웨어, 소프트웨어 등 여러 문제점으로 Mysql 서버가 비정상 종료되었을 때 테이터 파일에 기록하지 못한 데이터를 잃지 않게 해주는 안전장치다. Mysql 서버를 포함해 대부분 데이터베이스 서버는 데이터 변경 내용을 로그로 먼저 기록한다. 거의 모든 DBMS에서 데이터 파일은 쓰기보다 읽기 성능을 고려한 자료 구조를 가지고 있기 때문에 데이터 파일 쓰기는 디스크의 랜덤 엑세스가 필요하다.

 

그래서 변경된 데이터를 데이터 파일에 기록하려면 상대적으로 큰 비용이 필요한데, 이로 인한 성능 저하를 막기 위해 데이터베이스 서버는 쓰기 비용이 낮은 리두 로그를 가지고 있으며, 비정상 종료가 발생하면 리두 로그의 내용을 이용해 데이터 파일을 다시 서버가 종료되기 직전의 상태로 복구한다. 데이터베이스 서버는 ACID도 중요하지만 성능도 중요하기 때문에 데이터 파일 뿐만 아니라 리두 로그를 버퍼링할 수 있는 InnoDB 버퍼 풀이나 리두 로그를 버퍼링할 수 있는 로그 버퍼와 같은 자료 구조도 가지고 있다.

 

Mysql 서버가 비정상 종료되면, InnoDB 스토리지 엔진의 데이터 파일은 다음 2가지 종류의 일관되지 않은 데이터를 가질 수 있다.

1. COMMIT됐지만 데이터 파일에 기록되지 않은 데이터

2. ROLLBACK 됐지만 데이터 파일에 이미 기록된 데이터

 

 1번의 경우 리두 로그에 저장된 데이터를 데이터 파일에 다시 복사하기만 하면 된다. 하지만 2번의 경우 리두 로그로는 해결이 어렵고, 변경되기 전 데이터를 가진 언두 로그의 내용을 가져와 데이터 파일에 복사하면 된다. 추가로 최소한 그 변경이 커밋, 롤백, 트랜잭션의 실행 중간 상태였는지 확인하기 위해 리두 로그를 함께 사용해야한다.

 

 데이터베이스 서버에서 리두 로그는 트랜잭션이 커밋되면 즉시 디스크로 기록되도록 시스템 변수를 설정하는 것을 권장한다. 하지만 많은 부하를 유발할 수 있고, InnoDB 스토리지 엔진에서 제공하는 시스템 변수를 통해 어느 주기로 디스크에 동기화할 지 선택할 수 있다. InnoDB 스토리지 엔진의 리두 로그 파일들의 전체 크기는 InnoDB 스토리지 엔진이 가지고 있는 버퍼 풀의 효율성을 결정하기 때문에 신중히 결정해야 한다.

 

 

4.2.11.1 리두 로그 아카이빙

 Mysql 8.0부터 InnoDB 스토리지 엔진의 리두 로그를 아카이빙할 수 있는 기능이 추가됐다. 데이터 파일을 복사하는 동안 추가된 리두 로그 엔트리가 같이 백업지 않으면 복사된 데이터 백업 파일은 일관된 상태를 유지하지 못한다. Mysql 서버에 유입되는 데이터 변경이 너무 많으면 리두 로그가 매우 빠르게 증가하고, 리두 로그 내용을 복사하기도 전에 덮어쓰일 수도 있다. 리두 로그 아카이빙 기능은 데이터 변경이 많아서 리두 로그가 덮어쓰인다고 하더라도 백업이 실패하지 않게 해준다. 백업 툴이 리두 로그 아카이빙을 사용하려면 Mysql 서버에서 아카이빙된 리두 로그가 저장될 디렉터리를 innodb_redo_log_archive_dirs 시스템 변수에 설정해야 하며, 이 디렉터리는 Mysql 서버를 실행하는 유저만 접근이 가능해야 한다.

 

디렉터리 준비 후 리두 로그 아카이빙을 시작하도록 innodb_redo_log_archive_startUDF를 실행하면 된다. 1개 또는 2개 파라미터를 입력할 수 있는데, 첫 번째 파라미터는 리두 로그를 아카이빙할 디렉터리에 대한 레이블이며, 서브 디렉터리의 이름이다. 두번째 파라미터는입력하지 않아도 되는데, innodb_redo_log_archive_dirs 시스템 변수의 레이블에 해당하는 디렉터리에 별도 서브 디렉터리 없이 리두 로그를 복사한다.

 

InnoDB 리두 로그 아카이빙은 로그 파일이 로테이션될 때 복사되는 것이 아니라 리두 로그 파일에 로그 엔트리가 추가될 때 함께 기록하는 방식을 사용하고 있어서 데이터 변경이 발생하면 즉시 아카이빙된 로그 파일의 크기가 조금씩 늘어나는 것을 확인할 수 있다. 사용이 완료되면 사용자가 수동으로 삭제하면 된다. 만약 리두 로그 아카이빙을 시작한 세션이 innodb_redo_log_archive_stopUDF 실행 전 연결이 끊어진다면 InnoDB 스토리지 엔진은 리두 로그 아카이빙을 멈추고 아카이빙 파일도 자동으로 삭제해버린다.

 

4.2.11.2 리두 로그 활성화 및 비활성화

 InnoDB 스토리지 엔진의 리두 로그는 하드웨어, 소프트웨어 등 여러가지 문제점으로 Mysql 서버가 비정상 종료됐을 때 데이터 파일에 기록되지 못한 트랜잭션을 복구하기 위해 항상 활성화돼있다. Mysql 서버에서 트랜잭션이 커밋돼도 데이터 파일은 즉시 디스크로 동기화되지 않지만, 리두 로그는 항상 디스크로 기록된다. 8.0버전 부터 데이터를 복구하거나 대용량 데이터를 한번에 적재하는 경우 리두 로그를 비활성화해서 데이터의 적재시간을 단축할 수 있다.

 

리두 로그를 비활성화하고 데이터 적재 작업을 실행했다면, 적재 완료 후 다시 활성화하자. 리두 로그가 비활성화 된 상태에서 비정상 종료되면, 마지막 체크포인트 이후 시점의 데이터는 모두 복구할 수 없기 때문이다.