[Real MySQL 8.0] InnoDB 스토리지 엔진 알아보기 - 3편 (Buffer Pool - on disk structures)

🌱 들어가기 전

이번 포스팅에서는 InnoDB의 전반적인 아키텍처 중에서 디스크 영역에 대해서 알아보자.
마찬가지로 간단하게만 짚고 넘어가고자 한다.
 

---

 

저번 포스팅 그림 재탕...~

 

🌱 Tablespace

테이블 스페이스는 데이터를 저장하기 위해 사용되는 큰 논리적인 단위이며, Segment -> Extent -> Page -> Row와 같은 형태로 구성된다. MySQL에서 테이블 스페이스는 저장하는 데이터의 종류에 따라서 5가지로 분류가 가능한데, 이는 다음과 같다.
 
- System tablespace
- File-Per-Table tablespace
- General Tablespace
- Temporary Tablespace
- Undo Tablespace

---

 

🌱 System tablespace

System tablespace의 경우 MySQL에서 기본적으로 사용되는 Shared Tablespace이다.
체인지 버퍼가 있는 영역이며, 여기서 테이블을 생성하게 되면 테이블과 인덱스 데이터를 저장할 수 있다.
내부의 데이터 파일의 크기와 수는 innodb_data_file_path라는 시스템 환경변수로 설정이 가능하다.
 

---

 

🌱 File-Per-Table tablespace

하나의 테이블에 대한 데이터와 인덱스를 개별적인 파일로 관리하는 테이블 스페이스이다.
즉, 우리가 생성하는 테이블은 이 공간에 저장된다고 생각하면 된다. 
inno_file_per_table 옵션으로 조절이 가능하며, 해당 옵션을 비활성화 하면 시스템 테이블스페이스에 새엇ㅇ된다.
 
- truncate / drop 연산 시 디스크 공간은 OS에게 반납된다. (테이블 삭제 시 버퍼 풀을 잠그고 스캔하기 때문에 버퍼 풀이 크다면 시간이 더 소요될 수 있다는 점 주의)
- 다른 MySQL 인스턴스에서 file-per-table 공간에 있는 테이블을 가져올 수 있다.
 

---

🌱 General tablespace

create tablespace로 만든 구문을 사용해서 만들 수 있으며, shared tablespace여서 여러 테이블의 데이터를 저장할 수 있다.
다른 테이블 스페이스를 general로 변경할 수 없으며, 임시 테이블을 지원하지 않는다.
file-per-table 테이블 스페이스와 다르게 truncate / drop 시에 데이터 파일에 비어있는 공간이 생기며, OS로 반환되지 않는다.

---

 

🌱 Temporary tablespace

내부적으로 2가지의 테이블 스페이스로 분리되는데, Session / Global Temporary tablespace로 나뉜다.
 
Session Temporary tablespace의 경우 사용자가 생성한 임시 테이블과 옵티마이저가 임시로 생성하는 임시 테이블의 내용을 저장한다.
이 공간은 커넥션이 종료되면 truncate 되어서 temp tablespace pool로 반환된다. 풀의 경우 서버가 시작되면 10개의 temporary tablespace를 생성하며, 필요에 따라서 풀에 더 추가된다.
 
Global Temporary tablespace의 경우 임시 테이블에 대한 롤백 세그먼트들을 저장한다. 데이터 파일의 상대 경로나 이름, 크기, 속성을 정의하며 (innodb_temp_data_file_path 변수로 지정) 값을 지정하지 않았다면 하나의 데이터 파일로 생성하게 된다. (innodb_data_home_dir 디렉터리에 생성)
마찬가지로 종료되거나 중단되면 제거되고, 서버가 재시작되면 다시 생성된다.
 

---

 

🌱 Undo Tablespace

Undo tablespace에는 클러스터링 인덱스에 대한 Undo Log 정보가 포함되어 있다. Undo 로그의 경우 롤백 세그먼트 내부에 포함된 언두 로그 세그먼트에 존재하며, 롤백 세그먼트의 경우 undo tablespace or global tempory tablespace 안에 있다.
기본적으로 2개의 undo tablespace가 생성되며, innodb_undo_directory 시스템 변수에 정의된 위치에 파일이 생성된다. (미지정 시 mysql data 디렉터리에 생성)
⭐️ 여기서 일반 테이블에 대한 트랜잭션은 Undo tablespace, 임시 테이블에 대한 트랜잭션은 Global temporary tablespace에 undo log가 할당된다.
 
 

💬 Undo Log

InnoDB는 트랜잭션 (롤백 대비)과 격리 수준 보장을 위해 CUD 쿼리로 데이터가 변경되기 이전의 데이터를 별도로 백업하며, 이를 Undo Log라고 한다. 매우 중요한 역할을 하는 만큼 관리 비용도 상당하다.
 
만약, A라는 트랜잭션이 매우 길어서 그 사이에 여러 CUD 작업이 일어났다면, 사이에 발생한 작업의 트랜잭션이 끝나더라도 언두 로그는 계속해서 보존될 것이다. MySQL 5.5 이전에서는 한 번 증가한 언두 로그 공간이 다시 줄어들지 않았다. 이러다 보니 대용량의 데이터를 처리할 때 언두 로그의 양이 급격하게 증가되고, 조회 시마다 커진 언두 로그를 스캔하면서 성능이 나빠지게 되었다. 하지만 8.0으로 오면서 필요한 시점에 크기를 줄여주거나, 언두 로그를 돌아가면서 사용해서 디스크 공간이 크게 늘어나지 않도록 만들어두었다.
 
또한, 언두 로그가 얼마나 증가했는지 모니터링하는 기능도 추가되었다.

SHOW ENGINE INNODB STATUS \G

이런 식으로 나온다. 저기서 History List에 있는 숫자가 언두 로그의 건수이다. (딱히 작업한 게 없어서 0이다)
 
MySQL 8.0이라면 아래와 같이 좀 더 명시적으로 확인할 수 있다.

select count
from information_schema.INNODB_METRICS
where SUBSYSTEM='transaction'
and name = 'trx_rseg_history_len';

 

💡 참고로, 언두 로그의 경우 최대 4개로 분리된다.

- 사용자 정의 테이블에 대한 INSERT
- 사용자 정의 테이블에 대한 UPDATE / DELETE
- 사용자 정의 임시 테이블에 대한 INSERT
- 사용자 정의 임시 테이블에 대한 UPDATE / DELETE

이는 UPDATE / DELETE 시 발생한 언두 로그는 MVCC, 데이터 복구에 모두 사용되지만 INSERT의 경우 데이터 복구에 대해서만 사용되기 때문에 위에서 사용했던 확인 방법으로는 UPDATE / DELETE로 인해 발생한 언두 로그 개수만 표시된다.

 
이러한 언두 로그는 MySQL 8.0부터 로그 파일을 통해서 기록된다.
이전에는 시스템 테이블스페이스에 저장됐었는데, 1~128개의 롤백 세크먼스를 가진다. (페이지 크기 / 16bytes개)
하나의 롤백 세그먼트 내에는 다시 1개 이상의 Undo 슬롯을 가지고 있으며, 하나의 트랜잭션은 최대 4개까지의 언두 슬롯을 사용한다. (일반적으로는 2개)
그래서, 동시에 처리할 수 있는 트랜잭션의 개수는 보통 (innoDB 페이지 크기) / 16 * (롤백 세그먼트 개수) * (언두 테이블스페이스 개수)로 구할 수 있다. 언두 로그 공간이 부족하면 트랜잭션을 시작할 수 없기 때문에, 언두 로그 관련 변수를 조절할 때는 동시에 처리할 수 있는 트랜잭션 개수에 따라서 테이블스페이스와 롤백 세그먼트 개수를 설정해야 한다.
 
MySQL 8.0부터는 create undo tablespace나 drop tablespace 등을 통해서 동적으로 테이블 스페이스를 추가하거나 삭제할 수 있다. 

# undo log 관련 테이블스페이스 확인
select TABLESPACE_NAME, FILE_NAME
from information_schema.FILES
where FILE_TYPE like 'undo log'

 

 
💬 Undo tablespace 공간 줄이기

만약 언두 테이블스페이스의 공간을 줄이고 싶다면, 2가지의 방법을 사용할 수 있다.
CUD 쿼리 작업 시 언두 로그로 기록되는데, 트랜잭션이 커밋되면 언두 로그에 복사된 값은 불필요하기 때문에 퍼지 스레드가 주기적으로 해당 값을 제거한다. 이때, innodb_undo_log_truncate 시스템 변수가 on이라면 퍼지 스레드가 주기적으로 사용하지 않는 공간을 OS에게 반납한다. (반납 주기는 innodb_purge_rseg_truncate_frequency 변수 조정)
 
혹은, 직접 비활성화 쿼리를 이용해서 퍼지 스레드가 비활성 상태인 테이블스페이스를 반납하도록 만들 수 있다. (이때는 테이블스페이스가 최소 3개 이상은 되어야 작동이 가능하다.)

# 비활성화
alter undo tablespace tablespace_name set inactive;

# 퍼지 스레드에 의해 언두 테이블스페이스 공간이 반납되면 재활성화
alter undo tablespace tablespace_name set active;

---

 

🌱 Double Write Buffer

리두 로그는 페이지의 변경된 부분만 기록하는데, 만약 더티 페이지 플러시 시 일부만 기록되는 문제가 발생한다면 해당 페이지 내용은 복구 불가능할 수도 있다. 이런 식으로 일부만 기록되는 것을 Partial-Page, 또는 Torn-Page라고한다.
이러한 문제를 막기 위해 InnoDB에서는 'Double-Write'라는 공간을 통해, 버퍼 풀로부터 플러시된 페이지를 데이터 파일에 쓰기 전에 저장한다.
 

1. A~E까지의 더티 페이지 플러시
2. 디스크로 기록하기 전에 A~E까지의 데이터를 묶어서 Double Write Bufer에 기록
3. 더티 페이지를 적당한 위치에 랜덤으로 쓰기 작업 진행

 
만약 정상 기록 시 Double Write Buffer에 기록된 것은 제거되고, 비정상적으로 종료되었다면 해당 내용을 참조하여 복구한다.
데이터의 무결성이 중요한 서비스라면 사용하는 것이 좋다. (innodb_doublewrite 변수 사용)
- 참고로 innodb_flush_log_at_trx_commit 옵션을 (커밋 시 아무 작업도 X, 해당 옵션이 켜져 있다면 커밋 시 로그 버퍼에 데이터 쓰고 => 디스크에 데이터 쓰는 작업 진행) 성능상으로 껐다면 doublewrite도 끄자.
 

---

 

🌱 Redo Log 

Redo Log는 비정상적으로 종료된 트랜잭션에 의해 변경된 데이터를 적용하기 위해서 사용한다. (복구 작업) 기본적으로 MySQL은 innoDB의 변경 내용을 바로 디스크에 저장하지 않고 버퍼 풀에 저장하기 때문에, 변경된 데이터가 디스크에 적용되지 않았다면 재시작 동작 중에 Redo 작업을 먼저 수행하게 된다. 

- 참고로, 복구 작업은 다음과 같은 단계로 이루어진다.
테이블 스페이스 탐색하기 -> 리두 로그 적용하기 -> 완료되지 않은 트랜잭션 롤백하기 -> 체인지 버퍼 병합하기 -> 퍼지하기

 
기본적으로 버퍼 풀은 디스크에서 데이터를 읽은 상태로 전혀 변경되지 않은 Clean 페이지와, 변경되었지만 디스크에 아직 기록되지 않은 Dirty 페이지를 가지고 있는데, Dirty 페이지의 경우 디스크와 버퍼 풀 메모리에 적재된 데이터의 상태가 다르기 때문에 둘을 동기화해야 한다. 
 
더티 페이지의 경우 사실상 버퍼풀에 임시로 유지되는 데이터 상태이기 때문에, innoDB에서는 이를 제거하기 위해 여러 가지 방법을 사용한다. 그리고, 이 방법 중 하나가 '활성 리두 로그 - Active Redo Log'를 사용하는 것이다.
 
활성 리두 로그의 경우 여러 파일로 구성되어 있으며, 데이터 변경이 발생할 때마다 새로운 로그 엔트리로 덮어씌우며 기록된 파일을 순차적으로 재사용하는 것이다. (쓰여진 리두 로그 자체) 재사용을 하기 때문에 리두 로그에서는 재사용이 가능한 공간과 재사용이 불가능한 공간으로 나누어지며, 이 중에서 활성 리두 로그의 경우 '재사용 불가능 공간'을 의미한다.
 
리두 로그는 순환하기 때문에 기존의 데이터는 계속 덮어 씌워지면서 없어진다. 하지만, 기록될 때마다 계속 증가하는 'LSN (Log Sequence Number)'이라는 값을 표시한다. LSN은 Redo Log에 기록된 작업의 시점을 가리킨다고 볼 수 있다.

💡 InnoDB는 주기적으로 체크포인트를 통해 Redo 로그와 버퍼 풀의 Dirty 페이지를 디스크로 동기화한다.
이렇게 발생한 체크포인트 중에서 가장 최근 체크포인트 지점의 LSN이 활성 리두 로그 공간의 시작점이 된다.

💡 CheckPoint
- 체크포인트가 발생하면 버퍼 풀 내의 변경된 페이지를 디스크로 동기화 작업을 진행한다.

Sharp CheckPoint
- 커밋된 트랜잭션의 모든 더티 페이지를 디스크에 플러시하고, 가장 최근에 커밋된 트랜잭션의 LSN을 기록함
- 정상 종료나 리두 로그 파일을 순환하여 재사용할 때 Sharp CheckPoint 활용

Fuzzy CheckPoint
- 더티 페이지를 조금씩 디스크로 플러시하고, 그 위치를 시작 - 종료 지점의 LSN을 기록하여 관리
- 마스터 스레드에 대해 1~10초마다 주기적으로 플러시 리스트 확인 
- 프리 페이지의 여유 공간이 부족할 때 LRU 리스트의 더티 페이지 체크포인트
- 리두 로그 파일이 다 찼을 때 일부 페이지 강제 플러시 시 사용
- 더티 페이지가 너무 많을 때 체크포인트

 
또한, 가장 최근 지점의 LSN과 마지막 리두 로그 엔트리의 LSN 차이를 Checkpoint Age라고 하며, 해당 값이 클수록 아직 디스크에 반영되지 않은 변경사항이 많다는 것을 의미하기 때문에 체크포인트를 적절한 시점에 수행해주는 것이 중요하다.

결과적으로 버퍼 풀의 dirty 페이지는 특정 리두 로그 엔트리와 관계를 가지고, 체크포인트가 발생하면 체크포인트 LSN보다 작은 리두 로그 엔트리와 관련된 dirty 페이지, 리두 로그 엔트리는 모두 디스크로 동기화돼야 한다. 

 
ex) 버퍼 풀이 100기가, 리두 로그 파일의 전체 크기는 100메가
- Checkpoint Age 역시 최대 100메가까지 허용된다. 리두 로그 엔트리가 평균적으로 4KB라면 100MB / 4KB = 25600개 정도의 dirty 페이지만 버퍼 풀에 보관할 수 있게 된다. 만약 데이터 페이지가 16KB라면 허용 가능한 전체 더티 페이지는 400MB 정도이다.
= 버퍼 풀은 매우 크지만, 실제 쓰기 버퍼링을 위한 효과는 거의 못 보는 상태이다.
 
ex) 버퍼 풀은 100메가, 리두 로그 파일은 100기가
- 위의 경우와 다르게 전체 더티 페이지는 최대 400기가 정도 가질 수 있게 된다. 하지만, 버퍼 풀의 크기가 100메가니까 허용 가능한 더티 페이지는 100메가 정도이다. 이 경우에는 버퍼 풀이 필요할 때 너무 많은 dirty 페이지를 한 번에 기록해야 될 수도 있어서 좋지는 않다. 
= 리두 로그 파일은 매우 크지만, 버퍼 풀이 필요할 때 더티 페이지를 갑자기 엄청 써야 하는 일이 생길 수 있어서 부하가 생길 수도 있다.
 
두 예제 모두 상당히 극단적이다.
만약 버퍼 풀의 크기가 100기가 이하라면 대략 5~10기가 정도로만 선택하자.
 
 

💬 Redo Log 동작 순서

1. 버퍼 풀에서 데이터가 변경되면 해당되는 페이지를 수정한 다음 Dirty 마킹 진행
2. 관련된 리두 로그 레코드를 Double Write Buffer에 저장
3. 리두 로그 레코드를 Log Buffer로 이동 
4. 리두 로그 레코드를 Redo Log File로 플러시
5. 변경된 Dirty 페이지에 대해 체크포인트를 수행하여 System tablespace에 저장

- 중요한 점은 바로 디스크 영역인 System tablespace에 저장하는 게 아니라 Log Buffer에 들어가고, 한 번에 모아서 Redo Log File로 플러시한다는 게 중요하다.
 
 

💬 Redo Log 파일의 전체 크기

리두 로그 파일의 전체 크기는 버퍼 풀의 효율성을 결정할만큼 중요하다.
innodb_log_file_size 변수를 통해 리두 로그 파일의 크기를, innodb_log_files_in_group을 통해 리두 로그 파일의 개수를 설정할 수 있어, 결과적으로 두 값을 곱한 값이 로그 파일의 전체 크기가 된다. 로그 버퍼의 크기는 기본값이 16MB이며, 만약 큰 데이터를 자주 변경한다면 더 크게 설정하는 것이 좋다.
 
 

💬 Redo Log 아카이빙

리두 로그의 경우 중요한 만큼, 로그를 계속 추적하면서 새로 추가된 리두 로그 엔트리를 복사하는 기능이 추가되었다. (MySQL 8.0 엔터프라이즈 버전) 이때, 데이터 변경이 많아서 리두 로그 내용이 복사되기도 전에 덮어씌워지더라도 리두 로그 아카이빙을 활용하면 백업이 실패하지 않게 된다. (innodb_redo_log_archive_start, nnodb_redo_log_archive_stop)
 
기본적으로 리두 로그는 항상 활성화되어 있는데, MySQL 8.0부터는 비활성화하도록 만들 수도 있다.
대용량 데이터를 복구하거나 한 번에 적재하는 경우에는 비활성화하여 적재 시간을 낮출 수 있다.

# 비활성화
ALTER INSTANCE DISABLE INNODB REDO_LOG

# 활성화
ALTER INSTANCE ENABLE INNODB REDO_LOG

물론, 비활성 후 데이터 적재 작업을 진행했다면 꼭 다시 활성화를 해줘야 한다. (비정상 종료에 늘 대비하기)
 

---

 
내용이 많아서 어지럽다...
나중에 다시 정리해봐야겠다 ㅎㅎ;