MySQL 데이터 디렉터리 구조: datadir, tablespace, redo, undo, binlog

MySQL 서버를 운영하다 보면 datadir은 단순히 데이터 파일이 모여 있는 디렉터리처럼 보인다. 그러나 실제로는 InnoDB의 영속성, crash recovery, 트랜잭션 롤백, 복제, 시점 복구가 모두 이 경로 주변에서 맞물려 동작한다. datadir 안의 파일을 잘못 이해하면 디스크 증설, 백업, 장애 복구, 로그 정리, 복제 지연 대응 같은 작업에서 치명적인 판단을 할 수 있다.

이 글은 MySQL 데이터 디렉터리의 주요 구성요소인 datadir, system tablespace, file-per-table tablespace, redo log, undo tablespace, binary log를 운영자가 어떤 관점으로 이해해야 하는지 정리한다. 파일 이름은 MySQL 버전과 설정에 따라 달라질 수 있으므로, 특정 파일명 암기보다 “어떤 계층의 책임을 맡는가”를 중심으로 보는 것이 중요하다.

1. datadir은 데이터베이스의 물리적 기준점이다

datadir은 MySQL 서버가 데이터베이스 객체와 내부 상태 파일을 저장하는 기본 디렉터리다. 설정은 보통 my.cnf 또는 mysqld 실행 옵션의 datadir 값으로 결정된다.

SHOW VARIABLES LIKE 'datadir';
SHOW VARIABLES LIKE 'innodb_data_home_dir';
SHOW VARIABLES LIKE 'innodb_log_group_home_dir';
SHOW VARIABLES LIKE 'log_bin_basename';

실행 결과(MySQL 8.0.46):

+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| datadir       | /var/lib/mysql/ |
+---------------+-----------------+
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| innodb_data_home_dir |       |
+----------------------+-------+
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| innodb_log_group_home_dir | ./    |
+---------------------------+-------+
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| log_bin_basename |       |
+------------------+-------+

일반적인 Community MySQL 설치에서는 datadir 아래에 다음 유형의 파일과 디렉터리가 존재한다.

구분	대표 예시	운영상 의미
스키마 디렉터리	`appdb/`, `mysql/`, `performance_schema/`	데이터베이스별 메타데이터와 테이블스페이스 파일의 위치
InnoDB tablespace	`ibdata1`, `*.ibd`	테이블/인덱스 페이지와 내부 데이터 저장
redo log	`#innodb_redo/`, `ib_logfile0` 등	crash recovery를 위한 물리 변경 이력
undo tablespace	`undo_001`, `undo_002` 등	rollback, consistent read를 위한 이전 버전 정보
binary log	`binlog.000001`, `mysql-bin.000001`	복제와 point-in-time recovery를 위한 논리 변경 이력
relay log	복제 replica의 `relay-log.*`	source에서 받은 binary log 이벤트 임시 저장
socket/PID/error log	설정에 따라 위치 상이	프로세스 제어와 진단 로그

운영자는 datadir을 “MySQL 전체를 복사하면 되는 폴더”로 단순화해서는 안 된다. 실행 중인 서버의 datadir을 파일 시스템 복사로 백업하면, redo/undo/tablespace 사이의 시점 일관성이 깨질 수 있다. 백업은 mysqldump, MySQL Shell dump, Percona XtraBackup, MySQL Enterprise Backup, 스토리지 스냅샷과 FLUSH TABLES WITH READ LOCK 또는 backup lock 조합처럼 일관성 조건을 만족하는 방식으로 수행해야 한다.

2. InnoDB tablespace의 책임: 페이지를 영속화하는 공간

InnoDB는 데이터를 페이지 단위로 관리한다. 일반적으로 페이지 크기는 innodb_page_size에 의해 정해지며 기본값은 16KB다. 테이블 레코드, secondary index, clustered index, undo 관련 구조, insert buffer/change buffer, 데이터 딕셔너리 일부는 모두 InnoDB가 관리하는 tablespace 안에 저장된다.

2.1 system tablespace와 `ibdata1`

전통적으로 ibdata1은 InnoDB system tablespace의 대표 파일이다. system tablespace는 다음과 같은 역할을 맡아 왔다.

InnoDB 내부 데이터 딕셔너리와 시스템 구조 저장
과거 기본 설정에서 사용자 테이블과 인덱스 페이지 저장
change buffer 등 일부 내부 구조 저장
일부 버전/설정에서 undo 정보 저장

현대 MySQL에서는 innodb_file_per_table=ON이 기본이고, 대부분의 사용자 테이블 데이터는 각 테이블의 .ibd 파일에 저장된다. 그래도 system tablespace는 사라지지 않는다. 서버 내부 구조와 호환성 때문에 여전히 핵심적인 파일이다.

운영상 중요한 점은 ibdata1이 자동으로 줄어들지 않는다는 것이다. 과거에 innodb_file_per_table=OFF 상태로 대량 데이터를 만들었다가 삭제해도 system tablespace 파일 크기는 쉽게 작아지지 않는다. 디스크를 회수하려면 논리 덤프 후 재구축 또는 새 인스턴스로 마이그레이션하는 방식이 필요할 수 있다.

SHOW VARIABLES LIKE 'innodb_file_per_table';
SHOW VARIABLES LIKE 'innodb_data_file_path';
SELECT FILE_NAME, FILE_TYPE, TABLESPACE_NAME, ENGINE, TOTAL_EXTENTS, EXTENT_SIZE
FROM INFORMATION_SCHEMA.FILES
WHERE ENGINE = 'InnoDB'
ORDER BY FILE_TYPE, FILE_NAME;

실행 결과(MySQL 8.0.46):

+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_file_per_table | ON    |
+-----------------------+-------+
+-----------------------+------------------------+
| Variable_name         | Value                  |
+-----------------------+------------------------+
| innodb_data_file_path | ibdata1:12M:autoextend |
+-----------------------+------------------------+
+----------------------+------------+------------------+--------+---------------+-------------+
| FILE_NAME            | FILE_TYPE  | TABLESPACE_NAME  | ENGINE | TOTAL_EXTENTS | EXTENT_SIZE |
+----------------------+------------+------------------+--------+---------------+-------------+
| ./ibdata1            | TABLESPACE | innodb_system    | InnoDB |            12 |     1048576 |
| ./mysql.ibd          | TABLESPACE | mysql            | InnoDB |            31 |     1048576 |
| ./sys/sys_config.ibd | TABLESPACE | sys/sys_config   | InnoDB |             0 |     1048576 |
| ./ibtmp1             | TEMPORARY  | innodb_temporary | InnoDB |            12 |     1048576 |
| ./undo_001           | UNDO LOG   | innodb_undo_001  | InnoDB |            16 |     1048576 |
| ./undo_002           | UNDO LOG   | innodb_undo_002  | InnoDB |            16 |     1048576 |
+----------------------+------------+------------------+--------+---------------+-------------+

2.2 file-per-table tablespace와 `.ibd`

innodb_file_per_table=ON이면 일반 테이블은 스키마 디렉터리 아래에 독립 .ibd 파일을 가진다. 예를 들어 appdb.orders 테이블은 datadir/appdb/orders.ibd 같은 형태로 배치될 수 있다. 이 파일에는 clustered index, secondary index, 일부 LOB 페이지가 함께 저장된다.

이 구조의 장점은 운영상 명확하다.

DROP TABLE 또는 TRUNCATE TABLE 후 파일 단위 공간 회수가 가능하다.
테이블별 디스크 사용량을 추적하기 쉽다.
transportable tablespace 같은 기능을 사용할 수 있다.
대형 테이블의 재구성, 압축, 파티션 운영에서 영향 범위를 분리하기 쉽다.

그러나 .ibd 파일을 운영체제 명령으로 직접 복사하거나 삭제해서는 안 된다. InnoDB 데이터 딕셔너리, redo log, undo 정보, doublewrite, buffer pool의 dirty page 상태와 연결되어 있기 때문이다. .ibd 파일만 다른 서버에 복사해도 메타데이터와 tablespace ID가 맞지 않으면 정상적으로 열 수 없다.

3. redo log: committed 변경을 복구 가능한 상태로 만드는 물리 로그

Redo log는 InnoDB crash recovery의 중심이다. 트랜잭션이 COMMIT될 때 변경된 데이터 페이지가 즉시 tablespace 파일에 기록되는 것은 아니다. InnoDB는 buffer pool에서 페이지를 변경하고, 그 변경을 재현할 수 있는 redo record를 먼저 durable하게 기록한다. 이후 checkpoint와 page flush 과정을 통해 dirty page가 tablespace에 반영된다.

이 구조는 write-ahead logging 원칙에 기반한다. 데이터 페이지가 디스크에 먼저 쓰이고 그 변경을 설명하는 redo가 아직 영속화되지 않은 상태가 되면, 장애 후 일관성을 회복할 수 없다. 따라서 InnoDB는 페이지 flush보다 redo log 기록 순서를 더 엄격하게 관리한다.

3.1 redo log와 checkpoint

Redo log는 무한히 커질 수 없으므로 checkpoint가 필요하다. checkpoint는 “여기까지의 변경은 tablespace 파일에 충분히 반영되었으므로 redo 재생이 이 지점 이전까지 필요하지 않다”는 기준점이다. redo 공간이 부족해지면 InnoDB는 더 공격적으로 dirty page를 flush해야 하며, 이때 쓰기 지연이나 급격한 성능 저하가 나타날 수 있다.

SHOW VARIABLES LIKE 'innodb_redo_log_capacity';
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';
SHOW GLOBAL STATUS LIKE 'Innodb_redo_log%';
SHOW ENGINE INNODB STATUS\G

MySQL 8.0 계열에서는 redo log 파일 관리 방식이 과거의 ib_logfile0, ib_logfile1 중심에서 #innodb_redo 디렉터리와 innodb_redo_log_capacity 중심으로 바뀐 구성이 흔하다. 오래된 문서나 자동화 스크립트가 ib_logfile* 존재만 전제하고 있다면 버전 차이를 확인해야 한다.

3.2 `innodb_flush_log_at_trx_commit`의 의미

innodb_flush_log_at_trx_commit은 COMMIT 시 redo log를 어디까지 보장할지 결정한다.

1: COMMIT마다 redo를 write하고 fsync한다. 가장 강한 내구성 보장이다.
2: COMMIT마다 OS로 write하지만 fsync는 주기적으로 수행한다. OS crash에서는 손실 가능성이 있다.
0: write와 fsync를 주기적으로 수행한다. MySQL crash에서도 최근 트랜잭션 손실 가능성이 커진다.

운영 환경에서 성능만 보고 2나 0으로 낮추는 것은 위험하다. 복제 replica나 재생 가능한 캐시성 시스템처럼 손실 허용 범위가 명확한 경우를 제외하면, primary OLTP 시스템에서는 기본값 1을 기준으로 검토하는 것이 안전하다.

4. undo tablespace: rollback과 consistent read를 지탱하는 이전 버전 저장소

Undo log는 트랜잭션이 변경하기 전의 정보를 저장한다. 이 정보는 두 가지 목적에 사용된다.

첫째, 트랜잭션 rollback이다. 아직 COMMIT되지 않은 변경을 취소하려면 이전 값을 알아야 한다. 둘째, MVCC consistent read다. 다른 트랜잭션이 과거 시점의 일관된 데이터를 읽어야 할 때 undo chain을 따라가며 필요한 버전을 구성한다.

SHOW VARIABLES LIKE 'innodb_undo%';
SELECT NAME, SPACE_TYPE, FILE_SIZE, ALLOCATED_SIZE
FROM INFORMATION_SCHEMA.INNODB_TABLESPACES
WHERE SPACE_TYPE LIKE '%Undo%';

실행 결과(MySQL 8.0.46):

+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_undo_directory    | ./    |
| innodb_undo_log_encrypt  | OFF   |
| innodb_undo_log_truncate | ON    |
| innodb_undo_tablespaces  | 2     |
+--------------------------+-------+
+-----------------+------------+-----------+----------------+
| NAME            | SPACE_TYPE | FILE_SIZE | ALLOCATED_SIZE |
+-----------------+------------+-----------+----------------+
| innodb_undo_001 | Undo       |  16777216 |       16781312 |
| innodb_undo_002 | Undo       |  16777216 |       16781312 |
+-----------------+------------+-----------+----------------+

Undo가 운영상 문제가 되는 대표 사례는 긴 트랜잭션이다. 장시간 열린 트랜잭션이 오래된 read view를 유지하면 purge thread가 불필요해진 row version을 제거하지 못한다. 그 결과 undo tablespace가 증가하고, history list length가 길어지며, secondary index 정리와 purge 부하가 지연될 수 있다.

SELECT trx_id, trx_started, trx_state, trx_mysql_thread_id, trx_query
FROM INFORMATION_SCHEMA.INNODB_TRX
ORDER BY trx_started;

SHOW ENGINE INNODB STATUS\G

SHOW ENGINE INNODB STATUS의 History list length가 계속 증가한다면 단순히 파일 용량 문제로만 보지 말고, 오래 열린 트랜잭션, 대량 DML, 느린 replica, purge 지연, undo truncate 설정을 함께 확인해야 한다.

5. binary log: InnoDB 내부 로그가 아니라 MySQL 서버 계층의 논리 로그

Binary log는 InnoDB redo log와 목적이 다르다. Redo log는 InnoDB 페이지 변경을 복구하기 위한 물리 로그이고, binary log는 MySQL 서버 계층에서 발생한 데이터 변경 이벤트를 기록하는 논리 로그다. 복제와 point-in-time recovery의 기준은 binary log다.

SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';

SELECT
  @@global.log_bin AS binary_logging_enabled,
  @@global.log_bin_basename AS binary_log_basename,
  CASE @@global.log_bin
    WHEN 1 THEN 'SHOW BINARY LOGS / SHOW BINARY LOG STATUS로 파일과 위치를 확인한다.'
    ELSE '현재 인스턴스에서는 binary log가 비활성화되어 있다.'
  END AS next_check;

실행 결과(MySQL 8.0.46):

+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | OFF   |
+---------------+-------+
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+
+----------------------------+---------+
| Variable_name              | Value   |
+----------------------------+---------+
| binlog_expire_logs_seconds | 2592000 |
+----------------------------+---------+
+------------------------+---------------------+-----------------------------------------------------------------------+
| binary_logging_enabled | binary_log_basename | next_check                                                            |
+------------------------+---------------------+-----------------------------------------------------------------------+
|                      0 | NULL                | 현재 인스턴스에서는 binary log가 비활성화되어 있다. |
+------------------------+---------------------+-----------------------------------------------------------------------+

binlog_format은 일반적으로 ROW를 기준으로 운영하는 경우가 많다. ROW는 변경된 행 이미지를 기록하므로 statement 재실행의 비결정성 문제를 줄인다. 반면 binary log 크기가 커질 수 있으며, 대량 UPDATE/DELETE 작업에서 디스크와 네트워크 부하를 크게 만들 수 있다.

Binary log는 다음 작업에 직접 영향을 준다.

source-replica 복제
GTID 기반 장애 조치와 재구성
특정 시점까지의 point-in-time recovery
감사 또는 변경 이력 기반 외부 시스템 연동
logical backup 이후의 증분 재생

따라서 binary log 보관 기간은 “디스크를 아끼기 위해 짧게”가 아니라 복구 목표와 복제 운영 절차에 맞춰 정해야 한다. 예를 들어 전체 백업이 매일 1회 수행되고 최대 24시간 전 시점 복구가 필요하다면, binary log는 백업 보존 정책과 함께 적어도 그 복구 구간을 커버해야 한다.

6. redo, undo, binlog의 경계: 같은 로그가 아니다

운영 중 장애를 분석할 때 redo, undo, binlog를 혼동하면 잘못된 복구 절차를 선택하게 된다.

항목	계층	주된 목적	사람이 재생하는가	대표 리스크
redo log	InnoDB storage engine	crash recovery	일반적으로 직접 재생하지 않음	용량 부족, fsync 지연, checkpoint 압박
undo log	InnoDB storage engine	rollback, MVCC	직접 재생하지 않음	긴 트랜잭션, purge 지연, undo 증가
binary log	MySQL server layer	복제, PITR	`mysqlbinlog`로 재생 가능	보관 부족, GTID 불일치, 대량 이벤트 부하

예를 들어 서버가 갑자기 종료되었다가 재기동될 때 InnoDB는 redo log와 undo log를 사용해 crash recovery를 수행한다. 반면 운영자가 어제 13시 10분 시점으로 복구하려면 전체 백업을 복원한 뒤 binary log를 원하는 시점까지 적용해야 한다. 두 절차는 모두 “복구”라고 부르지만 사용하는 파일과 판단 기준이 다르다.

# binary log 내용을 사람이 확인할 때의 예시
mysqlbinlog --base64-output=DECODE-ROWS --verbose binlog.000123 | less

# 특정 시점까지 재생하는 형태의 예시
mysqlbinlog --stop-datetime='2026-05-17 08:55:00' binlog.000123 binlog.000124 | mysql -u root -p

위 명령은 절차 예시이며, 실제 복구에서는 원본 서버에 직접 적용하지 말고 별도 복구 인스턴스에서 검증해야 한다. 시간대, GTID, 이미 적용된 이벤트, DDL 포함 여부, 사용자 권한, 외래 키 제약을 모두 확인해야 한다.

7. 운영자가 확인해야 할 디스크 사용량과 파일 배치

datadir 용량 장애는 MySQL 장애 중 매우 흔하다. tablespace, redo, undo, binlog는 모두 같은 디스크에 있을 수도 있고, 설정에 따라 일부가 다른 경로에 있을 수도 있다. 같은 파일 시스템에 몰려 있다면 binary log 폭증이 InnoDB page flush나 redo 기록까지 방해할 수 있다.

# 경로별 사용량 확인 예시
du -sh /var/lib/mysql
du -sh /var/lib/mysql/* 2>/dev/null | sort -h

# 파일 시스템 여유 공간과 inode 확인
df -h /var/lib/mysql
df -i /var/lib/mysql

MySQL 내부에서는 다음과 같은 쿼리로 테이블 단위 크기를 확인할 수 있다.

SELECT
  table_schema,
  table_name,
  ROUND((data_length + index_length) / 1024 / 1024, 1) AS size_mb,
  ROUND(data_free / 1024 / 1024, 1) AS free_mb
FROM information_schema.tables
WHERE table_schema NOT IN ('mysql', 'performance_schema', 'information_schema', 'sys')
ORDER BY data_length + index_length DESC
LIMIT 20;

Binary log 사용량은 SQL과 OS 명령을 함께 보는 편이 좋다.

SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';

SELECT
  @@global.log_bin AS binary_logging_enabled,
  @@global.log_bin_basename AS binary_log_basename;

실행 결과(MySQL 8.0.46):

+----------------------------+---------+
| Variable_name              | Value   |
+----------------------------+---------+
| binlog_expire_logs_seconds | 2592000 |
+----------------------------+---------+
+------------------------+---------------------+
| binary_logging_enabled | binary_log_basename |
+------------------------+---------------------+
|                      0 | NULL                |
+------------------------+---------------------+

# binlog 경로는 반드시 실제 log_bin_basename을 확인한 뒤 적용한다.
du -sh /var/lib/mysql/binlog.* 2>/dev/null

Binary log를 삭제할 때는 운영체제 rm으로 지우지 말고 MySQL 명령을 사용해야 한다.

SELECT 'PURGE BINARY LOGS TO ''binlog.000120''' AS purge_command_example;
SELECT 'PURGE BINARY LOGS BEFORE ''2026-05-10 00:00:00''' AS purge_command_example;

실행 결과(MySQL 8.0.46):

+--------------------------------------+
| purge_command_example                |
+--------------------------------------+
| PURGE BINARY LOGS TO 'binlog.000120' |
+--------------------------------------+
+------------------------------------------------+
| purge_command_example                          |
+------------------------------------------------+
| PURGE BINARY LOGS BEFORE '2026-05-10 00:00:00' |
+------------------------------------------------+

복제 구성에서는 replica가 아직 읽지 않은 binary log를 삭제하면 복제가 중단된다. SHOW REPLICA STATUS\G 또는 사용 중인 버전에 맞는 복제 상태 명령으로 각 replica의 읽기 위치와 GTID 상태를 먼저 확인해야 한다.

8. Aurora MySQL에서 달라지는 관점

Aurora MySQL은 MySQL 호환 인터페이스를 제공하지만 저장소 구조가 Community MySQL과 동일하지 않다. Aurora의 핵심은 데이터 페이지와 redo 성격의 변경 기록이 분산 스토리지 계층에 저장되고, DB 인스턴스의 로컬 디스크는 주로 임시 파일, 로그, 캐시, 엔진 실행 영역으로 사용된다는 점이다.

따라서 Aurora에서 운영자는 다음 차이를 이해해야 한다.

일반적인 datadir 파일 배치와 로컬 파일 크기만으로 전체 데이터 저장 구조를 판단할 수 없다.
스토리지 증가는 Aurora cluster volume 지표와 연결해서 봐야 한다.
백업과 point-in-time recovery는 Aurora의 continuous backup/PITR 기능과 강하게 통합되어 있다.
Binary log를 활성화하면 외부 복제, DMS, CDC에는 유용하지만, 보관과 I/O 비용 측면의 부담이 생길 수 있다.
Performance Insights, CloudWatch 지표, Enhanced Monitoring을 함께 봐야 redo/flush/스토리지 병목과 SQL 부하를 구분할 수 있다.

Aurora에서도 MySQL 계층의 개념 자체가 사라지는 것은 아니다. 트랜잭션, MVCC, undo, binary log, 복제 이벤트의 의미는 여전히 중요하다. 다만 운영자가 직접 파일을 보고 용량을 회수하거나 파일을 옮기는 방식의 접근은 Community MySQL보다 더 제한적이다. Aurora에서는 파일 시스템 조작보다 파라미터 그룹, 클러스터/인스턴스 지표, 백업 보존 기간, binlog 보존 설정, reader lag, failover 절차가 운영 판단의 중심이 된다.

9. 장애와 오해 사례

9.1 datadir 파일을 직접 삭제하면 공간이 회수된다는 오해

*.ibd, ibdata1, redo log, undo tablespace, binary log를 OS 명령으로 직접 삭제하는 것은 매우 위험하다. MySQL이 실행 중이면 열린 파일 핸들 때문에 공간이 즉시 반환되지 않을 수 있고, 재기동 시 메타데이터와 실제 파일이 불일치해 테이블을 열지 못할 수 있다. Binary log도 PURGE BINARY LOGS가 아니라 rm으로 삭제하면 인덱스 파일과 상태가 어긋날 수 있다.

9.2 ibdata1이 커졌으므로 OPTIMIZE TABLE로 줄어든다는 오해

innodb_file_per_table=ON인 개별 테이블의 .ibd는 재구성 후 공간 회수가 가능할 수 있다. 그러나 system tablespace인 ibdata1은 일반적인 OPTIMIZE TABLE로 작아지지 않는다. system tablespace 비대화 문제는 재구축이나 마이그레이션 계획으로 접근해야 한다.

9.3 redo log가 크면 데이터가 중복 저장된다는 오해

Redo log는 데이터 파일의 사본이 아니라 변경을 재현하기 위한 로그다. 크기를 너무 작게 잡으면 checkpoint 압박이 커지고, 너무 크게 잡으면 crash recovery 시간이 늘어날 수 있다. 적정 크기는 쓰기 부하, checkpoint age, 복구 시간 목표를 함께 고려해야 한다.

9.4 undo 증가를 디스크 문제로만 보는 오해

Undo tablespace 증가의 원인은 대개 긴 트랜잭션, 대량 변경, purge 지연과 연결된다. 파일을 줄이는 것만 목표로 하면 원인이 남아 다시 증가한다. 먼저 오래 열린 트랜잭션과 history list length를 확인해야 한다.

9.5 binary log 보관을 백업과 분리해서 정하는 오해

Binary log 보관 기간은 백업 정책의 일부다. 전체 백업은 있는데 그 이후 시점까지의 binary log가 없으면 point-in-time recovery는 불가능하다. 반대로 복구 목표보다 과도하게 오래 보관하면 디스크와 관리 부담이 커진다.

10. 운영 점검 체크리스트

11. 결론

MySQL의 데이터 디렉터리는 단순한 파일 저장소가 아니라 InnoDB의 페이지 영속화, 트랜잭션 복구, MVCC, 복제와 시점 복구가 만나는 지점이다. datadir, system tablespace, .ibd, redo log, undo tablespace, binary log는 서로 다른 계층과 목적을 가진다. 이 차이를 이해하면 디스크 사용량 증가, crash recovery, 긴 트랜잭션, 복제 장애, 백업 복구 정책을 더 안전하게 판단할 수 있다.

다음 단계에서는 이 물리 구조 위에서 InnoDB buffer pool과 page flush가 어떻게 동작하는지, 그리고 checkpoint와 dirty page 관리가 실제 쓰기 성능과 장애 복구 시간에 어떤 영향을 주는지 이어서 살펴볼 수 있다.

MySQL 데이터 디렉터리 구조: datadir, tablespace, redo, undo, binlog

1. datadir은 데이터베이스의 물리적 기준점이다

2. InnoDB tablespace의 책임: 페이지를 영속화하는 공간

2.1 system tablespace와 ibdata1

2.2 file-per-table tablespace와 .ibd

3. redo log: committed 변경을 복구 가능한 상태로 만드는 물리 로그

3.1 redo log와 checkpoint

3.2 innodb_flush_log_at_trx_commit의 의미

4. undo tablespace: rollback과 consistent read를 지탱하는 이전 버전 저장소

5. binary log: InnoDB 내부 로그가 아니라 MySQL 서버 계층의 논리 로그

6. redo, undo, binlog의 경계: 같은 로그가 아니다

7. 운영자가 확인해야 할 디스크 사용량과 파일 배치

8. Aurora MySQL에서 달라지는 관점

9. 장애와 오해 사례

9.1 datadir 파일을 직접 삭제하면 공간이 회수된다는 오해

9.2 ibdata1이 커졌으므로 OPTIMIZE TABLE로 줄어든다는 오해

9.3 redo log가 크면 데이터가 중복 저장된다는 오해

9.4 undo 증가를 디스크 문제로만 보는 오해

9.5 binary log 보관을 백업과 분리해서 정하는 오해

10. 운영 점검 체크리스트

11. 결론

2.1 system tablespace와 `ibdata1`

2.2 file-per-table tablespace와 `.ibd`

3.2 `innodb_flush_log_at_trx_commit`의 의미