카테고리 : MySQL/기술노트

InnoDB checkpoint 동작: fuzzy checkpoint와 crash recovery의 관계

InnoDB fuzzy checkpoint가 dirty page flush, redo log 재사용, crash recovery 시간에 어떤 영향을 주는지 운영 관점에서 정리한다.

저자: MySQL 기술 노트 작성: 2026.06.16 약 14분 8,226자
다운로드
#MySQL#InnoDB#백업복구#운영

1. checkpoint를 이해해야 하는 이유

InnoDB를 운영하다 보면 “redo log가 부족하다”, “dirty page가 많다”, “장애 후 MySQL 기동이 오래 걸린다”, “page cleaner가 따라가지 못한다” 같은 현상을 만난다. 이 현상들은 서로 다른 문제처럼 보이지만, 내부적으로는 대부분 checkpoint와 연결된다. checkpoint는 단순히 “디스크에 저장했다”는 표시가 아니라, InnoDB가 메모리의 변경분과 redo log의 재생 가능 범위를 조절하는 핵심 장치다.

트랜잭션이 커밋될 때 InnoDB는 변경된 데이터 페이지를 즉시 데이터 파일에 모두 반영하지 않는다. 대신 변경 내용을 redo log에 먼저 기록하고, 버퍼 풀의 데이터 페이지는 dirty page 상태로 남긴다. 이후 page cleaner와 flush 정책이 dirty page를 점진적으로 데이터 파일에 기록한다. 이때 어느 지점까지 데이터 파일이 redo log 없이도 일관된 상태에 가까워졌는지를 나타내는 기준점이 checkpoint다.

운영자가 checkpoint를 이해해야 하는 이유는 세 가지다.

  • 성능: checkpoint 압력이 커지면 백그라운드 flush만으로 부족해지고 foreground query가 간접적으로 지연될 수 있다.
  • 장애 복구 시간: checkpoint가 오래 밀려 있으면 crash recovery에서 재적용해야 할 redo log 범위가 길어진다.
  • 용량과 안정성: redo log는 순환 구조로 재사용되므로, checkpoint가 앞으로 이동하지 못하면 새 redo 기록 공간 확보가 어려워진다.

이 글은 InnoDB checkpoint의 동작을 fuzzy checkpoint, dirty page flush, redo log 재사용, crash recovery의 관계로 나누어 설명한다. 목표는 변수를 외우는 것이 아니라, 운영 중 checkpoint 지표가 나빠질 때 어떤 내부 경로가 막힌 것인지 판단하는 기준을 갖추는 것이다.

2. checkpoint의 기본 개념: redo log와 dirty page 사이의 약속

InnoDB는 write-ahead logging 원칙을 사용한다. 데이터 페이지를 데이터 파일에 쓰기 전에, 그 변경을 복구할 수 있는 redo log가 먼저 안정적으로 기록되어야 한다. 이 원칙 덕분에 커밋 시점마다 모든 데이터 페이지를 즉시 디스크에 쓰지 않아도 된다. 장애가 발생하면 마지막 checkpoint 이후의 redo log를 읽어 데이터 페이지 변경을 다시 적용한다.

checkpoint는 “이 지점 이전의 redo log는 더 이상 crash recovery에 필수적이지 않다”는 경계를 제공한다. 더 정확히 말하면, checkpoint LSN 이전의 변경은 데이터 파일에 충분히 반영되어 있어 redo log 순환 재사용 관점에서 안전하다고 판단되는 지점이다. 여기서 LSN(Log Sequence Number)은 redo log stream에서 위치를 나타내는 단조 증가 숫자다.

다음 관계를 먼저 구분해야 한다.

항목 의미 운영상 해석
current LSN 현재까지 생성된 redo log 위치 쓰기 workload가 진행될수록 증가한다
checkpoint LSN 데이터 파일 flush가 따라온 기준 위치 이 값이 느리게 이동하면 checkpoint가 밀린다
checkpoint age current LSN과 checkpoint LSN의 차이 crash recovery 대상 범위와 redo log 압력의 근사치다
dirty page 버퍼 풀에서 변경됐지만 데이터 파일에 아직 내려가지 않은 페이지 flush backlog이자 checkpoint 전진의 재료다

checkpoint age가 증가한다는 것은 변경 생성 속도에 비해 dirty page flush가 뒤처지고 있음을 의미한다. 단순히 redo log 파일이 크거나 작다는 문제가 아니라, redo 생성 속도와 page flush 처리량 사이의 균형 문제다.

3. fuzzy checkpoint란 무엇인가

전통적인 단순 checkpoint 모델을 떠올리면, 데이터베이스가 잠시 멈추고 모든 변경 페이지를 디스크에 쓴 뒤 “여기까지 안전하다”고 표시하는 장면을 생각하기 쉽다. 하지만 고성능 OLTP 엔진이 매번 이런 방식으로 동작하면 서비스 지연이 너무 커진다. InnoDB는 서버를 멈추지 않고 checkpoint를 점진적으로 전진시키는 fuzzy checkpoint 방식을 사용한다.

fuzzy checkpoint의 핵심은 다음과 같다.

  1. dirty page 전체를 한 번에 모두 flush하지 않는다.
  2. 백그라운드 thread가 workload와 I/O capacity를 보며 dirty page를 계속 내려 보낸다.
  3. 가장 오래된 dirty page의 LSN이 앞으로 이동하면 checkpoint LSN도 전진할 수 있다.
  4. 장애 시에는 checkpoint 이후 redo log를 재적용하여 데이터 파일을 일관된 상태로 만든다.

즉, fuzzy checkpoint는 “완전히 깨끗한 데이터 파일 상태”를 만드는 절차가 아니라, 복구 가능한 범위를 통제하면서 서비스 중 flush를 분산하는 메커니즘이다. 이 방식 때문에 InnoDB는 높은 동시성에서 커밋을 빠르게 처리할 수 있지만, 반대로 flush가 지속적으로 뒤처지면 checkpoint age가 커지고 redo log 공간 압박과 복구 시간 증가가 발생한다.

다음 그림은 fuzzy checkpoint와 crash recovery의 관계를 단순화한 것이다.

flowchart LR
  A[트랜잭션 변경] --> B[Redo Log Buffer]
  B --> C[Redo Log File]
  A --> D[Buffer Pool Dirty Page]
  D --> E[Page Cleaner Flush]
  E --> F[(Data File)]
  C --> G{Checkpoint LSN 전진}
  F --> G
  G --> H[Redo Log 재사용 가능 범위 확대]
  C --> I[Crash Recovery]
  G --> I
  I --> J[Checkpoint 이후 Redo 재적용]

이 그림에서 중요한 점은 redo log 기록과 데이터 페이지 flush가 서로 독립적인 속도로 진행된다는 것이다. 커밋은 redo log 내구성을 중심으로 완료될 수 있지만, checkpoint 전진은 dirty page flush가 실제로 진행되어야 가능하다. 그래서 커밋 TPS가 높은데 스토리지 flush 처리량이 낮으면 checkpoint가 뒤로 밀린다.

4. checkpoint가 전진하는 내부 흐름

checkpoint 전진은 단일 이벤트가 아니라 여러 내부 작업의 결과다. 단순화하면 다음 순서로 이해할 수 있다.

  1. SQL thread가 페이지를 변경하고 redo log record를 생성한다.
  2. 변경된 버퍼 풀 페이지는 dirty page list에 남는다.
  3. page cleaner thread가 dirty page를 선택해 데이터 파일로 flush한다.
  4. flush가 완료된 페이지의 oldest modification LSN이 더 이상 checkpoint를 막지 않게 된다.
  5. 가장 오래된 미반영 변경 지점이 앞으로 이동하면서 checkpoint LSN도 전진한다.
  6. checkpoint LSN 이전 redo log 공간은 순환 재사용 가능 범위에 가까워진다.

여기서 “어떤 dirty page를 먼저 flush할 것인가”가 중요하다. InnoDB는 단순히 dirty page 수만 보지 않는다. redo log 공간 압력, adaptive flushing, LRU flush, flush list, I/O capacity 설정 등을 종합해 flush 강도를 조절한다. 오래된 LSN을 가진 dirty page가 계속 남아 있으면 최근 변경 페이지가 많이 flush되어도 checkpoint는 기대만큼 전진하지 않을 수 있다.

운영 관점에서는 다음 구분이 중요하다.

  • dirty page 비율이 높지만 checkpoint age가 안정적이면, flush가 backlog를 관리 가능한 범위에서 따라가고 있을 수 있다.
  • dirty page 비율이 낮아 보여도 오래된 dirty page가 남아 checkpoint LSN이 밀릴 수 있다.
  • redo log capacity가 작으면 같은 write workload에서도 checkpoint 압력이 더 빨리 커진다.
  • I/O capacity를 너무 낮게 잡으면 page cleaner가 보수적으로 동작해 checkpoint가 늦게 전진할 수 있다.
  • I/O capacity를 너무 높게 잡으면 flush storm으로 foreground read/write latency가 악화될 수 있다.

5. crash recovery와 checkpoint의 관계

MySQL이 비정상 종료되면 InnoDB는 기동 시 crash recovery를 수행한다. 복구 과정은 크게 세 단계로 이해할 수 있다.

  1. 마지막 checkpoint 위치를 찾는다.
  2. checkpoint 이후의 redo log를 읽어 데이터 페이지에 필요한 변경을 재적용한다.
  3. 미완료 트랜잭션의 undo를 처리하고 일관된 상태를 만든다.

checkpoint가 최근 지점에 가까울수록 redo 적용 범위가 짧아진다. 반대로 checkpoint age가 크면 읽고 재적용해야 할 redo log 양이 많아진다. 따라서 checkpoint는 단순한 런타임 성능 문제가 아니라 장애 복구 시간 목표(RTO)와도 연결된다.

복구 시간이 길어지는 상황은 대체로 다음 조건이 겹칠 때 나타난다.

  • write-heavy workload가 지속되어 redo 생성 속도가 높다.
  • 스토리지 쓰기 지연 또는 IOPS 제한으로 dirty page flush가 따라가지 못한다.
  • redo log capacity가 커서 checkpoint age가 크게 벌어질 여지가 있다.
  • 종료 직전 대량 DML, bulk load, index rebuild, purge backlog가 있었다.
  • 서버가 정상 shutdown이 아니라 crash 또는 강제 종료로 내려갔다.

redo log capacity를 크게 잡으면 런타임 checkpoint 압력은 줄어들 수 있다. 하지만 checkpoint가 멀리 밀릴 수 있는 여지도 커지므로, 장애 복구 시 재적용 범위가 커질 수 있다. 운영 설계에서는 성능 안정성과 복구 시간을 함께 고려해야 한다.

6. checkpoint 관련 설정과 진단 쿼리

다음 쿼리는 MySQL 8.0 이상에서 checkpoint 관련 변수와 InnoDB metric 객체를 확인하는 기본 예제다. 운영 환경에서는 결과를 단독으로 해석하지 말고 workload, 스토리지 지표, 장애 시각의 로그와 함께 봐야 한다.

SELECT VERSION() AS mysql_version;

SHOW VARIABLES WHERE Variable_name IN (
  'innodb_redo_log_capacity',
  'innodb_log_file_size',
  'innodb_log_files_in_group',
  'innodb_max_dirty_pages_pct',
  'innodb_max_dirty_pages_pct_lwm',
  'innodb_io_capacity',
  'innodb_io_capacity_max',
  'innodb_adaptive_flushing',
  'innodb_flush_log_at_trx_commit'
);

실행 결과(MySQL 8.0.46):

mysql> SELECT VERSION() AS mysql_version;

+---------------+
| mysql_version |
+---------------+
| 8.0.46        |
+---------------+
1 row in set (0.00 sec)

mysql> SHOW VARIABLES WHERE Variable_name IN (
    ->   'innodb_redo_log_capacity',
    ->   'innodb_log_file_size',
    ->   'innodb_log_files_in_group',
    ->   'innodb_max_dirty_pages_pct',
    ->   'innodb_max_dirty_pages_pct_lwm',
    ->   'innodb_io_capacity',
    ->   'innodb_io_capacity_max',
    ->   'innodb_adaptive_flushing',
    ->   'innodb_flush_log_at_trx_commit'
    -> );

+--------------------------------+-----------+
| Variable_name                  | Value     |
+--------------------------------+-----------+
| innodb_adaptive_flushing       | ON        |
| innodb_flush_log_at_trx_commit | 1         |
| innodb_io_capacity             | 200       |
| innodb_io_capacity_max         | 2000      |
| innodb_log_file_size           | 50331648  |
| innodb_log_files_in_group      | 2         |
| innodb_max_dirty_pages_pct     | 90.000000 |
| innodb_max_dirty_pages_pct_lwm | 10.000000 |
| innodb_redo_log_capacity       | 104857600 |
+--------------------------------+-----------+
9 rows in set (0.00 sec)

innodb_redo_log_capacity는 MySQL 8.0.30 이후 redo log 용량 설정의 중심 변수다. 이전 계열에서는 innodb_log_file_size와 innodb_log_files_in_group 조합을 더 자주 보았다. 운영 중인 minor version에 따라 변수 사용 방식이 다르므로, 버전과 변수 존재 여부를 먼저 확인해야 한다.

InnoDB는 information_schema.INNODB_METRICS에 checkpoint와 redo 관련 metric을 노출한다. metric은 설정과 버전에 따라 count가 0이거나 비활성일 수 있지만, 객체와 이름을 확인하는 것만으로도 진단 출발점이 된다.

SELECT NAME, SUBSYSTEM, COUNT, COMMENT
FROM information_schema.INNODB_METRICS
WHERE NAME IN (
  'log_lsn_current',
  'log_lsn_checkpoint_age',
  'log_lsn_checkpoint_lsn',
  'buffer_pool_pages_dirty',
  'buffer_pool_pages_total'
)
ORDER BY NAME;

실행 결과(MySQL 8.0.46):

mysql> SELECT NAME, SUBSYSTEM, COUNT, COMMENT
    -> FROM information_schema.INNODB_METRICS
    -> WHERE NAME IN (
    ->   'log_lsn_current',
    ->   'log_lsn_checkpoint_age',
    ->   'log_lsn_checkpoint_lsn',
    ->   'buffer_pool_pages_dirty',
    ->   'buffer_pool_pages_total'
    -> )
    -> ORDER BY NAME;

+-------------------------+-----------+-------+------------------------------------------------------------------+
| NAME                    | SUBSYSTEM | COUNT | COMMENT                                                          |
+-------------------------+-----------+-------+------------------------------------------------------------------+
| buffer_pool_pages_dirty | buffer    |     0 | Buffer pages currently dirty (innodb_buffer_pool_pages_dirty)    |
| buffer_pool_pages_total | buffer    |  4096 | Total buffer pool size in pages (innodb_buffer_pool_pages_total) |
| log_lsn_checkpoint_age  | log       |     0 | Current LSN value minus LSN at last checkpoint                   |
| log_lsn_current         | log       |     0 | Current LSN value                                                |
+-------------------------+-----------+-------+------------------------------------------------------------------+
4 rows in set (0.00 sec)

checkpoint age를 직접 제공하는 metric이 있으면 current LSN과 checkpoint LSN의 차이를 쉽게 관찰할 수 있다. 다만 metric 활성화 상태, MySQL minor version, 배포판 빌드에 따라 노출 결과가 달라질 수 있다. 자동화된 운영 대시보드에서는 먼저 해당 metric이 실제로 존재하고 의미 있는 값을 반환하는지 검증해야 한다.

다음 예제는 작은 테이블 변경을 통해 dirty page와 redo log가 만들어지는 흐름을 재현하는 축소 실습이다. 이 예제는 checkpoint 압력을 크게 만들기 위한 부하 테스트가 아니라, 변경 → redo 생성 → dirty page 발생이라는 관계를 관찰하기 위한 안전한 구조다.

DROP TABLE IF EXISTS checkpoint_lab;

CREATE TABLE checkpoint_lab (
  id BIGINT PRIMARY KEY,
  payload VARCHAR(200) NOT NULL,
  updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB;

INSERT INTO checkpoint_lab (id, payload)
VALUES
  (1, REPEAT('a', 120)),
  (2, REPEAT('b', 120)),
  (3, REPEAT('c', 120));

UPDATE checkpoint_lab
SET payload = CONCAT(payload, '-changed')
WHERE id IN (1, 2);

SELECT id, CHAR_LENGTH(payload) AS payload_length
FROM checkpoint_lab
ORDER BY id;

DROP TABLE checkpoint_lab;

실행 결과(MySQL 8.0.46):

mysql> DROP TABLE IF EXISTS checkpoint_lab;

Query OK, 0 rows affected (0.00 sec)

mysql> CREATE TABLE checkpoint_lab (
    ->   id BIGINT PRIMARY KEY,
    ->   payload VARCHAR(200) NOT NULL,
    ->   updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
    -> ) ENGINE=InnoDB;

Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO checkpoint_lab (id, payload)
    -> VALUES
    ->   (1, REPEAT('a', 120)),
    ->   (2, REPEAT('b', 120)),
    ->   (3, REPEAT('c', 120));

Query OK, 3 rows affected (0.01 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> UPDATE checkpoint_lab
    -> SET payload = CONCAT(payload, '-changed')
    -> WHERE id IN (1, 2);

Query OK, 2 rows affected (0.00 sec)
Rows matched: 2  Changed: 2  Warnings: 0

mysql> SELECT id, CHAR_LENGTH(payload) AS payload_length
    -> FROM checkpoint_lab
    -> ORDER BY id;

+----+----------------+
| id | payload_length |
+----+----------------+
|  1 |            128 |
|  2 |            128 |
|  3 |            120 |
+----+----------------+
3 rows in set (0.00 sec)

mysql> DROP TABLE checkpoint_lab;

Query OK, 0 rows affected (0.00 sec)

운영 환경에서 대량 DML 직후 checkpoint age가 증가한다면 위 축소 예제와 같은 원리가 훨씬 큰 규모로 발생하는 것이다. 변경된 페이지가 많아지고 redo 생성량이 늘어나며, page cleaner가 flush를 충분히 따라가지 못하면 checkpoint는 뒤로 밀린다.

7. 운영 지표를 어떻게 해석할 것인가

checkpoint 문제를 볼 때는 하나의 숫자보다 관계를 봐야 한다. 특히 다음 조합이 중요하다.

7.1 checkpoint age 증가 + write latency 증가

checkpoint age가 계속 증가하면서 스토리지 write latency도 커진다면 dirty page flush가 병목일 가능성이 높다. 이때는 innodb_io_capacity, innodb_io_capacity_max, 스토리지 IOPS/throughput 제한, 클라우드 볼륨 burst credit, doublewrite 비용을 함께 봐야 한다. page cleaner가 일을 더 해야 하는데 스토리지가 받아주지 못하는 상태일 수 있다.

7.2 checkpoint age 증가 + redo log 공간 압박

redo log는 순환 구조로 재사용된다. checkpoint가 앞으로 이동하지 않으면 오래된 redo 범위를 덮어쓸 수 없다. redo log capacity에 가까운 압력이 발생하면 InnoDB는 더 공격적으로 flush하거나 foreground 작업이 간접적으로 느려질 수 있다. 이 상태에서는 단순히 쿼리 튜닝만으로 해결되지 않을 수 있다.

7.3 dirty page 비율 높음 + flush storm

dirty page 비율이 높아진 뒤 갑자기 강한 flush가 발생하면 순간적으로 디스크 write가 몰리고 read latency까지 악화될 수 있다. 이를 flush storm처럼 체감할 수 있다. adaptive flushing은 이런 상황을 완화하기 위해 존재하지만, workload가 급격히 변하거나 I/O capacity 설정이 실제 스토리지와 맞지 않으면 여전히 흔들릴 수 있다.

7.4 장애 복구 시간이 길어짐

장애 후 MySQL 기동 로그에서 crash recovery가 오래 걸린다면, 종료 시점의 checkpoint age와 redo 양을 의심해야 한다. 정상 shutdown이 아니라 강제 종료였고 직전에 write burst가 있었다면 가능성이 더 크다. 이때는 “복구가 느렸다”는 사실만 보지 말고, 평소 checkpoint age의 상위 백분위와 redo 생성량을 관찰해야 한다.

8. Aurora MySQL에서는 무엇이 달라지는가

Aurora MySQL은 스토리지 계층이 Community MySQL의 로컬 InnoDB 파일 구조와 다르다. Aurora는 로그 중심의 분산 스토리지 구조를 사용하며, 6-way 복제된 스토리지 계층과 writer/reader 인스턴스 구조가 결합된다. 이 때문에 운영자가 보는 지표와 장애 양상은 일반 MySQL과 다르게 나타날 수 있다.

다만 개념적 원리는 여전히 유효하다. 변경을 복구 가능한 로그 형태로 남기고, 스토리지 계층이 일관된 복구 지점을 관리하며, 장애 후에는 필요한 로그 범위를 재적용하거나 스토리지 계층의 보호 메커니즘을 통해 복구한다. 차이는 다음 지점에서 나타난다.

  • 로컬 디스크의 redo log 파일 크기와 page flush 병목만으로 Aurora의 쓰기 경로를 설명할 수 없다.
  • CloudWatch, Performance Insights, Aurora wait event, storage latency 지표를 함께 봐야 한다.
  • checkpoint 또는 recovery 관련 문제를 해석할 때 인스턴스 내부 InnoDB 지표와 Aurora 스토리지 계층의 지표를 분리해야 한다.
  • failover 시간은 checkpoint age만이 아니라 writer 승격, cluster volume 상태, replica lag, connection failover 처리에 영향을 받는다.

따라서 Aurora 환경에서는 Community MySQL식 파일·redo 변수만으로 결론을 내리면 위험하다. 그러나 “변경 생성 속도, 로그 내구성, 스토리지 반영, 복구 범위”라는 사고 틀은 여전히 문제를 분해하는 데 유용하다.

9. 흔한 오해와 주의점

9.1 checkpoint는 모든 dirty page를 즉시 없애는 작업이 아니다

fuzzy checkpoint에서는 서비스 중 dirty page가 항상 존재할 수 있다. dirty page가 있다는 사실 자체가 문제는 아니다. 문제는 dirty page flush가 redo 생성 속도를 장기간 따라가지 못해 checkpoint age가 통제 범위를 벗어나는 것이다.

9.2 redo log를 크게 하면 모든 문제가 해결되는 것은 아니다

redo log capacity를 늘리면 checkpoint 압력을 완화하고 write burst를 흡수하는 데 도움이 될 수 있다. 하지만 복구 시 재적용 범위가 커질 수 있고, 근본적인 스토리지 처리량 부족을 숨길 뿐일 수도 있다. 변경 후에는 crash recovery 시간 목표와 write latency를 함께 검증해야 한다.

9.3 dirty page 비율만 보고 checkpoint 상태를 단정하면 안 된다

dirty page 비율은 유용하지만 checkpoint age를 완전히 대체하지 못한다. 오래된 LSN을 가진 소수 dirty page가 checkpoint 전진을 막을 수 있고, 반대로 dirty page 비율이 높아도 flush가 안정적으로 진행되면 운영상 문제가 작을 수 있다.

9.4 innodb_io_capacity는 스토리지 스펙 숫자가 아니다

innodb_io_capacity는 InnoDB 백그라운드 flush 강도를 조절하는 힌트에 가깝다. 클라우드 스토리지의 최대 IOPS를 그대로 넣는다고 좋은 설정이 되는 것은 아니다. foreground query latency, redo 생성량, page cleaner 활동, 스토리지 queue depth를 함께 보며 조정해야 한다.

9.5 정상 shutdown과 crash recovery를 혼동하면 안 된다

정상 shutdown에서는 InnoDB가 dirty page를 정리하고 복구 부담을 줄일 수 있다. 반면 crash나 강제 종료에서는 마지막 checkpoint 이후 redo log를 재적용해야 한다. 장애 복구 시간을 평가할 때는 종료 방식과 직전 workload를 반드시 함께 기록해야 한다.

10. 운영 점검 체크리스트

checkpoint와 crash recovery를 안정적으로 관리하려면 다음 항목을 주기적으로 점검한다.

  • innodb_redo_log_capacity
  • innodb_io_capacity와 innodb_io_capacity_max

11. 결론

InnoDB checkpoint는 redo log, dirty page, page cleaner, crash recovery를 연결하는 운영상의 중심 개념이다. fuzzy checkpoint는 서버를 멈추지 않고 checkpoint를 점진적으로 전진시키기 때문에 OLTP 성능에 유리하지만, flush가 장기간 뒤처지면 redo log 압력과 장애 복구 시간 증가로 이어진다.

운영자는 checkpoint를 “백그라운드에서 알아서 되는 내부 작업”으로만 보지 말아야 한다. write workload가 증가하거나 스토리지 latency가 흔들릴 때 checkpoint age가 어떻게 반응하는지, dirty page flush가 어느 속도로 따라가는지, 장애 후 복구 시간이 목표 안에 들어오는지 확인해야 한다. 다음 글에서는 이 흐름과 이어지는 주제로 redo log, undo log, purge, buffer pool flush가 실제 장애 상황에서 어떻게 서로 영향을 주는지 더 세밀하게 살펴볼 수 있다.