[Real MySQL 8.0] InnoDB 스토리지 엔진 알아보기 - 1편 (클러스터링 / 외래키 / MVCC)

🌱 InnoDB 스토리지 엔진 아키텍처

MySQL에서 가장 많이 사용하는 스토리지 엔진인 'InnoDB'에 대한 아키텍처를 알아보자.

그림이 복잡하기는 하지만, 왼쪽은 이전에 봤던 MySQL 엔진이고, 오른쪽이 InnoDB 스토리지 엔진의 구성도이다.
이번 포스팅에서는 innoDB 스토리지 엔진의 특징에 대해서 알아보도록 하자.
 

---

 

1. PK에 의한 클러스터링

기본적으로 InnoDB의 모든 테이블은 PK를 기준으로 클러스터링되어 저장된다.
여기서 클러스터링된다는 것은, PK 값이 비슷한 레코드끼리 묶어서 저장하는 것을 의미한다. PK 값이 레코드의 저장 위치를 결정하기 때문에 신중하게 결정해야 한다. 
일반적인 DBMS에서 세컨더리 인덱스의 리프 노드에는 데이터의 실질적인 물리 주소가 들어가서, 해당 인덱스의 데이터를 바로 가지고 오지만 innoDB에서는 PK 값에 대한 주소를 가지고 있다. 그래서 사용 시 PK 값을 찾아나가게 된다. (세컨더리 인덱스 -> PK 값 -> 데이터)

💡 세컨더리 인덱스란? (Secondary-Index)
PK 외의 정렬 기준이 필요할 때 사용되며, 하나의 테이블에 여러 개를 가질 수 있다.
순서를 가지지 않기 때문에 정렬되지 않아도 되며, unique 하지 않아도 된다는 점이 특징이다. (물론, 세컨더리 인덱스라고 했을 때 배표적인 예시로 유니크 키를 많이 뽑기는 한다.)
일종의 보조 역할을 하는 인덱스라고 생각하면 된다. 

모든 세컨더리 인덱스가 PK 값을 가지고 있다고 생각하면 된다.
⭐️ 만약 innoDB 테이블을 생성할 때 PK를 지정하지 않으면 내부적으로 대체할 컬럼을 찾게 되는데, NOT NULL이면서 unique한 인덱스 중에서 첫 번째 것을 클러스터 키로 삼게 된다. (단, 내부적으로 관리되기 때문에 조회 불가)
 
반면에, MyISAM 스토리지 엔진에서는 클러스터링 키를 지원하지 않기 때문에 PK와 세컨더리 인덱스가 구조적으로 아무런 차이가 없다. 단지, PK는 unique하다는 조건이 추가된 세컨더리 인덱스와 동일해진다. 또한, MyISAM 테이블의 모든 인덱스는 물리적인 레코드 주소값 (ROW-ID)을 가지기 때문에, PK 값이 변한다고 해서 실제 데이터 레코드의 위치가 변하지 않는다.
 

---

 

2. 외래키 지원

MyISAM과 다르게 InnoDB의 경우 FK를 지원한다. 사실 실무에서는 외래키를 잘 걸지 않는다는 말을 많이 들어서 이게 큰 이점이 될지는 모르겠지만, 로컬 환경에서 개발할 때는 좋게 쓰일 것으로 생각된다. 
만약 임시로 외래키 체크를 끄고 싶다면 다음 옵션을 사용하면 된다.

# 글로벌 설정
SET foreign_key_checks=OFF;

# 현재 작업을 진행하는 세션에 대해서만 끄기
SET SESSION foreign_key_checks=OFF;

해당 옵션을 끄게 되면 ON DELETE CASCADE, ON UPDATE CASCADE 같은 옵션은 사용할 수 없음을 유의하자.
참고로 외래키 옵션을 끈 뒤로 테이블에 대한 조작 작업을 했다면, 레코드 사이의 일관성이 깨지지 않았는지 잘 확인하고 다시 옵션을 켜야 한다. 
 

---

 

3. MVCC (Multi Version Concurrency Control)

MVCC는 동시 접근을 허용하는 데이터베이스에서 동시성을 제어하기 위해 사용하는 방법 중 하나이다. 여기서 말하는 'Multi Version'의 경우 하나의 레코드에 대해서 여러 개의 버전을 동시에 관리한다는 의미이다. (레코드 접근 시점에 대한 스냅샷을 관리한다.)
일반적으로 레코드 레벨의 트랜잭션을 지원하는 DBMS가 지원하는 기능이며, 락을 사용하지 않으면서 일관된 값을 읽도록 만드는 것이 목적이다. InnoDB의 경우 Undo log를 활용하여 이 기능을 구현한다.
 
격리 수준이 READ_COMMITTED일 때 어떤 식으로 처리하는지 그림으로 알아보자.
⭐️ 참고로, InnoDB에서는 기본적으로 REPEATABLE_READ을 기본 격리 레벨로 사용한다.

💡 READ_COMMITTED
특정 트랜잭션이 진행되는 동안 다른 트랜잭션은 해당 데이터에 접근할 수 없는 격리 레벨.
read 연산 시 실제 테이블 값을 가져오지 않고, Undo 영역의 백업된 레코드에서 값을 가져온다.
= 즉, 트랜잭션이 시작되기 전 데이터를 읽어오기 때문에 완전히 커밋된 데이터만 읽게 된다.
단, 커밋된 데이터만 읽기 때문에 동일한 select 쿼리를 날리더라도 같은 결과를 반환받지 못할 수도 있다.

CREATE TABLE `member` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(10) NOT NULL,
  `password` varchar(64) NOT NULL,
  PRIMARY KEY (`id`),
  INDEX KEY `name` (`name`)
) ENGINE=InnoDB;

위와 같이 간단하게 member에 대해 관리하는 테이블이 있다.
위 테이블에 다음과 같이 한 명의 멤버를 넣어보자.

insert into member(name, password) values ('journey', 'testpassword');

해당 레코드는 아래와 같이 관리된다.

PK와 name, password가 InnoDB 버퍼 풀과 디스크에 각각 저장된 것을 볼 수 있다.
 
만약, 해당 레코드에 업데이트가 일어났다면 어떻게 될까?

update member set password='realpassword' where id = 1;

update가 실행되면 변경 이전의 값을 undo 로그에 저장하고, 버퍼 풀에는 업데이트된 새로운 값으로 수정된다.
디스크의 경우 InnoDB의 백그라운드 스레드 중 쓰기 스레드 (Write)에 의해서 새로운 값으로 업데이트되며, 이때 ACID를 보장하기 때문에 일반적으로는 버퍼 풀과 데이터 파일이 동일하게 된다. (시점에 따라서 업데이트되기 전일수도 있지만)
 
그리고, 이 상태에서 select 쿼리를 날리게 되면 격리 레벨에 따라서 어디에 있는 데이터를 조회할지 달라진다. 만약 read_uncommitted라면 버퍼 풀에 있는 데이터를, read commmitted 이상의 레벨이라면 undo 로그에 있는 데이터를 읽게 된다.
이렇게 하나의 레코드에 대해서 여러 개의 버전 (버퍼 풀, 언두 로그)를 관리하기 때문에 'MVCC'라고 표현하며, 필요에 따라서 어떤 데이터가 보여질지 달라지게 됨을 의미한다.
 
이후 커밋이 일어나면, 해당 트랜잭션의 undo 로그가 더 이상 필요하지 않을 때 undo 로그를 제거하게 된다. 
보통 undo 영역은 일정 크기로 유지되기 때문에 가장 오래된 undo 세그먼트는 제거되거나, 혹은 정책에 의해서 관리된다.
 
만약, 위 상황에서 롤백이 일어난다면 어떻게 될까? 

위와 같이 undo 영역에 있는 값을 복구하고, undo 영역에 있는 값을 제거하게 된다.
 

---

 

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

앞서 말한 MVCC 덕분에 InnoDB의 경우 락 없이도 일관된 읽기를 제공할 수 있다.
여기서 말하는 '일관된 읽기'란, 격리 레벨이 READ_UNCOMMITTED / READ_COMMITTED / REPEATABLE_READ일 때 순수한 읽기 작업은 다른 트랜잭션의 변경 작업과 관련 없이 undo 영역의 값을 읽으면서 바로 실행됨을 의미한다.
 
하지만, 이를 위해 undo 영역의 값을 바로 삭제하지 못하고 계속 유지해야 하기 때문에 트랜잭션의 범위가 커질수록 MySQL의 서버가 느려지거나 문제가 발생할 수 있어서 주의해야 한다. (트랜잭션은 가능한 짧게 가져가는 게 좋다.)

💡 READ UNCOMMITTED
커밋, 롤백 여부와 상관없이 다른 트랜잭션의 값을 읽을 수 있는 격리 레벨.
이미 롤백이 되었는데도 해당 값을 읽을 수 있기 때문에 주의해야 한다. (Dirty read)

💡 REPEATABLE_READ
트랜잭션마다 ID를 부여하여, 실행 중인 트랜잭션 ID보다 작은 ID를 가진 트랜잭션의 변경 사항만 읽는 격리 레벨.
Undo 영역에 백업된 모든 레코드는 변경을 발생시킨 트랜잭션의 번호를 추가로 관리하고, 특정 트랜잭션보다 앞 번호의 레코드에서만 변경된 내용을 읽도록 만든다.
그래서 실행 중인 트랜잭션 중에서 가장 오래된 트랜잭션 번호보다 앞에 있는 Undo 영역의 데이터는 삭제할 수 없다.
하지만, 다른 트랜잭션에 의해서 값이 삽입되거나 변경되었을 때 해당 쿼리 전후로 select한 조회 결과가 달라질 수 있다. (Phantom read) -> InnoDB에서는 Next Key Lock을 활용하여 발생하지 않도록 만들었다.

💡 SERIALIZABLE
작업이 시작된 트랜잭션이 가지고 있는 레코드는 다른 트랜잭션에서 접근할 수 없는 격리 레벨.
읽기 작업에도 락이 필요하기 때문에 데이터의 정합성은 보장하지만, 처리 성능이 굉장히 떨어진다.

- 락에 대해서는 다음에 자세히 다룰 예정이니 이번에는 넘어가자 😊
 

---

 

5. 자동 데드락 감지

InnoDB에서는 교착 상태 감지를 위해서 락에 대한 대기 목록을 그래프 (Wait-for List) 형태로 관리한다.
- 여기서 교착 상태(데드락)란, 서로 다른 트랜잭션이 서로 필요한 락을 가지고 있어서 서로 무한하게 대기하고 있는 상태.
 
교착 상태의 경우 트랜잭션이 여러 테이블의 행에 대해 락을 거는 경우 (update나 select for update 구문 등을 통해서) 발생할 수 있는데, 이때 테이블 수준의 락을 위해서 테이블에 대한 잠금 목록을 관리한다. 이때, 두 번째 트랜잭션이 해당 레코드를 업데이트하거나, 이미 락이 걸린 테이블에 대해 다시 락을 획득하려고 하면, InnoDB는 해당 레코드에 대한 락 요청을 대기 목록에 추가한다. 최종적으로 락을 얻기 위해서는 레코드에 걸려있는 모든 락이 제거되어야만 얻을 수 있게 된다.
 
아래와 같이 information_schema / performance_schema DB를 확인하게 되면 트랜잭션에 대한 상태를 확인할 수 있다.

# 트랜잭션 상태 확인
select * from information_schema.INNODB_TRX;

# 현재 실행 중인 트랜잭션에서 잠금을 획득한 데이터나 유형, 트랜잭션 정보 확인 (MySQL 8.0부터)
# 어떤 트랜잭션의 어떤 데이터가 락이 걸린 상태인지 확인 가능
select * from performance_schema.data_locks;

# 락 대기 요청 목록 확인 (MySQL 8.0부터)
# 어떤 트랜잭션이 다른 트랜잭션의 락을 대기 중인지 확인 가능
select * from performance_schema.data_lock_waits;

 
데드락을 줄이기 위해서는 테이블 자체에 락을 거는 것보다는 트랜잭션 자체를 작게 유지하는 것이 좋다. 여러 트랜잭션이나 여러 테이블이 동시에 레코드를 업데이트한다면, 최대한 해당 트랜잭션들이 변경하는 레코드의 순서들을 일관되게 (동일한 순서로 업데이트되도록) 만드는 것이 좋다.
 
 

💬 데드락 감지 스레드

InnoDB의 경우 내부적으로 데드락 감지 스레드를 가지고 있으며, 해당 스레드는 그래프를 정기적으로 검사하여 교착 상태에 빠진 트랜잭션을 찾아 강제로 종료한다. 이때, Undo 로그의 양이 더 적은 트랜잭션을 롤백 대상으로 설정하게 된다.
 
참고로, InnoDB 스토리지 엔진이 아닌 MySQL 엔진 위에서 잠금된 테이블 (LOCK TABLES)은 볼 수가 없기 때문에 데드락에 대한 감지가 불확실할 수도 있지만, innodb_table_locks 변수를 활성화하면 레코드 락뿐만 아니라 테이블 락까지 감지가 가능해진다. (웬만하면 활성화하도록 하자.)
 
하지만, 만약 동시에 처리하는 스레드가 매우 많거나 하나의 트랜잭션에서 가지고 있는 락이 매우 많아진다면 데드락 감지 스레드 역시 느려진다. 이는 데드락 감지 스레드가 잠금 상태가 변경되지 않도록 잠금 목록이 저장되어 있는 테이블에 새로운 락을 걸고 스레드를 찾기 때문에, 데드락 감지 스레드가 느려지면 실제 비즈니스 로직을 처리하는 스레드 역시 락에 걸려서 계속 대기 상태에 빠질 수도 있다.
 
이를 위해서 MySQL 서버는 innodb_deadlock_detect라는 변수를 제공하고 있으며, 해당 변수를 OFF로 하면 데드락 감지 스레드가 더 이상 동작하지 않게 된다. 하지만, InnoDB 스토리지 엔진 내부에서 데드락이 발생하더라도 중재하는 스레드가 없으니 무한정 대기하기 때문에 innodb_lock_wait_timeout 변수를 활성화하여 일정 시간이 지나면 자동으로 요청이 실패하고 에러 메시지를 반환하도록 만들어야 한다. 즉, 데드락 감지 스레드 자체가 성능에 영향을 끼친다면 해당 스레드를 사용하지 않는 대신, 일종의 ttl을 통해 대기하도록 만드는 전략인 것이다. 기본값은 50초인데, 훨씬 더 낮은 시간을 사용하는 게 좋다.
 

---

 

6. 자동화된 장애 복구

InnoDB에는 손실이나 장애로부터 데이터를 보호하기 위한 매커니즘이 탑재되어 있다. 
기본적으로 MySQL 서버가 시작될 때 항상 자동 복구를 수행하기 때문에, 복구 불가능한 손상이 있다면 자동 복구를 멈추고 MySQL 서버 자체를 종료해버린다. (이때는 innodb_force_recovery 변수를 통해서 서버를 재시작해야 한다.) 재시작 후 mysqldump를 통해 가능한 데이터를 백업하고 서버와 DB를 재생성하자.
 
아래는 innodb_force_recovery 변수값에 따른 복구 모드 전략이다.

- 1 (SRV_FORCE_IGNORE_CORRUPT)
테이블스페이스의 데이터나 인덱스 페이지에서 손상된 부분이 발견되어도 무시하고 재시작.
테이블의 데이터 파일이 손상됐다면 사용하자.

- 2 (SRV_FORCE_NO_BACKGROUND)
백그라운드 스레드 중 메인 스레드를 시작하지 않고 재시작.
이는 메인 스레드가 undo 영역을 주기적으로 비울 때 장애가 발생했다면 사용하자.

- 3 (SRV_FORCE_NO_TRX_UNDO)
커밋되지 않고 종료된 트랜잭션은 그대로 남아있도록 재시작.
innoDB에서는 트랜잭션 실행 시 롤백에 대비하여 변경 전의 데이터를 undo 영역에 기록하고, 서버 재시작 시 undo 영역의 데이터를 우선적으로 데이터 파일에 적용하는데 보통 커밋되지 않은 데이터는 롤백을 한다.
이때 롤백을 하지 않고 재시작을 하는 전략이다.

- 4 (SRV_FORCE_NO_IBUF_MERGE)
인서트 버퍼의 내용을 무시하고 강제로 재시작.
innoDB는 CUD 작업으로 인해 인덱스가 변경 작업을 바로 처리하거나 인서트 버퍼에 저장해두고 나중에 데이터 파일에 merge하거나, 둘 중 하나를 채택하는데 만약 인서트 버퍼가 손상되었다면 사용하는 전략이다. 

- 5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
undo 로그를 모두 무시하고 재시작. 
innoDB에서는 MySQL 재시작 시 undo 영역에 있는 데이터를 이용하여 복구하고, redo 로그를 활용하여 종료 시점이나 장애 시점의 상태를 재현하며, 커밋되지 않은 트랜잭션에서 변경한 작업은 모두 롤백 처리되는데, 이러한 undo 로그가 손상되었을 때 사용하는 전략이다. 단, 이 전략을 사용하면 커밋되지 않은 작업도 모두 커밋된 것처럼 처리되기 때문에 주의해야 한다.

- 6 (SRV_FORCE_NO_LOG_REDO)
redo 로그를 모두 무시하고 재시작.
커밋되었거나 redo 로그에만 기록되고 데이터 파일에 기록되지 않은 데이터는 모두 무시되며, 마지막 체크포인트 시점에서의 데이터만 남게 된다. 

 

---

 
다음 포스팅에서는 innoDB의 핵심 부분인 버퍼 풀에 대해서 알아보도록 하자.