[MySQL] InnoDB 스토리지 엔진 아키텍처

MySQL의 InnoDB 스토리지 엔진은 MySQL에서 가장 널리 사용되는 트랜잭션 기반 스토리지 엔진 중 하나로, ACID(Atomicity, Consistency, Isolation, Durability) 속성을 지원하는 아키텍처를 제공한다.

 

오늘은 InnoDB 스토리지 엔진의 주요 아키텍처와 이를 통해 제공되는 중요한 기능들을 정리한다.

1. InnoDB 아키텍처 개요

InnoDB는 트랜잭션과 데이터 무결성을 보장하면서 고성능을 제공하기 위해 설계된 스토리지 엔진이다. MySQL에서 기본 스토리지 엔진으로 사용되며, 다양한 기능을 통해 데이터베이스 운영을 효율적으로 관리할 수 있다. 주요 구성 요소는 다음과 같다

• 버퍼 풀(Buffer Pool): InnoDB 스토리지 엔진에서 매우 핵심적인 부분. 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐싱해두는 공간이다. 정보가 바뀐 더티페이지들을 캐싱해서 disk로 일괄 쓰기할 수 있게 해주는 버퍼 역할도 같이 한다. 이런 방식으로 읽기 및 쓰기 성능을 향상 시킨다.
• 리두 로그(Redo Log): 리두 로그는 데이터베이스가 비정상적으로 종료될 경우, 데이터 손실을 방지하고 데이터 일관성을 유지하기 위해 사용된다. 모든 쿼리는 커밋될경우 리두로그에 추가되며, 리두로그는 disk 에 동기화된다. 하지만 데이터 자체는 디스크에 바로 동기화 되지 않는데, InnoDB 버퍼풀의 더티페이지에 변경된 데이터페이지들이 리두로그와 매핑되어 관리된다. InnnoDB 스토리지엔진이 주기적으로 체크포인트를 발생시켜 체크포인트 LSN보다 작은 리두로그와 연결된 더티페이지를 디스크로 한번에 동기화 시킨다.
• 언두 로그(Undo Log): 트랜잭션이 롤백될 때, 데이터를 이전 상태로 되돌리는 데 필요한 정보가 저장되는 공간이다. 즉, 트랜잭션에서 특정 row를 변경하면, 변경한 데이터가 InnoDB 버퍼풀에는 즉시 반영되고 변경전 데이터가 언두로그에 백업되는 식이다. 트랜잭션이 커밋되어도 언두로그의 백업데이터들이 바로 사라지지는 않는데, 이것은 MVCC(multi version concurrency control)를 구현하는데 핵심적인 데이터로 사용된다. 하나의 Row라도 어느 시점에 시작된 트랜잭션인가에 따라서 그 시점의 데이터로 읽혀야 하는데, Row의 데이터 변경 히스토리가 언두로그에 그대로 기록되어있으니 가능한 것이다.

2. 트랜잭션 처리

InnoDB는 MVCC(Multi-Version Concurrency Control)를 사용해 트랜잭션 간의 동시성을 보장한다. 이를 통해 여러 사용자가 동시에 데이터를 읽고 쓸 수 있으며, 락 경합을 줄여 성능을 높인다. 트랜잭션 격리 수준도 지원하여 애플리케이션에 맞는 동시성 및 일관성 요구 사항을 충족할 수 있다.

• 커밋 및 롤백: 트랜잭션이 성공적으로 완료되면 COMMIT 명령을 통해 변경 사항이 영구적으로 저장되며, 중간에 실패하면 ROLLBACK을 통해 이전 상태로 되돌릴 수 있다.

3. 잠금 메커니즘

InnoDB는 **행 단위 잠금(Row-level Locking)**을 지원하여 테이블 전체를 잠그지 않고, 특정 행만 잠금으로 처리하여 성능을 높인다. 또한 잠금 에스컬레이션이 없다는 점에서 매우 유연하며, 대규모 트랜잭션 처리에 유리하다.

4. 데이터 저장 구조

InnoDB의 데이터는 클러스터형 인덱스(Clustered Index) 구조로 저장된다. 기본 키를 중심으로 데이터가 물리적으로 정렬되어 저장되기 때문에 빠른 검색이 가능하다. 이 외에도 비클러스터형 인덱스를 통해 추가적인 검색 최적화를 제공한다.

5. Crash Recovery(장애 복구)

InnoDB는 시스템 장애 발생 시 리두 로그를 활용하여 데이터를 복구한다. 비정상 종료 후에도 데이터의 일관성을 유지할 수 있도록 트랜잭션에 대한 기록을 복원한다.