데이터베이스 인터널스라는 책을 읽으면서 MySQL 리두 로그를 다시 공부하게 되었는데, Redo Log 파일 관리 방식이 MySQL 8.0.3 이후로 변경되어 해당 부분을 정리해봤습니다.

8.0.30 이전 Redo Log

MySQL 8.0 이전 버전에서는 위 그림과 같이 InnoDB redo Log 파일이 기본적으로 2개로 관리되었습니다. 또한 Redo Log 파일의 수와 크기를 조정하기 위해서는 innodb_log_file_size, innodb_log_files_in_group를 수정해야 했으며, 수정한 뒤 MySQL 서버를 재시작해야 했습니다.

그래서 개발자들은 Redo Log 파일의 사이즈는 어떻게 해야할까?라는 고민을 해야했습니다.
왜냐하면, Redo Log의 경우 MySQL 서버에 크래시(crash)가 발생할 경우 시스템을 복구하는데 사용되어, Redo Log 파일 크기에 따라 복구 시간이 달라졌기 때문입니다.

하지만 MySQL 8.0.30 버전에 추가된 Dynamic InnoDB Redo Log를 통해서 Redo Log의 크기, 수를 직접 지정할 필요가 없어졌으며, Redo Log의 설정이 변경되더라도 MySQL 서버를 재시작할 필요가 없이 동적으로 반영되게 변경됐습니다.

8.0.30 이후 Redo Log

Redo Log 사이즈(innodb_redo_log_capacity)

새로운 Redo Log 아키텍처의 경우 innodb_redo_log_capacity 단일 변수를 통해 Redo Log를 관리할 수 있습니다. 기본값은 100MB이며, 최대 512GB로 지정할 수 있습니다.

innodb_redo_log_capacity 값을 다음 쿼리를 통해 변경할 수 있습니다.

mysql> set global innodb_redo_log_capacity=200*1024*1024;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'innodb_redo_log_capacity%';
+--------------------------+-----------+
| Variable_name            | Value     |
+--------------------------+-----------+
| innodb_redo_log_capacity | 209715200 |
+--------------------------+-----------+
1 row in set (0.00 sec)

innodb_redo_log_capacity 변수의 값이 정의되면 기존 innodb_log_file_size, innodb_log_files_in_group의 값을 대체합니다.

만약 innodb_redo_log_capacity 변수의 값이 정의되어 있지 않지만, innodb_log_file_size, innodb_log_files_in_group는 정의되어 있다면, 다음 공식을 통해 innodb_redo_log_capacity의 값을 결정합니다.

innodb_redo_log_capacity = innodb_log_file_size * innodb_log_files_in_group

반면 모든 변수가 정의되지 않았다면, innodb_redo_log_capacity의 기본값 100MB를 적용합니다.(하지만 직접 innodb_redo_log_capacity의 값을 정의하지 않습니다)

파일 관리

새로운 Redo Log 아키텍처는 새로운 전용 디렉토리(#innodb_redo)에 32개의 redo 로그 파일을 생성합니다. 각 파일은 앞선 innodb_redo_log_capacity을 32로 나눈 값으로 정의됩니다.

해당 디렉토리 내에는 다음과 같은 파일들을 확인할 수 있습니다.

• #ib_redoXXX: 활성 파일로 실제 로그 기록에 사용되는 파일
• #ib_redoXXX_tmp: 예비 파일로 필요 시 활성 파일로 전환되는 스페어 파일

위 파일들이 어떻게 활용되는지 설명하면 다음과 같습니다.(총 32개의 파일에 대한 이미지 입니다.)

• checkpoint_lsn(Innodb_redo_log_checkpoint_lsn): 페이지들이 체크포인트를 통해 디스크에 모두 반영된 지점입니다.
• current_lsn(Innodb_redo_log_current_lsn): 가장 최근에 저장된 로그 위치입니다. 해당 데이터는 메모리에 버퍼링되어 디스크에 반영되지 않았을 수 있습니다.
• flushed_to_disk_lsn(Innodb_redo_log_flushed_to_disk_lsn): 로그 파일이 디스크로 플러시된 마지막 지점입니다.

만약 총 innodb_redo_log_capacity 용량에 대해 90%(약 31개 파일 사용)를 사용중이라면, 더 이상 사용하지 않는 활성 파일(체크포인트 이전 파일)을 식별하며 해당 파일들을 예비 파일로 비활성화 시킵니다.

만일 활성 파일을 정리하는 과정에서 지연이 발생하면 트랜잭션 처리에도 지연이 발생하게 됩니다. 이런 경우 innodb_redo_log_capacity의 크기를 늘리는 것을 고려해봐야 합니다.

요약

Redo Log 아키텍처 변화에 따른 이점을 다음과 같이 정리할 수 있습니다.

• 재시작 없이 Redo Log 파일 설정 변경 가능
  • 기존 innodb_log_file_size, innodb_log_files_in_group 변경 시 서버 재시작을 해야했지만, innodb_redo_log_capacity을 변경하면 서버 재시작 없이 동적으로 변경할 수 있게 됐음
• I/O 병목 완화
  • 기존에는 하나의 파일에 집중된 I/O가 여러(32개) 파일로 분산되어 대용량 트랜잭션 처리나 서버 복구 시 부하가 줄어들었음

ref
https://dev.mysql.com/blog-archive/dynamic-innodb-redo-log-in-mysql-80/
https://hoing.io/archives/5820