DB 인사이드 | MySQL Architecture - 7. InnoDB : On-Disk Structure

 

 

본 문서에서는 MySQL에 주요 스토리지 엔진인 InnoDB의 On-Disk Structure에 대해 알아보도록 하겠습니다. InnoDB의 디스크 구조 관련 항목은 아래와 같으며, InnoDB는 모든 Data를 디스크 상의 Tablespace라는 논리적인 공간에 저장합니다.

• Tablespace
• Table
• Index
• Doublewrite Buffer
• Redo Log
• Undo Log

 

Tablespace

Tablespace는 Data를 저장하는 데 사용되는 가장 큰 논리적 단위이며, 내부적으로 Segment → Extent → Page → Row의 형태로 구성됩니다.

MySQL의 Tablespace는 저장하는 데이터의 종류와 방식에 따라 5가지로 분류가 가능한데, 각각의 Tablespace에 대해 알아보도록 하겠습니다.

 

Tablespace	File
System Tablespace	ibdata1
File-Per-Table Tablespace	table_name.ibd
General Tablespace	tablespace_name.ibd
Temporary Tablespace	ibtmp1, temp_1.ibt
Undo Tablespace	undo_001, undo_002

 

System Tablespace

System Tablespace는 MySQL에서 기본적으로 사용되는 Shared Tablespace입니다. Change Buffer 저장 영역이며, System Tablespace에서 테이블을 생성하는 경우에는 테이블 및 인덱스 Data 역시 저장 가능합니다.

📢 이전 MySQL 버전에서는 System Tablespace에 InnoDB Data Dictionary(스토리지 엔진 별 Data Dictionary)가 포함되어 있었습니다. MySQL 8.0에서는 데이터베이스 Object에 대한 정보를 저장하는 Transactional Data Dictionary를 통합하여 Metadata를 모두 MySQL Data Dictionary에 파일이 아닌 테이블로 저장합니다. 이후 언급할 Doublewrite Buffer의 경우 이전 버전에는 System Tablespace에 있었지만, MySQL 8.0 20부터 별도의 파일로 분리되었습니다.

System Tablespace는 하나 이상의 Data 파일을 가질 수 있으며, 기본적으로 ibdata1라는 System Tablespace의 Data 파일이 MySQL data 디렉토리에 생성됩니다. System Tablespace의 Data 파일의 크기와 수는 innodb_data_file_path라는 System Variable로 설정할 수 있습니다.

 

File-Per-Table Tablespace

File-Per-Table Tablespace는 하나의 InnoDB 테이블에 대한 Data와 인덱스를 개별 파일로 관리하는 Tablespace를 이야기합니다.

일반적으로 InnoDB는 File-Per-Table Tablespace에 테이블을 생성합니다. 별도의 Tablespace 생성과정은 없으며, innodb_file_per_table의 값이 ON이면 File-Per-Table Tablespace로 Table이 생성됩니다. 이때, Data File은 tablename.ibd형식으로 생성됩니다.

innodb_file_per_table System Variable을 비활성화하면 테이블은 System Tablespace에 생성됩니다.

장점

• 테이블을 Truncate 또는 Drop 시 디스크 공간이 OS로 반환됩니다.
• File-Per-Table Tablespace의 Data 파일은 I/O 최적화, 공간 관리 또는 백업을 목적으로 별도의 저장 장치에 생성할 수 있습니다.
• 다른 MySQL 인스턴스에서 File-Per-Table Tablespace에 있는 테이블을 가져올 수 있습니다.
• innodb_flush_method 설정이 O_DIRECT일때, File-Per-Table Tablespace를 사용하면 성능이 향상될 수 있습니다. (다른 Tablespace는 여러 테이블이 존재하기 때문에 단일 파일에 대한 동시 쓰기가 허용되지 않습니다.)
• File-Per-Table Tablespace는 개별 테이블의 크기를 늘릴 수 있는 충분한 공간을 할당할 수 있습니다. (Shared Tablespace의 경우에는 64TB 크기 제한이 있으므로 테이블의 크기도 제한됩니다.)

단점

• 동일한 테이블의 Row에 대해서만 사용할 수 있는 공간이 존재하기 때문에, 사용되지 않는 공간에 대한 낭비로 이어질 수 있습니다.
• fsync 작업은 파일 단위로 이루어집니다. File-Per-Table Tablespace를 사용하는 경우, 여러 테이블에 대한 쓰기 작업은 테이블 수만큼 Data 파일에서 수행하기 때문에 그만큼 fsync 작업이 늘어납니다.
• mysqld는 File-Per-Table Tablespace에 대해 Open File Handle을 유지해야 하므로 여러 테이블이 File-Per-Table Tablespace에 있을 경우 성능에 영향을 미칠 수 있습니다.

📢 Open File Handle란 사용자가 open을 요청한 파일에 운영체제가 할당하는 임시 참조 번호를 의미합니다. 시스템은 사용자가 파일 또는 시스템 세션을 종료할 때까지 세션 전체에서 해당 참조 번호를 통해 파일을 호출하고 Access 하며 상호작용합니다.

• File-Per-Table Tablespace의 테이블을 삭제할 때는 Buffer Pool을 잠금 후 스캔하기 때문에 Buffer Pool이 큰 경우에는 시간이 더 소요되어 다른 작업이 지연될 수 있습니다.

 

General Tablespace

General Tablespace는 CREATE TABLESPACE 구문을 사용하여 만들 수 있습니다. General Tablespace는 System Tablespace와 마찬가지로 Shared Tablespace이기 때문에 여러 테이블 Data를 저장할 수 있습니다.

제약 사항

• 기존의 다른 타입의 Tablespace를 General Tablespace로 변경할 수 없습니다.
• Temporary General Tablespace의 생성은 지원되지 않고, General Tablespace는 Temporary Table을 지원하지 않습니다.
• Truncate 또는 Drop 사용 시 Data 파일에 빈 공간이 생깁니다. 이 공간은 운영체제에 반환된 것이 아니며, InnoDB의 새로운 Data에만 사용할 수 있습니다.
• MySQL 5.7.24에서부터 General Tablespace는 파티션 테이블에 대한 지원을 하지 않습니다.

 

Temporary Tablespace

Temporary Tablespace의 경우 MySQL 버전에 따른 변화가 많았습니다. 5.7 버전에 처음으로 소개된 Temporary Tablespace는 8.0 버전에서는 Session Temporary Tablespace와 Global Temporary Tablespace로 분리되었습니다.

Session Temporary Tablespace

Session Temporary Tablesapce에는 사용자가 생성한 Temp Table 및 Optimizer가 내부적으로 생성하는 Temp Table (Internal Temporary Table)의 내용을 저장합니다.

💡 Temporary Table을 Temp Table로 줄여서 작성하였습니다.

📢 MySQL 8.0.16부터 On-Disk Internal Temp Table에 사용되는 스토리지 엔진은 항상 InnoDB입니다. 이전 버전까지는 internal_tmp_disk_storage_engine라는 System Variable로 설정하였습니다.

디스크에 Temp Table을 생성할 필요가 있을 경우, Temporary Tablespace Pool에서 Session에 할당하며, 이때 Session에 할당 가능한 최대 Tablespace 공간은 사용자가 만든 Temp Table과 Optimizer에 의해 만들어진 Internal Temp Table, 최대 2개입니다.

Session Temprary Tablespace는 innodb_temp_tablespaces_dir에 설정한 경로에 .ibt 형식으로 파일이 생성됩니다. Session에 할당된 Temporary Tablespace공간은 Connection 종료 시 Temporary Tablespace에서 Truncate 되어 Tablespace Pool로 반환됩니다. (Temporary Tablespace Pool은 정상 종료 또는 중단으로 인한 초기화 시 제거되고 Server 시작 시 다시 생성됩니다.)

Global Temporary Tablespace

사용자가 생성한 Temp Table의 변경사항에 대한 Rollback Segment를 저장합니다. Global Temporary Tablespace의 Data 파일의 상대 경로, 이름, 크기 및 속성 등은 innodb_temp_data_file_path System Variable을 통해 정의하며, 값을 지정하지 않은 경우에는 innodb_data_home_dir 디렉토리에 ibtmp1이라는 하나의 Data 파일(auto extend)로 생성합니다.

Global Temporary Tablespace는 정상 종료 또는 중단으로 인한 초기화 시 제거되며 Server가 시작될 때마다 다시 생성됩니다.

📢 MySQL 5.7 버전에서 사용되던 ibtmp1 파일의 경우 Session Temporary Tablespace의 역할을 같이 수행하였지만, 8.0부터는 이름과 달리, Temp Table의 Undo Log를 저장하는 Global Temporary Tablespace용 파일로 사용됩니다.

 

Undo Tablespace

Undo Tablespace는 Clustered Index에 대한 Undo Log(최신 변경사항을 실행 취소하기 위한 정보)가 포함되어 있습니다.

Undo Tablespace는 하나 이상의 Undo Log 파일로 구성됩니다. MySQL 5.7 이전에는 Undo가 System Tablespace에 존재하였지만, 5.7 이후 System Tablespace로부터 분리되었습니다.

인스턴스 초기화 시, 두 개의 Default Undo Tablespace가 생성되며, innodb_undo_directory System Variable에 정의된 위치에 파일이 생성됩니다. (정의되지 않은 경우 MySQL data 디렉토리에 생성됩니다.)

MySQL 8.0.14부터 운영 중에 SQL을 사용하여 Undo Tablespace를 추가로 생성할 수 있습니다.

 

Table

InnoDB 테이블과 인덱스는 System Tablespace, File-Per-Table Tablespace 또는 General Tablespace 안에 생성할 수 있습니다. InnoDB 테이블은 기본적으로 File-Per-Table Tablespace에 생성됩니다. InnoDB 테이블을 System Tablespace에 생성하기 위해서는 innodb_file_per_table 값을 비활성화하면 되며, CREATE TABLE ~ TABLESPACE ~명령어를 사용하면 General Tablespace에 테이블을 생성할 수 있습니다.

CREATE TABLE table_name ... TABLESPACE [=] tablespace_name

테이블을 File-Per-Table Tablespace에 생성할 경우 MySQL은 Database 디렉토리에 table_name.ibd 라는 개별 파일을 만들어 저장하고, System Tablespace를 사용하는 경우에는 기존 ibdata 파일에 저장됩니다.

InnoDB는 모든 테이블을 Primary Key(PK)를 기준으로 정렬하여 저장합니다.

테이블의 Data가 PK 값으로 정렬되어 저장되므로, Secondary Index들은 실제 Data의 주소 대신 PK 값을 논리적인 주소로 사용합니다. 이러한 Clustered Index를 통해 Range 스캔 성능을 빠르게 처리할 수 있습니다.

테이블 생성 시 PK를 정의하지 않아도 되지만, PK는 성능과 밀접한 연관이 있기 때문에 특히, 크거나 자주 사용되는 테이블에 대해서는 생성 시점에 PK를 정의하는 게 좋습니다.

📢 Oracle DBMS의 IOT(Index Organized Table)와 동일한 구조가 MySQL의 InnoDB에서는 일반적인 테이블 구조입니다.

 

Index

MySQL 인덱스의 대부분은 B-Tree 형태를 사용합니다. 예외로 지리적 공간 값을 나타내는 Data 유형(공간 Data)은 R-Tree를 사용하고, InnoDB의 Full-Text Index는 텍스트 기반의 컬럼들을 기반으로 생성하며 Inverted Index Design을 가집니다. (단어의 리스트와 각 단어들이 나타나는 문서의 리스트를 저장합니다.)

Clustered Index(=Primary Key)

InnoDB 테이블에는 Clustered Index라는 특별한 인덱스가 반드시 존재합니다. Clustered Index는 Primary Key(PK) 값을 이용하여 Data를 정렬하여 저장합니다. Clustered Index는 일반적인 B-Tree 구조이며 Leaf Node에는 모든 컬럼이 같이 저장되어 있습니다.

Clustered Index란 사실 특정 Index Type이 아닌 저장 구조에 가깝습니다. 즉, Primary Key를 기준으로 정렬된 B-Tree 인덱스와 동일 값으로 정렬된 실제 데이터를 통칭하기 때문입니다. 그렇기 때문에 Clustered Index를 통해 Access 하면 바로 Row가 포함된 Page로 직접 이어져 빠른 속도로 처리가 가능합니다.

• 테이블 생성 시 PK를 정의하면 InnoDB는 PK로 Clustered Index를 사용합니다.
• PK로 사용할 만한 Unique 하고 Not Null인 컬럼, 혹은 컬럼의 Set가 없다면 자동 증가 컬럼을 추가하는 식으로 Clustered Index를 구성합니다.
• 테이블에 PK가 없고 적절한 Unique Index도 없는 경우에는 Row ID 값을 포함하여 만든 컬럼으로 Hidden Clustered Index를 생성하여 사용합니다.

Secondary Index

앞서 설명한 Clustered Index 이외에 사용자가 추가한 모든 인덱스를 Secondary Index라고 부릅니다. 여타 DBMS의 경우 Index를 생성하면 Leaf Node에 대상 테이블 Block의 물리 주소를 저장하고 있어 이를 통해 Data를 가져옵니다. 하지만 MySQL의 경우 주소 값 대신 PK를 저장하고 있으므로 해당 PK를 이용해 다시 한번 Clustered Index를 검색하여 원하는 Data에 접근합니다. (즉, Secondary Index → Primary Key Value → Data로 순으로 찾습니다.)

Secondary Index의 경우 지정된 컬럼과 함께 PK값을 함께 저장하기 때문에 주의해야 할 사항이 있습니다. 다양한 컬럼의 조합으로 PK를 구성한 경우 Secondary Index의 사이즈가 증가할 수 있으므로, 다양한 Secondary Index를 구성하는 경우 PK 선택에 주의를 기울여야 합니다.

 

Doublewrite Buffer

InnoDB는 Data 손실을 방지하기 위해 Doublewirte라는 파일 Flush 기능을 사용합니다. Doublewirte Buffer는 Buffer Pool로부터 Flush 된 Page를 Data 파일에 쓰기 전에 저장하는 영역으로, 버퍼라는 명칭을 쓰지만 실제 디스크상에 파일 형태로 존재합니다.

1. Buffer Pool의 Dirty Page가 Flush 됩니다.
2. 여러 Dirty Page가 한 번에 Doublewrite Buffer에 Write 합니다.
3. Doublewrite Buffer에 쓰인 Dirty Page들을 하나씩 순차적으로 Buffer Pool에서 Data 파일에 Write 합니다.

⚡ Buffer Pool에서 Data 파일로 Page를 쓰는 도중에 mysqld 프로세스의 중지 또는 운영체제, 스토리지 시스템 등의 문제가 발생하면 Doublewrite Buffer로부터 페이지의 복사본을 찾아 복구를 수행할 수 있습니다.

📢 MySQL 8.0.20 이전 버전에서는 Doublewrite Buffer 저장영역이 System Tablespace안에 존재했지만, 이후 버전부터는 Doublewrite File에 존재합니다.

 

Redo Log

Redo Log는 Crash Recovery 수행 시 완료되지 않은 트랜잭션에 의해 변경된 Data를 적용하기 위해 사용됩니다. 메모리 상의 Log Buffer 혹은 디스크 상의 Redo Log File이 Redo Log에 해당됩니다.

MySQL은 모든 InnoDB의 변경 내용을 바로 디스크 영역에 저장하지 않고 메모리 영역(Buffer Pool)에 저장하기 때문에 인스턴스 장애로 인해 변경 Data가 디스크 영역(Data 파일)에 적용되지 않았으면, Database 재시작 중에 Redo 작업을 수행합니다.

📢 WAL 원칙에 따라 Redo Log는 Buffer Pool의 Data보다 먼저 기록됩니다.

Redo Log는 기본적으로 아래와 같은 2개의 파일을 순환 구조로 사용합니다.

• ib_logfile0
• ib_logfile1

Redo Log File은 순환방식이므로 기존 Data는 덮어 쓰이면서 없어집니다. Redo Log를 통한 Data 전달은 계속 증가하는 LSN 값으로 표시됩니다.

📢 LSN(Log Sequence Number)이란 임의의 계속 증가하는 값으로, Redo Log에 기록된 작업에 해당하는 시점을 가리킵니다. Crash Recovery와 Buffer Pool 관리를 위해 내부적으로 사용됩니다.

• InnoDB는 트랜잭션이 Commit 되기 전에 트랜잭션의 Redo Log를 디스크로 Flush 합니다. InnoDB는 Group Commit을 사용하여 Commit시마다 Flush가 수행되는 것을 피하며, 여러 개의 Flush를 그룹화하며 한 번에 수행합니다. 이는 동시에 Commit 하는 여러 트랜잭션에 대한 처리량을 크게 향상할 수 있습니다.
• Redo Log 레코드를 복사하는 백업 유틸리티가 때로는 Redo Log의 생성 속도를 따라가지 못해, 순환되어 사용되는 Redo Log 레코드의 손실을 야기할 수 있습니다. MySQL 8.0.17에서 Redo Log Archiving 기능이 도입되면서 Redo Log File 외에도 Archive File에 Redo Log 레코드를 순차적으로 기록하기 때문에 이 문제를 피해 갈 수 있습니다. innodb_redo_log_archive_dirs System Variable을 통해 Redo Log Archiving 사용 여부를 설정할 수 있습니다.
• MySQL 8.0.21부터는 특정 상황에서 Redo Logging 기능을 비활성화할 수 있습니다. 새로운 MySQL 인스턴스 구축을 위해 대량의 Data를 로드할 때 Redo Log Write 및 Doublewrite Buffering을 중지하여 Data 로드 속도를 높이기 위해서 사용 가능합니다. Redo Logging이 비활성화된 상태로 Server를 운영할 수 있지만, 예기치 않게 Server가 중지될 경우 Data 손실 및 인스턴스 손상이 발생할 수 있기 때문에 운영시스템에서는 해당 기능을 사용하지 말아야 합니다.

 

Undo Log

Undo Log란 단일 트랜잭션과 관련된 레코드의 모음입니다. Undo Log는 트랜잭션의 가장 최근의 변경 사항의 이전(변경 전) Data에 대한 정보를 가지고 있습니다. 변경 전 Data(원본)를 읽기를 원하는 다른 트랜잭션이 있다면 Undo Log에서 변경 전 Data를 읽을 수 있습니다.

Undo Log는 Rollback Segment 내에 포함된 Undo Log Segment에 존재합니다. Rollback Segment는 Undo Tablesapce 혹은 Global Temporary Tablespace 안에 포함되어 있습니다. Undo 관련 Data File은 8.0 이전에는 System Tablespace에 존재하였지만 이후엔 별도의 파일로 분리되었습니다.

일반 테이블에 대한 트랜잭션은 Undo Tablespace, 임시 테이블에 대한 작업을 수행하는 트랜잭션은 Global Temporary Tablespace에 Undo Log가 할당됩니다. Global Temporary Tablespace에 있는 Undo Log는 임시 테이블의 Data를 변경하는 트랜잭션에서 사용되므로 Server가 운영 중일 때 Rollback을 위해서만 사용됩니다. (임시 테이블이기 때문에 Crach Recovery는 불필요하므로 Redo Logging이 되지 않습니다.)

 

Undo Log는 다음과 같이 대상 및 DML 유형별로 최대 4개만큼 트랜잭션 별로 할당됩니다.

• 사용자 정의 테이블에 대한 INSERT 작업
• 사용자 정의 테이블에 대한 UPDATE, DELETE 작업
• 사용자 정의 임시 테이블에 대한 INSERT 작업
• 사용자 정의 임시 테이블에 대한 UPDATE, DELETE 작업

예를 들어 일반 테이블 및 임시 테이블에 각각 Insert, Update, Delete작업을 수행하는 트랜잭션이 있다면 Undo Log를 최대 4개 할당해야 하며, 일반 테이블에 Insert 작업만 수행하는 트랜잭션의 경우 1개의 Undo Log가 할당됩니다.

트랜잭션에 할당된 Undo Log는 트랜잭션이 완료될 때까지 Connection 상태를 유지합니다. 예를 들어, 일반 테이블의 Insert 작업에 할당된 Undo Log는 해당 트랜잭션이 수행하는 모든 일반 테이블의 Insert 작업에서 사용됩니다.

 

System Variable

Parameter	Default Value	Range	Description
innodb_file_per_table	ON	ON, OFF	• innodb_file_per_table 사용여부를 결정하는 System Variable입니다. • ON이면 기본적으로 테이블이 File-Per-Table Tablespace에 생성되며, OFF인 경우에는 System Tablespace에 생성됩니다.
innodb_flush_method	(unix) fsync, (windows) unbuffered	(unix) fsync, O_DSYNC, littlesync, nosync, O_DIRECT, O_DIRECT_NO_FSYNC (windows) unbuffered, normal	UNIX • I/O 처리량에 영향을 줄 수 있는 Data 파일 및 로그 파일로 Data를 Flush하는데 사용되는 방법을 정의합니다. • fsync 또는 0 : fsync() System Call을 사용하여 Data와 로그 파일을 모두 Flush합니다. • O_DSYNC 또는 1 : O_SYNC를 사용하여 로그 파일을 열고 Flush하며, fsync()를 사용하여 Data 파일을 Flush합니다. InnoDB는 O_DSYNC를 직접 사용하지는 않습니다. • littlesync 또는 2 : 내부 성능 테스트에 사용되며 현재 지원되지 않는 옵션입니다. 사용 시 리스크가 있습니다. • nosync 또는 3 : 내부 성능 테스트에 사용되며 현재 지원되지 않는 옵션입니다. 사용 시 리스크가 있습니다. • O_DIRECT 또는 4 : O_DIRECT를 사용하여 Data 파일을 열고 fsync()를 사용하여 Data와 로그 파일을 모두 Flush합니다. • O_DIRECT_NO_FSYNC : 입출력을 Flush 하는 동안 O_DIRECT를 사용하지만, 각 Write 작업 후에는 fsync() System Call을 건너뜁니다. WINDOWS • unbuffered 또는 0 : 시뮬레이션된 비동기 I/O 및 버퍼되지 않은 I/O를 사용합니다. • normal 또는 1 : 시뮬레이션된 비동기 I/O 및 버퍼링된 I/O를 사용합니다.
innodb_undo_directory	NULL		• Undo Tablespace를 생성하는 Path입니다. • 일반적으로 다른 저장 장치에 Undo Tablespace를 배치하는데 사용됩니다. 이 System Variable이 정의되지 않은 경우, data Directory에 Undo Tablespace가 생성됩니다.
internal_tmp_disk_storage_engine	INNODB	MYISAM, INNODB	• On-Disk internal Temporary Table에 사용되는 스토리지 엔진을 결정합니다. • MySQL 8.0.16 이상에서 On-Disk internal Temporary Table은 항상 InnoDB 스토리지 엔진을 사용하며, MySQL 8.0.16부터 이 System Variable이 제거되어 더 이상 지원되지 않습니다.
innodb_temp_tablespaces_dir	#innodb_temp		InnoDB 시작 시 Session Temporary Tablespace Pool을 생성하는 위치를 정의합니다.
innodb_temp_data_file_path	ibtmp1:12M:autoextend		• Global Temporary Tablespace Data 파일의 상대 경로, 이름, 크기 및 속성을 정의합니다. • 이 값이 지정되지 않으면 ibtmp1이라는 하나의 자동 확장 Data 파일을 innodb_data_home_dir 디렉토리에 생성합니다. • Global Temporary Tablesace Data 파일은 다른 Data 파일과 같은 이름으로 지정할 수 없습니다.
innodb_data_home_dir	MySQL datadir		• InnoDB System Tablespace Data 파일에 대한 디렉토리 경로의 공통 부분을 의미합니다. • 이 값이 절대 경로로 정의되지 않은 경우에는 innodb_data_file_path 설정과 연결됩니다.
innodb_doublewrite	ON	ON, OFF	Doublewrite Buffer의 사용 여부를 제어합니다.
innodb_doublewrite_dir	MySQL datadir		Doublewrite File을 생성하는 위치입니다.
innodb_doublewrite_files	innodb_buffer_pool_instances * 2	2 ~ 256	• Doublewrite File 개수를 정의합니다. • 기본적으로 각 Buffer Pool 인스턴스에 대하여 2개의 Doublewrite File이 생성됩니다. (Flush List, LRU List) • Doublewrite File의 최대 수는 Buffer Pool 인스턴스 수의 2배입니다. (Buffer Pool 인스턴스 수는 innodb_buffer_pool_instances 라는 System Variable에 의해 제어됩니다.)
innodb_doublewrite_pages	innodb_write_io_threads	innodb_write_io_threads ~ 512	• Thread 당 제어할 수 있는 최대 Doublewrite Page 수입니다. • 값을 지정하지 않으면 innodb_writer_io_threads 값으로 설정됩니다.
innodb_doublewrite_batch_size	0	0 ~ 256	일괄적으로 Write할 Doublewrite Page 수를 제어하며, 고급 성능 튜닝에 사용됩니다.
innodb_log_file_size	50331648(48MB)	4194304 - 512GB	• 로그 그룹에 있는 각 로그 파일의 크기입니다. • 값이 클수록 Buffer Pool에 필요한 Checkpoint Flush가 적어 디스크 I/O가 절약됩니다.(그러나 Crash Recovery는 느려질 수 있습니다.)
innodb_log_files_in_group	2	2 ~ 100	• 로그 그룹의 로그 파일 수입니다. • 순환 방식으로 파일에 기록합니다.
innodb_log_group_home_dir	MySQL datadir		InnoDB Redo Log 파일의 디렉토리 경로입니다. • 로그 파일의 번호는 innodb_log_files_in_group으로 지정됩니다.
innodb_redo_log_archive_dirs	NULL		• Redo Log Archive 파일을 만들 수 있도록 Label을 지정한 디렉토리를 정의합니다. • Label을 지정한 디렉토리를 세미콜론으로 구분하여 여러 개 정의할 수 있으며, 디렉토리가 존재해야하고 경로를 지정해야 합니다.

 

 

 

 

기획 및 글 | 기술기획팀

이미지 제작 | 디자인그룹 이민석