/Database/💬 MySQl/ InnoDB 스토리지 엔 아키텍쳐

4.2 InnoDB 스토리지 엔진 아키텍처 4.2.1 프라이머리 키에 의한 클러스터링 4.2.2 외래 키 지원 4.2.3 MVCC(Multi Version Concurrency Control) 4.2.4 잠금 없는 일관된 읽기(Non-Locking Consistent Read) 4.2.5 자동 데드락 감지 4.2.6 자동화된 장애 복구

2.7 InnoDB 버퍼 풀

---

• InnoDB 스토리지 엔진에서 가장 핵심적인 부분
• 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간
• 쓰기 작업을 지연시켜 일괄 작업으로 처리할 수 있게 해주는 버퍼 역할도 수행
• 일반적인 애플리케이션에서는 데이터를 변경하는 쿼리(INSERT, UPDATE, DELETE)는
  랜덤한 디스크 작업을 발생시키는데,
  InnoDB 버퍼 풀은 변경된 데이터를 모아서 처리하면 랜덤한 디스크 작업의 횟수를 줄여 주는 것이 가능

2.7.1 버퍼 풀의 크기 설정

---

• 운영체제와 각 클라이언트 스레드가 사용할 메모리도 충분히 고려해서 설정

• MySQL 서버 내에서 레코드 버퍼가 상당한 메모리를 사용하는 경우 :
  커넥션이 많고 사용하는 테이블도 많다면
  레코드 버퍼 용도로 사용되는 메모리 공간이 꽤 많이 필요해질 수도 있음

  • 레코드 버퍼
    • 각 클라이언트 세션에서 테이블의 레코드를 읽고 쓸 때 버퍼로 사용하는 공간
    • MySQL 서버가 사용하는 레코드 버퍼 공간은 별도로 설정할 수 없으며,
      전체 커넥션 개수와 각 커넥션에서 읽고 쓰는 테이블의 개수에 따라서 결정됨.
    • 동적으로 해제되기도하므로 정확히 필요한 메모리 공간의 크기를 계산할 수가 없음
      • MySQL 5.7 버전부터는 InnoDB 버퍼 풀의 크기를 동적으로 조절할 수 있게 개선
      • 그래서 가능하면 InnoDB 버퍼 풀의 크기를 적절히 작은 값으로 설정해서
        조금씩 상황을 봐 가면서 증가시키는 방법이 최적의 방법

• InnoDB 버퍼풀 크기 변경
  • innodb_buffer_pool_size :
    시스템 변수로 크기를 설정하고, 동적으로 버퍼풀의 크기를 확장
  • 가능하면 MySQL 서버가 한가한 시점을 골라서 진행하는 것이 좋음
  • InnoDB 버퍼풀을 더 크게 변경하는 작업은 시스템 영향도가 크지 않지만,
    버퍼풀의 크기를 줄이는 작업은 서비스 영향도가 매우 크므로 가능하면
    버퍼풀의 크기를 줄이는 작업은 하지 않도록 주의

• InnoDB 버퍼 풀은 전통적으로 버퍼 풀 전체를 관리하는 잠금(세마포어)으로 인해
  내부 잠금 경합을 많이 유발해왔는데, 이런 경합을 줄이기 위해
  버퍼 풀을 여러개로 쪼개어 관리할 수 있게 개선
  • innodb_buffer_pool_instances :
    버퍼풀을 여러개로 분리해서 관리할 수 있는데, 각 버퍼 풀을 버퍼 풀 인스턴스라고 표현
    • 버퍼풀 인스턴스의 개수
      • 기본적으로 8개로 초기화
      • 전체 버퍼풀을 위한 메모리 크기가 1GB 미만이면 버퍼풀 인스턴스는 1개만 생성
      • 버퍼풀로 할당할 수 있는 메모리 공간이 40GB 이하 수준 :
        기본값인 8을 유지하는 것이 좋음
      • 버퍼풀로 할당할 수 있는 메모리 공간이 40GB 보다 크다면 :
        버퍼풀 인스턴스당 5GB 정도가 되게 인스턴스 개수를 설정하는 것이 좋음

2.7.2 버퍼 풀의 구조

---

• InnoDB 스토리지 엔진은
  버퍼 풀이라는 거대한 메모리 공간을 페이지 크기(innodb_page_size 시스템 변수에 설정된)의 조각으로 쪼개
  InnoDB 스토리지 엔진이 데이터를 필요로 할 때 해당 데이터 페이지를 읽어서 각 조각에 저장

• 버퍼풀의 페이지 크기 조각을 관리하기 위해 InnoDB 스토리지 엔진은 3개의 자료 구조를 관리

  • 프리(Free) 리스트
  • LRU(Least Recently Used) 리스트
  • 플러시(Flush) 리스트

(1) 프리(Free) 리스트

---

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

(2) LRU(Least Recently Used) 리스트

---

• LRU(Least Recently Used) : Old 서브리스트 영역
• MRU(Most Recently Used) : New 서브리스트 영역

• LRU 리스트를 관리하는 목적
  • 디스크로부터 한 번 읽어온 페이지를
    최대한 오랫동안 InnoDB 버퍼풀의 메모리에 유지해서 디스크 읽기를 최소화

InnoDB 스토리지 엔진에서 데이터를 찾는 과정

1. 필요한 레코드가 저장된 데이터 페이지가 버퍼 풀에 있는지 검사
   • InnoDB 어댑티브 해시 인덱스를 이용해 페이지를 검색
   • 해당 테이블의 인덱스(B-Tree)를 이용해 버퍼 풀에서 페이지를 검색
   • 버퍼 풀에 이미 데이터 페이지가 있었다면 해당 페이지의 포인터를 MRU 방향으로 승급

2. 디스크에서 필요한 데이터 페이지를 버퍼 풀에 적재하고,
   적재된 페이지에 대한 포인터를 LRU 헤더 부분에 추가

3. 버퍼풀의 LRU 헤더 부분에 적재된 데이터 페이지가 실제로 읽히면 MRU 헤더 부분으로 이동
   (Read Ahead와 같이 대량 읽기의 경우 디스크의 데이터 페이지가 버퍼 풀로 적재는 되지만
   실제 쿼리에서 사용되지는 않을 수도 있으며, 이런 경우에는 MRU로 이동되지 않음)

4. 버퍼풀에 상주하는 데이터 페이지는 사용자 쿼리가 얼마나 최근에 접근했었는지에 따라 나이(Age) 부여,
   버퍼풀에 상주하는 동안 쿼리에서 오랫동안 사용되지 않으면
   데이터 페이지에 부여된 나이가 오래되고(‘Aging’이라고 함) 결국 해당 페이지는 버퍼 풀에서 제거됨.
   • 버퍼 풀의 데이터 페이지가 쿼리에 의해 사용되면 나이가 초기화되어 다시 젊어지고 MRU의 헤더 부분으로 옮겨짐.
   • Eviction : 버퍼 풀에서 데이터 페이지를 삭제해 추가 공간을 확보하는 작업
5. 필요한 데이터가 자주 접근됐다면 해당 페이지의 인덱스 키를 어댑티브 해시 인덱스에 추가

➡️ 처음 한 번 읽힌 데이터 페이지가 이후

• 자주 사용되는 경우 :
  그 데이터 페이지는 InnoDB 버퍼풀의 MRU 영역에서 계속 존재
• 거의 사용되지 않는 경우 :
  새롭게 디스크에서 읽히는 데이터 페이지들에 밀려서 LRU의 끝으로 InnoDB 버퍼 풀에서 제거

(3) 플러시(Flush) 리스트

---

• 디스크로 동기화되지 않은 데이터를 가진 데이터 페이지(더티 페이지)의 변경 시점 기준의 페이지 목록을 관리
• 일단 한 번 데이터 변경이 가해진 데이터 페이지는 플러시 리스트에 관리되고 특정 시점이 되면 디스크로 기록되야 함

• 데이터가 변경되면 InnoDB는 변경 내용을 리두 로그에 기록하면
  • 버퍼풀의 데이터 페이지에도 변경 내용을 반영
    -> 리두 로그의 각 엔트리는 특정데이터 페이지와 연결
  • 버퍼풀의 데이터 페이지에도 변경 내용을 반영하지 않은 경우
  • InnoDB 스토리지 엔진은 체크포인트를 발생시킴
    -> 디스크의 리두 로그와 데이터 페이지의 상태를 동기화

✔️ 체크포인트 :
MySQL 서버가 시작될 때 InnoDB 스토리지 엔진이
리두 로그의 어느 부분부터 복구를 실행해야 할지 판단하는 기준점을 만드는 역할

2.7.3 버퍼 풀과 리두 로그

---

• InnoDB의 버퍼풀과 리두 로그는 매우 밀접한 관계
• InnoDB의 버퍼 풀은 서버의 메모리가 허용하는 만큼 크게 설정하면 할수록 쿼리의 성능이 빨라짐
  (이미 디스크의 모든 데이터 파일이 버퍼 풀에 적재될 정도의 버퍼 풀 공간이 아닐 경우)

InnoDB 버퍼풀의 데이터베이스 서버의 성능 향상을 위한 역할

1. 데이터 캐시
2. 쓰기 버퍼링

• 데이터 캐시 기능 향상 :
  버퍼풀의 메모리 공간만 단순히 늘리는 것은 데이터 캐시 기능만 향상
• 데이터 캐시 기능 향상 + 쓰기 버퍼링 기능 향상 : …?

버퍼풀

---

• 클린 페이지(Clean Page) : 디스크에서 읽은 상태로 전혀 변경되지 않은 페이지
• 더티 페이지(Dirty Page) : INSERT, UPDATE, DELETE 명령으로 변경된 데이터를 가진 페이지

더티 페이지

• 디스크와 메모리(버퍼 풀)의 데이터 상태가 다르기 때문에 언젠가는 디스크로 기록
• 버퍼 풀에 무한정 머무를 수 있는 것은 아님

리두로그

---

• InnoDB 스토리지 엔진에서 리두 로그는 1개 이상의 고정 크기 파일을 연결해서 순환 고리처럼 사용됨
• 데이터 변경이 계속 발생하면 리두 로그 파일에 기록됐던 로그 엔트리는
  어느 순간 다시 새로운 로그 엔트리로 덮어 쓰임

• InnoDB 스토리지 엔진은
  전체 리두 로그 파일에서 재사용 가능한 공간과 당장 재사용 불가능한 공간을 구분해서 관리

redo log 상태

1. current
   • 현재 사용 중
   • 현재 LGWR이 내용을 기록하고 있는 상태
2. active
   • 활용 불가능한 상태
   • 아직 DB Buffer Cache 에서 Data File로 저장이 안 된 상태
3. inactive
   • 활용 가능한 상태
   • Data File에 저장 작업까지 끝난 Redo Log
   • Redo Log File을 삭제하고 싶다면 INACTIVE 상태로 만들고 수행해야 함
4. unused
   • 한번도 사용한 적이 없는 상태

• LSN(Log Sequence Number) :
  매번 기록될 때마다 로그 포지션은 계속 증가된 값을 갖음
  (리두 로그 파일의 공간은 계속 순환되어 재사용)

2.7.4 버퍼 풀 플러시(Buffer Pool Flush)

---

2.7.4.1 플러시 리스트 플러시

---

2.7.4.2 LRU 리스트 플러시

---

2.7.5 버퍼 풀 상태 백업 및 복구

2.7.6 버퍼 풀의 적재 내용 확인

2.8 Double Write Buffer

2.9 언두 로그

2.9.1 언두 로그 레코드 모니터링

2.9.2 언두 테이블스페이스 관리

---

(참고)

• Buffer Pool
• Redo Log File
• InnoDB 버퍼 풀과 주변 기능

공부한 내용을 여러글과 책 읽은 내용을 바탕으로 정리하고 있습니다.
좋은 글로 저의 공부에 도움을 주시는 분들께 감사드립니다.