[MySQL] InnoDB 버퍼 풀

버퍼 풀은 디스크의 데이터와 인덱스를 캐시하는 역할과 쓰기 작업을 지연시켜 일괄처리하는 역할을 한다.

일반적으로 데이터를 변경하는 쿼리는 랜덤한 디스크 작업을 발생시킨다. 하지만 버퍼 풀이 이러한 변경된 데이터를 일괄 처리하게 되면 랜덤한 디스크 작업의 횟수를 줄일 수 있다.

그 밖에도 InnoDB의 버퍼 풀은 많은 백그라운드 작업의 기반이 되는 공간이다.

 

버퍼 풀은 메모리 내에 위치하며 크게 디스크에서 읽어온 데이터와 인덱스를 캐시해두는 '데이터 페이지 버퍼'와 MVCC를 위한 '언두 로그', 인덱스 업데이트 성능 향상을 위한 '인서트(체인지) 버퍼'로 구성된다.

버퍼 풀 자체는 세마포어로 관리되며 기존 1개의 인스턴스에서, 최근에는 기본 8개의 인스턴스를 지원한다.

 

 

---

 

 

☑️ 버퍼 풀 페이지 저장 메커니즘 (데이터 페이지 버퍼)

 

버퍼 풀은 전체 메모리를 특정 사이즈의 페이지로 관리하는데 각 페이지는 아래와 같은 메커니즘으로 관리된다.

• LRU 리스트(Least Recently Used) : New(Most Recently Used) + Old (Least Recently Used)
• 플러시 리스트 : 더티 페이지 목록
• 프리 리스트 : 비어있는 페이지

 

 

💠 LRU 리스트

 

LRU 리스트의 목적은 한번 읽어온 페이지를 최대한 오랫동안 버퍼풀에 저장해서 디스크 접근을 최소화하는 것이다.

클라이언트 요청 시, 아래와 같이 동작한다.

 

1. 필요한 레코드가 저장된 데이터 페이지가 버퍼 풀(LRU 리스트)에 있는지 검사한다.

• 어댑티트 해시 인덱스를 이용해 타겟 페이지를 조회한다.
• 해당 테이블의 B-Tree 인덱스를 이용해 버퍼 풀에서 타겟 페이지를 조회한다.

2. 페이지가 이미 존재한다면 해당 페이지를 MRU의 헤드로 올린다.

3. 페이지가 존재하지 않는다면 디스크로부터 데이터를 읽어와서 버퍼풀에 적재한다. 그리고 해당 페이지의 포인터를 LRU의 헤드에 추가하고, 해당 페이지를 실제로 읽는다면 그 때 MRU의 헤드 부분으로 이동한다.

• 새로운 페이지를 버퍼풀에 추가하기 위한 페이지 공간이 필요한 경우, 접근이 가장 오래된 페이지를 선정하여 버퍼풀에서 제거하고, 새로운 페이지를 리스트의 중간지점에 삽입하는데 이를 midpoint insertion이라고 한다. 또한 이를 기준으로 MRU와 LRU를 구분한다.
• 특정 데이터가 자주 접근 되었다면, 해당 페이지의 인덱스 키를 어댑티브 해시 인덱스에 추가한다. 

 

※ LRU 리스트 플러시

 

InnoDB 스토리지 엔진은 더티 페이지 플러시를 위해 플러시 리스트 플러시와 LRU 리스트 플러시를 사용한다. 이 중 LRU 리스트 플러쉬는 사용한지 오래된 데이터 페이지들(더티 페이지)을 제거해서 Free 리스트를 확보하는 작업이다.

1. LRU 리스트의 끝 부분 ~ 최대 innodb_lru_scan_depth만큼 페이지를 스캔
2. 더티 페이지는 디스크에 동기화, 클린 페이지는 즉시 프리 리스트로 페이지 이동. 

 

 

 

 

 

 

💠 플러시 리스트

 

더티 페이지의 페이지 목록을 관리한다. 디스크에서 읽어온 후, LRU 리스트에 있는 페이지 중 데이터 변경이 가해진 페이지는 플러시 리스트에 관리되고 특정 시점이 되면 디스크로 기록되어야 한다.

 

더티 페이지가 플러시 되는 시점은 체크 포인트 이벤트가 발생하거나, 특정 조건을 만족해서 더티 페이지 자체가 플러시 되는 경우다. 이 때, 더티 페이지에 저장된 변경 레코드가 실제 디스크 데이터 파일에 동기화 된다. 이후 변경 내용을 리두 로그에 기록하고, 버퍼 풀의 데이터 페이지에도 변경 내용을 반영한다.

체크 포인트의 두가지 유형

• Sharp Checkpoint
  • 모든 더티 페이지를 디스크에 동기화 한다.
  • 이 때, DB 서버의 동작이 일시 중단되며 MySQL이 종료될 때 주로 사용된다.
• Fuzzy CheckPoint
  • 더티 페이지를 일부만 디스크로 동기화 한다. 
  • 조금씩 옮기기 때문에 성능 문제가 덜하고, DB도 중단없이 계속 사용이 가능하다. 
  • Fuzzy CheckPoint의 발생 상황
    • Master Thread CheckPoint : 마스터 쓰레드는 주기적으로 Flush List 확인하여 일정 비율만큼의 Dirty Page를 동기화힌다.
    • FLUSH_LRU_LIST CheckPoint : Free Page 개수가 약 100개 이하로 여유 공간이 부족한 경우, LRU List의 Old 영역부터 일정 수치만큼 Scan 한 후 더티 페이지가 있으면 체크 포인트를 수행한다. 
    • Flush CheckPoint : Redo Log 파일이 거의 가득 차서, Redo Log 파일을 사용할 수 없는 경우 발생한다. 
    • Dirty Page too much Checkpoint : 버퍼 풀 공간 대비 더티 페이지 비율이 특정 수치에 도달하면 체크포인트를 수행한다. 

 

Double Write Buffer

 

 

Partial-page (Torn-page)

하드웨어의 오작동이나 시스템의 비정상 종료 등으로 페이지가 일부만 기록되는 현상을 파셜 페이지(Partial-page) 혹은 톤 페이지(Torn-page)라고 한다.

 

 

Double Write

데이터 무결성을 위해 파셜 페이지와 같은 문제를 해결할 때 사용하는 방법이다. 주로 플러시 리스트 플러시에 사용된다.

1. 실제 데이터 파일에 변경 내용을 기록하기 전에, 플러시할 더티 페이지들을 우선 묶어서 한 번의 디스크 쓰기로 시스템 테이블 스페이스의 DoubleWrite 버퍼에 기록한다.
2. 그리고 각 더티 페이지를 파일의 적당한 위치에 하나씩 랜덤으로 쓰기를 실행한다.
3. 만약 기록되는 도중 운영체제가 비정상적으로 종료된다면 DoubleWrite 버퍼가 사용된다.

 

 

 

💠 프리 리스트

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

 

 

☑️ Undo 로그

언두 영역은 DML로 데이터를 변경했을 때 변경되기 전의 데이터를 보관하는 곳이다.

단순 UPDATE와 DELETE 쿼리는 트랜잭션을 커밋하지 않아도 데이터 파일(데이터/인덱스 버퍼) 내용이 변경된다.

그리고 변경되기 전의 값을 백업한다. 이 상태에서 만약 사용자가 커밋하게 되면 현재 상태가 그대로 유지되고,

만약 롤백한다면 언두 영역에 백업되있던 데이터를 다시 데이터 파일(데이터/인덱스 버퍼)로 복구한다.

Undo의 데이터는 트랜잭션의 롤백과 트랜잭션의 격리 수준을 유지하면서 높은 동시성을 제공하는데 사용된다.

 

 

 

☑️ 인서트 버퍼

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

 

사용자에게 결과를 전달하기 전에 반드시 중복 여부를 체크해야 하는 유니크 인덱스는 인서트 버퍼를 사용할 수 없다. 인서트 버퍼에 임시로 저장돼 있는 인덱스 레코드 조각은 이후 백그라운드 스레드에 의해 병합되는데, 이 스레드를 인서트 버퍼 머지 스레드 라고 한다.