[RealMysql 8.0]04아키텍처 4.2.7 ~ 4.2.7.4

• InnoDB 버퍼 풀
  • InnoDb 스토리지 엔진에서 가장 핵심적인 부분으로 "디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간"이다
  • 쓰기 작업을 지연시켜 일괄 작업할 수 있게 해주는 버퍼 역할도 같이 한다.
  • 일반적인 application 에서는 insert, update, delete 처럼 데이터 변경하는 쿼리는 데이터 파일의 여러곳에 위치한 레코드를 변경하기 때문에, 랜덤한 디스크 작업이 발생하지만, 버퍼 풀을 통해 이러한 변경된 데이터를 모아서 처리하면 랜덤한 디스크 작업의 횟수를 줄일 수 있다.
• 버퍼 풀의 크기 설정
  • 운영체제와 각 클라이언트 스레드가 사용할 메모리도 충분히 고려해서 설정해야 한다.
  • 초기설정 후 모니터링을 통하여 조금씩 줄이거나 늘리는걸 추천
    • 운영체제 전체 메모리 8GB 미만이면 50%를 50GB라면 15GB~30GB 를 제외하고 버퍼 풀로 할당.
  • 버퍼풀의 변경은 크리티컬하기때문에 서버가 한가할때 진행하자.(늘리는 작업은 영향도가 적으나 줄이는건 영향도가 매우 크다)
  • 버퍼풀은 128MB 청크단위로 쪼개어 관리된다.
• 버퍼 풀의 구조
  • 페이지 크기의 조각으로 쪼개어 관리
  • LRU, Flush, Free 리스트 3개의 자료구조를 관리.
    • LRU
      • LRU? 가장 오래 전에 마지막으로 사용했던 페이지를 내보낸다. 
      • 디스크로부터 한 번 읽어온 페이지를 최대한 오랫동안 버퍼풀의 메모리에 유지하여 디스크 읽기를 최소하에 목적이 있다.
    • 플러시
      • 디스크로 동기화되지 않은 데이터를 가진 데이터 페이지(더티 페이지)의 변경 시점 기준의 페이지 목록을 관리
• 버퍼 풀과 리두 로그
  • redo log?
    • 트랜잭션이 수행되는 과정에서 모든 변경사항을 기록하는 로그 파일.
    • 이를 통해 트랜잭션의 원자성, 일관성, 복구 기능을 제공해 줌.
    • 트랜잭션이 완료되면 버퍼 풀에 있던 데이터를 디스크레 기록.
    • 버퍼풀과 리두 로그는 트랜잭션을 처리하는데 필수적인 역할을 하며, 상호작용하여 일관된 트랜잭션 처리를 제공해 줌. 
  • innodb 버퍼 풀은 디스크에서 읽은 상태로 전혀 변경되지 않은 클린페이지와 함께, 더티페이지도 가지고 있다. 이 더티 페이지는 언젠가 디스크로 기록돼야 하는데, 무한정 버퍼 풀에 머무를 수 있는것은 아니다. 
  • 리두 로그는 1개 이상의 고정 크기 파일을 연결해서 순환고리처럼 사용 하는데, 데이터 변경이 계속 발생된다면 기존 로그를 덮는 일이 발생된다.
  • 이를 방지하기위해 innodb 스토리지 엔진은 전체 리두 로그 파일에서 재사용 가능한 공간과 당장 사용할 공간으로 구분하여 관리하여야 하는데, 재사용 불가능한 공간을 활성 리두 로그라고 한다.
  • innobd 스토리지 엔진은 주기적인 체크포인트 이벤트를 발생시켜 리두 로그와 버퍼 풀의 더티 페이지를 디스크로 동기화를 진행한다.
• 버퍼 풀 플러시
  • 버퍼 풀에서 아직 디스크로 기록되지 않은 더티 페이지들을 성능상의 악영향 없이 디스크에 동기화 하기 위해 2개의 플러시 기능을 백그라운드로 실행.
  • 플러시 리스트 플러시, LRU 리스트 플러시
  • 플러시 리스트 플러시
    • 리두 로그 공간을 재활용하기위해 주기적으로 오래된 리두로그 공간을 비워줘야 함.
    • 이를 비우기 위해 반드시 버퍼 풀의 더티 페이지가 디스크랑 동기화 되어야 함.
    • 플러시 리스트 플러시 함수를 호출하여 플러시 리스트에서 오래전에 변경된 데이터 페이지 순서대로 디스크 동기화 작업을 수행.
  • LRU 리스트 플러시
    • LRU 리스트에서 사용 빈도가 낮은 데이터 페이지들을 제거해서 새로운 페이지들을 읽어올 공간을 만들어야 하는데, 이를위해 LRU 리스트 플러시 함수가 사용됨

 

ps.와..디비쪽도 볼게 많다..어떤걸 걸러서 봐야할지 좀 에매하다.