[Real MySQL 8.0] InnoDB 스토리지 엔진 아키텍처 (MVCC, 데드락 감지, ...)

MySQL 5.5 버전 이후 부터는 기본 스토리지 엔진이 InnoDB 스토리지 엔진으로 변경되었다.

1. InnoDB 스토리지 엔진

InnoDB는 MySQL에서 사용할 수 있는 스토리지 엔진 중 거의 유일하게 레코드 기반의 잠금을 제공하며,
그 때문에 높은 동시성 처리가 가능하고 안정적이며 성능이 뛰어나다.

 

 

1-1. PK에 의한 클러스터링

InnoDB의 모든 테이블은 기본적으로 PK를 기준으로 순서대로 클러스터링되어 디스크에 저장되며,
모든 세컨더리 인덱스는 레코드의 주소 대신 PK의 값을 논리적인 주소로 사용한다.

PK가 클러스터링 인덱스이기 때문에 PK를 이용한 레인지 스캔은 상당히 빨리 처리될 수 있다. 결과적으로 쿼리의 실행 계획에서 다른 보조 인덱스보다 PK가 선택될 확률이 높다.

MyISAM 스토리지 엔진에서는 구조적으로 클러스터링 키를 지원하지 않는다고 한다.

 

 

1-2. 외래 키 지원

외래 키 지원은 InnoDB 스토리지 엔진 레벨에서 지원하며, MyISAM에서는 사용 불가하다.

InnoDB에서 외래 키는 부모 테이블과 자식 테이블 모두 해당 컬럼에 인덱스 생성이 필요하고, 변경시에는 반드시 부모 테이블이나 자식 테이블에 데이터가 있는지 체크하는 작업이 필요하므로 잠금이 여러 테이블로 전파되고, 그로 인해 데드락이 발생할 때가 많으므로 개발할 때도 외래 키의 존재에 주의해야 한다.

foreign_key_checks 시스템 변수를 OFF로 설정하면 외래 키 관계에 대한 체크 작업을 일시적으로 멈출 수 있고 수동으로 데이터를 적재하거나 스키마 변경 등의 관리 작업을 편하게 할 수 있다. 하지만, 부모와 자식 테이블 간의 관계가 깨진 상태로 유지하면은 안되고 무조건 일관성을 맞춰준 후에 외래 키 체크 기능을 활성화 해야 한다.

 

 

1-3. MVCC ( Multi Version Concurrency Control)

MVCC의 가장 큰 목적은 잠금을 사용하지 않는 일관된 읽기를 제공하는 데 있다. 멀티 버전이란 하나의 레코드에 대해 여러 개의 버전이 동시에 관리된다는 의미다.
InnoDB는 언두 로그를 이용해 이 기능을 구현한다. 

한 Member 테이블에 아래와 같은 데이터를 삽입한다.

INSERT INTO MEMBER (m_id, m_name) VALUES (12, '데브풍');

INSERT문이 실행되면 InnoDB 버퍼풀과 데이터 파일에는 해당 데이터가 축적되어 있다.

그 후에, 12번의 이름을 '홍길동'으로 변경하는 수정 쿼리를 날린다.

UPDATE member SET m_name = '홍길동' where m_id = 12;

UPDATE문이 실행되면 InnoDB 버퍼풀에는 새로운 값인 '홍길동'으로 업데이트 된다. 그리고 데이터 파일에는 체크포인트나 Write Thread에 의해 새로운 값으로 업데이트 되어 있을 수도 있고 아닐 수도 있다. (InnoDB가 ACID를 보장하기에 일반적으로는 버퍼 풀과 데이터 파일은 동일한 상태라고 가정해도 됨)
그리고 언두 로그에는 변경되기 이전의 데이터중에 m_name 컬럼의 값만 복사해서 저장한다. 따라서, (12, '데브풍')의 데이터가 저장되어 있다. 

 

 

아직 COMMIT이나 ROLLBACK 되지 않은 상태에서 다른 사용자가 해당 레코드를 조회하면 어디에 있는 데이터를 조회할지가 주요 문제이다.

 

해당 문제는 MYSQL 서버의 시스템 변수(transaction_isolation)에 설정된 격리 수준에 따라 다르게 된다.
격리 수준이 READ_UNCOMMITTED 인 경우에는 InnoDB의 버퍼 풀이나 데이터 파일로부터 변경되지 않은 데이터를 읽어서 반환한다. 데이터가 변경되었든 아니든 변경된 상태의 데이터를 반환한다.
READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE의 경우에는 아직 커밋되지 않았기 때문에 InnoDB 버퍼 풀이나 데이터 파일에 있는 내용 대신 변경되기 이전의 내용을 보관하고 있는 언두 영역의 데이터가 반환된다. 

 

이러한 과정을 DBMS에서는 MVCC라고 부른다.
하나의 레코드에 대해서 두가지 버전이 유지되고, 필요에 따라 보여지는 데이터가 달라지는 구조다.

 

 

UPDATE 쿼리를 실행하면 InnoDB 버퍼 풀은 즉시 새로운 데이터로 변경되고 기존 데이터는 언두영역으로 복사되는 과정이 있다.
그 후에 COMMIT 명령이 실행되면 InnoDB는 더 이상 변경 작업 없이 지금의 상태를 영구적으로 만들어 버린다.
하지만, ROLLBACK 명령이 실행되면 언두 영역에 있는 백업 데이터를 InnoDB 버퍼 풀로 다시 복구하고 언두영역의 내용을 삭제한다.

COMMIT이 된다고 해서 언두 영역의 백업 데이터가 항상 바로 삭제되는건 아니고, 언두 영역을 필요로 하는 트랜잭션이 더 이상 없을 때 삭제된다.

 

 

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

InnoDB는 MVCC 기술을 이용하여 잠금을 걸지 않고 읽기 작업을 수행한다. 잠금을 걸지 않음으로 읽기 작업은 다른 트랜잭션이 가지고 있는 잠금을 기다리지 않고, 읽기 작업이 가능하다.

격리 수준이 SERIALIZABLE이 아닌 READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ 수준인 경우에는 INSERT와 연결되지 않은 순수한 읽기 작업은 다른 트랜잭션의 변경 작업과 관계 없이 항상 잠금을 대기하지 않고 바로 실행된다.

언두로그가 변경되기 전의 데이터를 읽어야 하는 상황을 위해 필요한 것이다.

오랜 시간 동안 활성상태인 트랜잭션으로 인해 MySQL 서버가 느려지거나 문제가 발생할 때가 가끔 있는데, 바로 이러한 일관된 읽기를 위해 언두 로그를 삭제하지 못하고 계속 유지해야 하기 때문에 발생하는 문제이다.
이렇기에 트랜잭션은 가능한 한 빠르게 롤백이나 커밋을 통해 완료해야 한다.

 

 

1-5. 자동 데드락 감지

InnoDB는 내부적으로 잠금이 교착 상태에 빠지지 않았는지 체크하기 위해 잠금 대기 목록을 그래프 형태로 관리한다.
InnoDB가 가지고 있는 데드락 감지 스레드가 주기적으로 잠금 대기 그래프를 검사해서 교착 상태에 빠진 트랜잭션들을 찾아서 그 중 하나를 강제 종료시킨다.

강제 종료의 기준은 언두 로그의 양이며, 양이 적을수록 롤백의 대상이 된다. 이유는 예상되듯이 롤백을 해도 언두 처리를 해야 할 내용이 적으며, 트랜잭션 강제 롤백으로 인한 MySQL 서버의 부하도 덜 유발하기 때문이다.

InnoDB는 상위 레이어인 MySQL 엔진에서 관리되는 테이블 잠금은 볼 수가 없어서 데드락 감지가 불확실할 수 있다.
이때 innodb_table_locks 시스템 변수를 활성화하면 InnoDB 스토리지 엔진 내부의 레코드 잠금 뿐만 아니라 테이블 레벨의 잠금까지 감지할 수 있게 되므로 일반적으로는 해당 시스템 변수를 활성화 하면 된다.

동시 처리 스레드가 매우 많아지거나 각 트랜잭션이 가진 잠금의 개수가 많아지면 데드락 감지 스레드가 느려진다. 또한, 더 많은 CPU 자원을 사용하게 되므로 서비스에 악영향을 줄 수 있다.
해당 문제를 해결하는 방법은  innodb_deadlock_detect 시스템 변수를 OFF로 설정하여 데드락 감지 스레드의 작동을 중지시키고, 중지로 인한 데드락 문제의 사이드 이펙트를 줄이기 위해 innodb_lock_wait_timeout 시스템 변수를 활성화하여 데드락 상황에서 일정 시간이 지나면 자동으로 요청이 실패하고 에러 메시지를 반환하게 설정할 수 있다.

 

 

1-6. 자동화된 장애 복구

InnoDB는 손실이나 장애로부터 데이터를 보호하기 위해 여러 메커니즘이 적용되어 있다.

InnoDB는 매우 견고해서 데이터 파일이 손상되거나 MySQL 서버가 시작되지 못하는 경우는 거의 없다.
하지만 MySQL 서버와는 무관하게 디스크나 서버 하드웨어 이슈로 InnoDB 스토리지 엔진이 자동으로 복구를 못하는 경우가 발생할 수 있다.

InnoDB 데이터 파일은 기본적으로 MySQL 서버가 시작될 때 항상 자동 복구를 수행한다. 이 단계에서 복구할 수 없는 손상을 감지하면 자동 복구를 멈추고 종료돼 버린다.

이때는 innodb_force_recovery 시스템 변수를 1~6까지의 값 설정을 통해 단계 별로 선별적 자동복구를 수행시킬 수 있다.

자세한 설정은 필요할 때 찾아보기로 하고, 간단하게만 알아보자.

• InnoDB의 로그 파일이 손상되었다면 6으로 설정하고 재기동한다.
• InnoDB 테이블의 데이터 파일이 손상되었다면 1로 설정하고 재기동한다.
• 어떤 부분이 문제인지 알 수 없다면 innodb_force_recovery 값을 1부터 6까지 변경하면서 재기동 해본다.

해당 방법을 사용해도 문제가 해결되지 않을 수도 있다. 그때는 백업을 이용해 다시 구축하는 방법밖에 없다. 최대한 장애 이전 시점까지의 데이터를 복구할 수도 있으므로 데이터 손실이 그나마 적을 수 있다.