[Real MySQL 8.0] InnoDB 버퍼 풀•언두 로그 •체인지 버퍼• 리두 로그

1. InnoDB 버퍼 풀

디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간이다. 쓰기 작업을 지연시켜 일괄 작업으로 처리할 수 있게 해주는 버퍼 역할도 같이 한다.

일반적인 애플리케이션에서는 INSERT, UPDATE, DELETE 처럼 데이터를 변경하는 쿼리는 데이터 파일의 이곳저곳에 위치한 레코드를 변경하기 때문에 랜덤한 디스크 작업을 발생시킨다.
하지만, 버퍼 풀이 이러한 변경된 데이터를 모아서 처리하면 랜덤한 디스크 작업의 횟수를 줄일 수 있다.

버퍼 풀의 크기 설정

운영체제와 각 클라이언트 스레드가 사용할 메모리를 고려하여 설정해야 한다.
MySQL 5.7 버전부터는 InnoDB 버퍼 풀의 크기를 동적으로 조절할 수 있게 개선되었다.

따라서 상황을 조금씩 보면서 증가시키는게 최적의 방법이다. 아래의 방법을 참고하자.

1. 운영체제의 전체 메모리 공간이 8GB 미만이라면 50% 정도만 InnoDB 버퍼 풀로 설정하고 나머지 공간은 MySQL 서버와 운영체제, 그리고 다른 프로그램이 사용할 수 있는 공간으로 확보해주는 것이 좋다.

2. 전체 메모리 공간이 그 이상이라면 InnoDB 버퍼 풀의 크기를 전체 메모리의 50%에서 시작해서 조금씩 올려가면서 최적점을 찾는다.

3. 전체 메모리 공간이 50GB 이상이라면, 대략 15GB에서 30GB 정도를 운영체제와 다른 응용 프로그램을 위해서 남겨두고 나머지를 InnoDB 버퍼 풀로 할당한다.

버퍼 풀을 더 크게 하는 것은 시스템 영향도가 크지 않지만, 줄이는 것은 시스템 영향도가 매우 크므로 줄이는 작업은 하지 않도록 해야한다.

버퍼 풀은 내부적으로 128MB 청크 단위로 쪼개져 관리되므로, 해당 단위 크기로 줄이거나 늘려야 한다.

버퍼 풀의 구조

버퍼 풀이라는 거대한 메모리 공간을 페이지 크기의 조각으로 쪼개어 InnoDB 스토리지 엔진이 데이터를 필요로 할 때 해당 데이터 페이지를 읽어서 각 조각에 저장한다.

InnoDB 스토리지 엔진은 버퍼 풀의 페이지 조각 관리를 위해 LRU 리스트, Flush 리스트, Free 리스틀라는 3개의 자료 구조를 관리한다.

• LRU(Least Recently Used) 리스트
  • 디스크로부터 한 번 읽어온 페이지를 최대한 오랫동안 InnoDB 버퍼 풀의 메모리에 유지해서 디스크 읽기를 최소화
• Flush 리스트
  • 디스크로 동기화되지 않은 데이터를 가진 데이터 페이지(Dirty Page)의 변경 시점 기준의 페이지 목록을 관리
• Free 리스트
  • 실제 사용자 데이터로 채워지지 않은 비어 있는 페이지들의 목록이며, 사용자 쿼리가 새롭게 디스크의 데이터 페이지를 읽어와야 하는 경우 사용된다.

버퍼 풀과 리두 로그

둘은 매우 밀접한 관계가 있다. 버퍼 풀은 서버의 메모리가 허용하는 만큼 크게 설정하면 할수록 쿼리의 성능이 빨라진다.
InnoDB 버퍼 풀은 데이터베이스 서버의 성능 향상을 위해 데이터 캐시와 쓰기 버퍼링이라는 두 가지 용도가 있는데, 버퍼 풀의 메모리 공간만 단순히 늘리는 것은 데이터 캐시 기능만 향상시키는 것이다. 쓰기 버퍼링 기능까지 향상시키려면 리두 로그에 대해서 알아야 한다.

InnoDB 버퍼 풀은 디스크에서 읽은 상태로 전혀 변경되지 않은 Clean 페이지와 함께 INSERT, UPDATE, DELETE 명령으로 변경된 데이터를 가진 Dirty 페이지를 가지고 있다.

1. Dirty 페이지는 디스크와 메모리(버퍼 풀)의 데이터 상태가 다르기 때문에 언젠가는 디스크로 기록돼야 한다.

2. 하지만,  더티 페이지는 버퍼 풀에 무한정 머무를 수 없기에 리두 로그 파일과의 순환 고리를 이용해 데이터 변경을 기록할 수 있다.

3. 리두 로그 파일에 데이터가 매번 기록될 때 마다 LSN(Log Sequence Number)이라는 값을 증가시킨다.

4. InnoDB 스토리지 엔진은 체크포인트 이벤트를 발생시켜 리두 로그와 버퍼 풀의 더티 페이지를 디스크로 동기화하며, 이렇게 발생한 체크포인트 중 가장 최근 체크포인트 지점의 LSN이 활성 리두 로그 공간의 시작점이 된다.

5. 체크포인트가 발생하면 체크포인트 LSN 보다 작은 리두 로그 엔트리와 관련된 더티 페이지는 모두 디스크로 동기화돼야 한다.

2. 언두 로그

트랜잭션과 격리 수준을 보장하기 위해 DML(INSERT, UPDATE, DELETE)로 변경되기 이전 버전의 데이터를 별도로 백업한 데이터를 의미한다. 아래와 같이 트랜잭션을 보장하고 격리 수준을 보장함으로써 높은 동시성을 제공할 수 있다.

• 트랜잭션 보장
  • 트랜잭션이 롤백되면 트랜잭션 도중 변경된 데이터를 변경 전 데이터로 복구해야 하는데, 이때 언두 로그에 백업해둔 이전 버전의 데이터를 이용해 복구한다.
• 격리 수준 보장
  • 특정 커넥션에서 데이터를 변경하는 도중에 다른 커넥션에서 데이터를 조회하면 트랜잭션의 격리 수준에 맞게 변경중인 레코드를 읽지 않고 언두 로그에 백업해둔 데이터를 읽어서 반환할 수도 있다.

언두 로그는 InnoDB에서 매우 중요한 역할을 하지만 관리 비용도 많이 필요하다. 

3. 체인지 버퍼

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

출처: https://hoing.io/archives/3513

체인지 버퍼는 기본적으로 InnoDB 버퍼 풀로 설정된 메모리 공간의 25%까지만 사용할 수 있게 설정되어 있고, 필요하다면 50% 까지 사용가능하도록 설정할 수 있다.

4. 리두 로그 및 로그 버퍼

리두 로그는 트랜잭션의 4가지 요소인 ACID 중에서 D(Durable)에 해당하는 영속성과 가장 밀접하게 연관되어 있다.
리두 로그는 HW나 SW 등 여러 가지 문제점으로 인해 MySQL 서버가 비정상적으로 종료됐을 때 데이터 파일에 기록되지 못한 데이터를 잃지 않게 해주는 안전장치 이다.

대부분의 데이터베이스 서버는 데이터 변경 내용을 로그로 먼저 기록한다. 거의 모든 DBMS에서 데이터 파일은 쓰기보다 읽기 성능을 고려한 자료구조를 가지고 있기 때문에 데이터 파일 쓰기는 디스크의 랜덤 액세스가 필요하다. 그래서 변경된 데잍러를 데이터 파일에 기록하려면 상대적으로 큰 비용이 필요하다.
이로인한 성능저하를 막기 위해 데이터베이스 서버는 쓰기 비용이 낮은 자료 구조를 가진 리두 로그를 가지고 있으며, 비정상 종료가 발생하면 리두 로그의 내용을 이용해 데이터 파일을 다시 서버가 종료되기 직전의 상태로 복구한다.

비정상 종료되는 경우 다음 두 가지 케이스가 있다.
1. 커밋됐지만 데이터 파일에 기록되지 않은 데이터
2. 롤백됐지만 데이터 파일에 이미 기록된 데이터

1번의 경우 리두 로그에 저장된 데이터를 데이터 파일에 다시 복사하기만 하면 된다.
2번의 경우에는 리두 로그로는 해결할 수 없는데, 이때는 변경되기 전 데이터를 가진 언두 로그의 내용을 가져와 데이터 파일에 복사하면 된다. 커밋, 롤백, 실행 중 등의 트랜잭션 상태를 확인하기 위해 2번의 경우에도 리두 로그가 필요하다.