MySQL 버전 별 Innodb Architecture

이번 글에서는 MySQL 의 Innodb 엔진 아키텍처가 버전에 따라 어떻게 달라졌는지 간단히 살펴보겠습니다.

data dictionary , 정합성을 위한 doublewrite buffer, dml 성능을 위한 change buffer, mvcc를 위한 undo log, innodb_file_per_table이 off면 시스템테이블스페이스에 table이 저장되는 구조
- ibdata 파일이 커지기 굉장히 쉬운 환경
- 특히 undo log가 커졌을 때 DB상에서 트랜잭션이 종료되어도 OS의 파일 사이즈는 자동으로 반환되지 않기 때문에 장애위험성이 있음

MySQL 5.5 => 5.6 으로 올라오면서 undo log를 System tablespace (ibdata) 에서 별도로 둘 수 있게됨
커진 undo log truncate 기능 (set global innodb_undo_log_truncate = ON)
- innodb_max_undo_log_size 보다 커지면 truncate 수행
- innodb_undo_tablespaces > 1 이상 설정하여 system tablespace에 undo 없도록 설정 필요
- 001번 언두테이블스페이스가 너무 커지게되면, 002번을 사용하도록 변경하고 001번을 드랍하는 식으로 불필요하게 점유하는 디스크를 반환할 수 있음
MySQL 5.7 부터 temp table이 MyISAM이 아닌 InnoDB로 생성됨
- 5.6에서는 루트영역의 tmp 쪽에 템프파일을 만들고 , 작업 완료되면 지우고 이런식으로 동작했음
- 5.7부터는 innodb_temp_data_file_path라는 파라미터와 함께 autoextend랑 파일 맥스사이즈를 지정하면서 설정할 수 있게되어 ibtmp파일을 계속 사용할 수 있음
general tablespace의 활용 => 특정 테이블을 고속의 스토리지에 배치
- MySQL은 datadir이 꽉차면 동작을 못하는데 general tablespace를 통해 데이터파일의 분산 효과도 누릴 수 있음

create tablespace ts1 add datafile '/home1/test1/tab1.ibd' ;
create table tab1 tablespace tab1;

기존엔 undo tablespace 의 위치가 system tablespace (ibdata)에 있거나 밖으로 꺼내거나 선택적인 사항이었으나 8.0 으로 올라오면서 필수로 system tablespace 밖에 생성됨
5.7 까지는 data dictionary 가 system tablespace(ibdata)과 테이블명.frm 파일로 저장이 되었으나
8.0으로 올라오면서 innodb 스토리지 엔진을 사용하는 별도의 data dictionary table(mysql.ibd)에 저장됨 => frm 파일 읽으면서 생기는 I/O 병목, non-transaction ddl 문제 해결
temp tablespace 를 global / session 영역 별로 나눠서 사용함
- global 영역은 ibtmp, session 영역은 #innodb_temp를 사용
- 8.0 미만에서는 ibtmp파일이 커지면 재기동을 해서 디스크를 반환해야했는데 #innodb_temp의 등장으로 쿼리의 임시테이블은 #innodb_temp를 사용하게됨
- #innodb_temp는 세션이 종료되면 자동으로 디스크가 반환되는 장점이 있음
- ibtmp영역은 index생성할때 사용됨
internal temptable space engine도 memory -> temptable로 변경됨
- temptable 엔진은 임시테이블에도 가변길이를 제공하기 때문에 템프영역을 효율적으로 사용하기에도 좋고
  템프메모리보다 더 많이 사용할때 바로 디스크로 떨구는게 아니라 mmap 자료구조를 한번 더 쓸 수 있도록 한 장점이 있음

MySQL 버전 별 Innodb Architecture#