measure(rpo-rto): binlog 재생 1GB 당 약 2분 15초 · S3 반출 주기 N초면 최악 ≈ N초 손실 (EC2)

docs/decisions/rpo-rto-targets.md

@@ -1,6 +1,6 @@
 # RPO·RTO 목표 — «얼마나 잃어도 되고, 얼마 안에 돌아와야 하나» 를 정하는 분기점
 
-작성일: 2026-11-07 · 갱신: 2026-11-08 (§8-1 읽기 : 쓰기 비율 가정 추가)
+작성일: 2026-11-07 · 갱신: 2026-11-08 (§8-1 읽기 : 쓰기 비율 가정 추가 · §6-2 측정 둘 — 재생 시간·호스트 상실 RPO)
 상태: 🟡 **방향 확정 · 숫자 미정.** 구성 2(백업 + binlog 서버 밖 반출) 채택, 리플리카 보류, 반동기 미채택
 (2026-11-07 사용자 confirm). **반출 주기·백업 주기·보존 기간 숫자는 아직 없다** — 추천안이 숫자를 정하지
 않았고, 근거 없이 채우지 않는다(§6 Q4·Q6).
@@ -101,7 +101,7 @@ Flyway 마이그레이션의 테이블 기준. «재생성» 칸은 코드·문
 |---|---|---|---|---|
 | **프로세스 죽음** | OOM kill, mysqld 크래시 | 디스크에 남음 | **0** — 커밋된 건 디스크에 있다(`innodb_flush_log_at_trx_commit=1`·`sync_binlog=1`) | ⬜ **미측정** — 재기동 + redo 복구 시간 |
 | **호스트 재부팅** | OS 패치, 인스턴스 재시작 | 남음 | 0 | ⬜ 미측정 |
-| **논리 사고** | 실수로 `DROP TABLE`·대량 `DELETE` | 남음 (사고도 binlog 에 기록) | **사고 직전** — PITR 실측 확인(백업 문서 Q5) | 백업 붓기(물리 약 174초 · 논리 약 21분, 1억 행) **+ binlog 재생(⬜ 미측정)** |
+| **논리 사고** | 실수로 `DROP TABLE`·대량 `DELETE` | 남음 (사고도 binlog 에 기록) | **사고 직전** — PITR 실측 확인(백업 문서 Q5) | 백업 붓기(물리 약 174초 · 논리 약 21분, 1억 행) **+ binlog 재생 — 1GB 당 약 2분 15초(표준), 병렬이면 약 절반** ([재생 실측](../../loadtest/results/binlog-replay-time-2026-11-07/README.md)) |
 | **호스트·디스크 상실** | EBS 고장, 인스턴스 삭제, `compose down -v`, 랜섬웨어 | 🔴 **binlog 도 같이 사라짐** | 🔴 **정의 안 됨** — «마지막 백업 시점» 인데 백업 주기·위치가 없다 | 새 서버 준비(⬜) + 백업 붓기 — **백업이 서버 밖에 없으면 복구 불가** |
 
 ⚠️ 복구 시간 실측은 m6i.xlarge · gp3 · 1억 행(합성) 조건이고 «운영에서 N분» 으로 인용 금지(백업 문서 §5).
@@ -120,7 +120,7 @@ Flyway 마이그레이션의 테이블 기준. «재생성» 칸은 코드·문
 |---|---|---|---|---|---|
 | **0** | 지금 (백업 없음, binlog 같은 디스크) | 🔴 전부 | 🔴 복구 불가 | 없음 | 없음 |
 | **1** | 주기 백업 → 서버 밖(S3 등) | **백업 주기** (예: 하루면 최대 24시간) | 새 서버 + 백업 붓기 (물리 약 174초 · 논리 약 21분 실측, 1억 행) | 없음 (백업 중 정지 42~126ms 실측) | 저장 요금 · 백업 잡 |
-| **2** | 1 + binlog 를 주기적으로 서버 밖에 (회전 때 업로드) | **binlog 업로드 주기** (예: 5분) | 1 + **binlog 재생 (⬜ 미측정)** | 없음 | 2 와 비슷 · 업로드 잡 · 주기적 `FLUSH BINARY LOGS` |
+| **2** | 1 + binlog 를 주기적으로 서버 밖에 (회전 때 업로드) | **binlog 업로드 주기** — 실측 최악 ≈ 주기(60초 주기 6~51초 · 300초 주기 109~300초, [호스트 상실 실측](../../loadtest/results/hostloss-rpo-2026-11-07/README.md)) | 1 + **binlog 재생 — 1GB 당 약 2분 15초**(DAU 1,000 가정 하루치 ≈ 0.6GB ≈ 1분 20~35초, [재생 실측](../../loadtest/results/binlog-replay-time-2026-11-07/README.md)) | 없음 | 2 와 비슷 · 업로드 잡 · 주기적 `FLUSH BINARY LOGS` |
 | **2'** | 1 + binlog 실시간 스트리밍 (`mysqlbinlog --stop-never` 를 다른 서버에서) | 수 초 | 2 와 같음 | 없음 | 받는 서버 1대 상시 |
 | **3** | 2 + **비동기 리플리카** | 리플리카가 못 받은 양 — 쓰기 부하에서 **약 60초 밀림** 실측(같은 AZ·SQL writer) | **승격 시간** — 밀린 양 적용 + 앱 연결 전환 (⬜ 미측정, 수동이면 사람 시간 추가) | 없음 | 서버 1대 상시 · 복제 감시 |
 | **4** | 3 + **반동기** | 거의 0 — 🔴 단 리플리카가 끊기면 **조용히 비동기로 강등**(실측) | 3 과 같음 | **처리량 −5.9%(같은 AZ) ~ −17.2%(다른 AZ)** · 몰리면 −10.3% (실측) | 3 + 강등 알람 · 리플리카 재기동 절차(시작 옵션으로 켤 것 — [11-07 결과](../../loadtest/results/replication-semisync-recovery-2026-11-07/README.md)) |
@@ -162,8 +162,8 @@ Flyway 마이그레이션의 테이블 기준. «재생성» 칸은 코드·문
 
 | 무엇 | 왜 | 어디서 |
 |---|---|---|
-| binlog 재생 시간 (백업 이후 N시간치) | 구성 2 의 RTO 를 정한다 — Q5 의 근거 | EC2 (백업 rig 재사용) |
-| 호스트 상실 → S3 만으로 복구 | 구성 2 가 실제로 되는지 + 잃은 행 수 | EC2 |
+| ~~binlog 재생 시간 (백업 이후 N시간치)~~ ✅ 11-08 | 구성 2 의 RTO 를 정한다 — Q5 의 근거 | [재생 실측](../../loadtest/results/binlog-replay-time-2026-11-07/README.md) |
+| ~~호스트 상실 → S3 만으로 복구~~ ✅ 11-08 | 구성 2 가 실제로 되는지 + 잃은 양 | [호스트 상실 실측](../../loadtest/results/hostloss-rpo-2026-11-07/README.md) |
 | 프로세스 재기동 RTO | §4 첫 줄의 빈칸 | 로컬로 충분 (메커니즘) |
 
 ---
@@ -252,3 +252,11 @@ DAU 와 비교해 판단을 닫지 않는다는 원칙과도 어긋난다([[feed
 - 2026-11-08: **§8-1 읽기 : 쓰기 비율 가정 추가** (사용자 요청). 실측이 없어 가정으로 — 요청 기준 1 : 6,
   행 기준 쓰기 10배 이상, 문장 기준 약 1 : 2. 새 가정 둘(저장 묶음 20행 · 세션당 조회 5번)은 미확인이라 표시.
   조회가 6배 늘어도 같아지는 정도라 R4(읽기 리플리카)가 뒤쪽이라는 판단은 유지된다.
+- 2026-11-08: **§6-2 측정 둘 — EC2 로 닫았다** (m6i.xlarge · 8.0.46 · 커밋 `7c5e4900`). 숫자 결정(Q4·Q5·Q6)은 **여전히 사용자 몫**이고
+  이 항목은 근거만 붙인다.
+  ① [재생 실측](../../loadtest/results/binlog-replay-time-2026-11-07/README.md): 표준 재생(mysqlbinlog|mysql)은 binlog 1GB 당 135~141초로 **양에 거의 정비례**, 병렬 재생(SQL 스레드 4개)은 적용만 약 2배
+  빠르다(준비 포함 1.6~1.9배). 0.67 / 2.33 / 8.89GB = DAU 1,000 가정 약 1.1 / 4 / 15일치 → 표준 93~95 / 318~322 / 1,187~1,212초.
+  ② [호스트 상실 실측](../../loadtest/results/hostloss-rpo-2026-11-07/README.md): S3 만으로 끝까지 복구됐고(7판), 잃은 시간은 «주기 안에서 잃은 시점 × 주기» — 60초 주기 6~51초, 300초 주기 109~300초.
+  🔴 300초의 최악이 299.5초로 주기에 붙었다 — «최대 손실 = 주기» 로 약속하려면 업로드 시간을 더해 잡아야 한다.
+  쓰기 중 XtraBackup 은 EC2 7판 모두 1회 성공(로컬에선 redo 경합으로 실패한 판 있음).
+  다음에 잴 것: 복구 중에만 디스크 기록을 늦춘 재생(다른 세션 제안) · 기준 1억 행 · 새 서버 준비 시간.

loadtest/results/binlog-replay-time-2026-11-07/README.md

@@ -0,0 +1,91 @@
+# binlog 재생 시간 — 백업 이후 쌓인 binlog 를 되살리는 데 얼마 걸리나 (2026-11-08, EC2)
+
+설계 문서: [`../../../docs/decisions/rpo-rto-targets.md`](../../../docs/decisions/rpo-rto-targets.md) §5 구성 2 · §6-2
+짝 실험: [`../hostloss-rpo-2026-11-07/`](../hostloss-rpo-2026-11-07/README.md) (호스트 상실 RPO)
+무대: **EC2 `m6i.xlarge`**(4 vCPU · 15GB) · gp3 200GB · `ap-northeast-2d` · MySQL **8.0.46** · 버퍼풀 2GB ·
+`flush_log_at_trx_commit=1` · `sync_binlog=1`(재생하는 복구 서버도 같음) · 기준 1,000만 행 ·
+RUN_ID `replay-ec2-20261107-173709` · 커밋 `7c5e4900` · 19판 전부 검증 일치(COUNT·MAX(id)·CHECKSUM)
+
+## 0. 한 줄
+
+**표준 방법(mysqlbinlog | mysql)은 binlog 1GB 를 되살리는 데 약 2분 15초(135~141초)가 걸리고, 양에 거의 정비례했다.**
+병렬 방법(릴레이 로그 + 복제 SQL 스레드 4개)은 적용만 보면 **약 2배 빨랐다**(65~70초/GB). 파일을 릴레이 로그로
+옮기는 준비 시간을 넣어도 1.6~1.9배다.
+
+## 1. 결과 (본판 3판씩)
+
+| 단계 | 실제 binlog | 행 수 | DAU 1,000 가정이면 | 표준 M1 | 병렬 M2 (적용) | 병렬 M2 (준비 포함) |
+|---|---:|---:|---|---:|---:|---:|
+| 512MB | 0.67GB | 31만 | 약 1.1일치 | **93~95초** | 45~46초 | 54~58초 |
+| 2048MB | 2.33GB | 108만 | 약 4.0일치 | **318~322초** | 147~156초 | 173~182초 |
+| 8192MB | 8.89GB | 413만 | 약 15일치 | **1,187~1,212초** (약 20분) | 620~621초 | 745~751초 |
+
+- **양에 비례한다** — M1 은 GB 당 141 → 137 → 135초로 거의 일정하다. 그래서 «백업 간격 × 하루 binlog 양 × 135~141초/GB»
+  로 다른 간격도 환산할 수 있다(이 무대·이 페이로드 조건에서)
+- **판 간 흔들림이 작다** — 같은 칸 안 차이가 M1 1.3~2.0%, M2 0.3~5.8%. 단계·방법 차이보다 한참 작다
+- 「DAU 1,000 가정이면」 열은 **추정**이다 — 연 1억 행(이 프로젝트의 DAU 1,000 합성 가정) ÷ 365 = 하루 약 27만 행으로
+  나눈 값이고, 실제 하루 쓰기량을 잰 게 아니다
+
+### 1-1. 쓰기보다 재생이 느리다
+
+같은 binlog 를 만드는 데 걸린 시간(15개 연결로 동시에 씀)은 0.67GB 41초 · 8.89GB 635초였다(`ec2/levels.tsv`, 누적).
+표준 재생은 한 줄로 순서대로 적용하니 **원래 쓰는 데 걸린 시간의 약 2배**가 걸린다. 병렬 재생은 거의 원래 속도를 따라간다.
+
+## 2. 이걸로 RTO(복구 시간)를 어떻게 읽나
+
+구성 2(백업 + binlog 를 서버 밖에)의 복구 시간 ≈ **새 서버 준비 + 백업 붓기 + binlog 재생**.
+
+| 항목 | 값 | 출처·조건 |
+|---|---|---|
+| 백업 붓기 | 물리(XtraBackup) 약 174초 · 논리 약 21분 | 08-13 백업 라운드 — **1억 행**(합성), m6i.xlarge |
+| 백업 붓기 (작은 무대) | 내려받기 2.4~2.6초 + prepare·copy-back 53~57초 | 짝 실험(호스트 상실) — **1,000만 행** |
+| binlog 재생 | 위 표 — 1GB 당 약 2분 15초(M1) | 이 실험 |
+| 새 서버 준비 | ⬜ 안 쟀다 | — |
+
+예) DAU 1,000 가정에서 **백업을 하루 한 번** 뜨면, 최악(백업 직전 상실)의 재생 몫은 하루치(약 0.6GB) ≈ **약 1분 20초~1분 35초(M1)**
+(잰 칸은 1.1일치 93~95초), **일주일에 한 번**이면 약 7일치 ≈ 4.1GB ≈ **약 9~10분(M1, 환산)** 이다. 여기에 백업 붓기(1억 행이면 약 3분)와 새 서버
+준비 시간이 더해진다. ⚠️ 일주일치는 **잰 단계(1·4·15일치) 사이를 직선으로 환산한 값**이다.
+
+## 3. 조건 — 인용할 때 떼면 안 되는 것
+
+1. **writer 페이로드는 실제 33 랜드마크 JSON(≈2KB/행)** 이다(사용자 결정, 2026-11-07). `'{}'` 로 재면 같은 GB 에 행이 수십 배라
+   재생 시간이 부풀어 나온다 — 08-22 복제 라운드의 writer 와 **페이로드가 다르다**
+2. **기준 테이블(1,000만 행)은 `'{}'` 페이로드**다. 재생이 얹히는 테이블의 크기·인덱스 깊이는 1,000만 행 기준이고, 1억 행이면
+   다를 수 있다(안 쟀다)
+3. **복구 서버도 커밋마다 디스크에 확실히 기록하는 설정**(`flush=1`·`sync_binlog=1`, binlog 켜짐)으로 재생했다. 복구 중에만 이걸
+   늦추면 빨라질 수 있다 — §5
+4. M2 는 `replica_parallel_workers=4` · `LOGICAL_CLOCK` · `preserve_commit_order=ON`. 소스의 의존성 추적은 `COMMIT_ORDER`
+   (8.0 기본)다 — `WRITESET` 이면 병렬 여지가 더 커질 수 있다(안 쟀다)
+5. 판마다 같은 기준 datadir 사본에서 복구 서버를 새로 띄웠다 — 사본 붓기 시간은 이 표에 없다(§2 의 «백업 붓기» 가 그 자리)
+6. 절대 시간은 하드웨어 종속이다(m6i.xlarge · gp3 기본 125MB/s·3,000 IOPS) — «운영에서 N분» 으로 인용 금지
+
+## 4. 로컬 스모크가 걸러낸 rig 결함
+
+EC2 에서 몇 시간 돌린 뒤에야 만났을 것들 — 커밋 `7c5e4900` 메시지에 전부 적었다. 이 rig 에 해당하는 것만:
+
+- 헬퍼 컨테이너가 root 가 아니라 datadir 를 못 읽음 → `--user 0`
+- M2 의 «끝났다» 판정을 릴레이 파일 이름으로 해서 영영 안 끝남 — 적용이 끝난 릴레이 파일은 MySQL 이 지운다 → 원본 binlog 좌표 +
+  워커가 다 놀고 있는지로 판정
+- `SELECT 1` 대기가 MySQL 초기화용 임시 서버에 붙어 «떴다» 고 착각 → `skip_networking=0` 이 될 때까지 대기
+- 윈도의 `python3` 가 스토어 안내만 찍는 가짜라 템플릿 생성 실패 → 실제로 도는 파이썬을 고른다
+
+## 5. 다음에 잴 것
+
+- **복구 서버의 디스크 기록을 늦춘 표준 재생** — 재생하는 동안만 `innodb_flush_log_at_trx_commit=2` · `sync_binlog=0` 으로 띄우는 팔.
+  다른 세션(«AWS 실측 체크»)의 로컬 리허설에서 더 빨랐지만 판 간 흔들림이 커 크기는 판정하지 못했다(그 rig 는 폐기). 단서 둘:
+  ① 재생 중 서버가 죽으면 처음부터 다시 해야 한다 ② 끝나고 설정을 되돌려 운영으로 넘기는 시간은 이 값에 안 들어간다.
+  M1 이 트랜잭션당 약 7.6ms(31만 행 ÷ 25행 ÷ 94초)라 «커밋마다 fsync» 만으로 설명되는지는 이 데이터로 갈리지 않는다
+- 기준 1억 행에서 같은 재생 — 조건 2
+- 새 서버 준비 시간 — §2 의 빈칸
+
+## 6. 재현
+
+```bash
+# 로컬 스모크
+OUT="$PWD/_smoke" BASE_ROWS=20000 LEVELS_MB="4 16" REPS=1 WRITE_CHUNK_S=5 BUFFER_POOL=256M bash replay_sweep.sh
+# EC2 — ec2_userdata.sh 의 @@...@@ 를 채워 user-data 로 (이번 값은 ec2/round.log 머리)
+BASE_ROWS=10000000 LEVELS_MB="512 2048 8192" REPS=3 BUFFER_POOL=2G bash replay_sweep.sh
+```
+
+산출물: `ec2/trials.tsv`(판별) · `ec2/levels.tsv`(단계 경계의 binlog 크기·행 수·검증값·누적 쓰기 시간) · `ec2/D0_stage.txt` ·
+`ec2/run.log` · `ec2/round.log` · `ec2/box.txt`. `_smoke/` 는 로컬 스모크(시간 값 무의미).

loadtest/results/binlog-replay-time-2026-11-07/_smoke/D0_stage.txt

@@ -0,0 +1,12 @@
+# D0 — 무대 (2026-11-07T15:09:52Z UTC)
+source  version                                  8.0.46
+source  innodb_buffer_pool_size                  268435456
+source  innodb_flush_log_at_trx_commit           1
+source  sync_binlog                              1
+source  binlog_format                            ROW
+source  binlog_transaction_dependency_tracking   COMMIT_ORDER
+source  max_binlog_size                          1073741824
+BASE_ROWS=20000 LEVELS_MB=4 16 REPS=1 CONNS=15 ROWS_PER_TX=25 WORKERS=4
+M2 판별 실제 병렬 설정 (workers · type · preserve_commit_order):
+4	LOGICAL_CLOCK	1
+nproc=4

loadtest/results/binlog-replay-time-2026-11-07/_smoke/levels.tsv

@@ -0,0 +1,3 @@
+level_mb	binlog_bytes	files	count	max_id	probe_checksum	write_s
+4	8392787	binlog.000004 binlog.000005 	23900	31213	3082519675	27
+16	24155791	binlog.000004 binlog.000005 binlog.000006 	31225	40296	2861379414	67

loadtest/results/binlog-replay-time-2026-11-07/_smoke/trials.tsv

@@ -0,0 +1,6 @@
+trial	kind	method	level_mb	binlog_bytes	prep_ms	apply_ms	verify
+1	버림	M1	4	8392787	0	33824	OK
+2	본판	M1	4	8392787	0	26620	OK
+3	본판	M2	4	8392787	41244	49136	OK
+4	본판	M1	16	24155791	0	81822	OK
+5	본판	M2	16	24155791	33021	72874	OK

loadtest/results/binlog-replay-time-2026-11-07/_writer_common.sh

@@ -0,0 +1,56 @@
+# 두 rig(binlog 재생 시간 · 호스트 상실 RPO)이 같이 쓰는 writer — source 해서 쓴다
+#
+# 트랜잭션 모양은 08-22 복제 rig(repl2_rig.sh:272)과 같다: INSERT p_rows 행 + 세션 행 UPDATE 를 한 트랜잭션.
+# 다른 점은 페이로드 하나 — `joint_coordinates` 에 '{}' 대신 **실제 33 랜드마크 JSON(≈2,076B/행)** 을 넣는다
+# (loadtest/seed/gen_pose_template.py, 08-13 백업 라운드의 real 무대와 같은 템플릿). binlog 를 «GB» 로 재면
+# 페이로드가 행 수를 정하고, 재생 시간은 행·트랜잭션 수를 따라가기 때문이다(2026-11-07 사용자 결정).
+#
+# 커밋마다 (세션 id, 커밋 뒤 version, 커밋 시각 µs) 한 줄을 클라이언트로 돌려준다 — 호스트 상실 rig 이
+# «서버 밖에서 본 커밋 성공» 의 정본으로 쓴다(서버가 사라져도 클라이언트 파일은 남는다).
+#
+# 필요한 것: q() · PW · WORK · die() 가 호출하는 쪽에 정의돼 있어야 한다.
+
+COMMON_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+TEMPLATE_GEN="$COMMON_DIR/../../seed/gen_pose_template.py"
+
+# $1 = 컨테이너. lab 스키마·pose_data_scale·session_probe 가 이미 있어야 한다.
+setup_writer() {
+  local c=$1 py
+  # 실제로 «도는» 파이썬을 고른다 — 윈도의 python3 는 스토어 안내만 찍는 가짜일 수 있다(로컬 스모크가 거기서 죽었다)
+  py=""; local cand; for cand in python3 python; do command -v "$cand" >/dev/null && "$cand" -c 'import sys' >/dev/null 2>&1 && { py=$cand; break; }; done
+  [ -n "$py" ] || die "python 이 없다 — 실제 페이로드 템플릿을 만들 수 없다(대체 페이로드로 재지 않는다)"
+  "$py" "$TEMPLATE_GEN" --rows 750 --out "$WORK/_pose_template.sql" >/dev/null || die "템플릿 생성 실패"
+  docker exec -i "$c" mysql -uroot -p"$PW" lab < "$WORK/_pose_template.sql" 2>/dev/null || die "템플릿 적재 실패"
+  q "$c" "
+    DROP TABLE IF EXISTS lab._tpl;
+    CREATE TABLE lab._tpl (n INT PRIMARY KEY, ts DOUBLE, jc TEXT, fb VARCHAR(255)) ENGINE=InnoDB;
+    INSERT INTO lab._tpl
+      SELECT ROW_NUMBER() OVER (ORDER BY timestamp_sec) - 1, timestamp_sec, CAST(joint_coordinates AS CHAR),
+             NULLIF(feedback_message, '')
+      FROM lab._pose_template;
+    DROP TABLE lab._pose_template;" || die "_tpl 생성 실패"
+
+  cat > "$WORK/_proc.sql" <<'SQL'
+DELIMITER //
+DROP PROCEDURE IF EXISTS lab.load_run //
+CREATE PROCEDURE lab.load_run(IN p_session BIGINT, IN p_rows INT, IN p_secs INT)
+BEGIN
+  DECLARE v_end DATETIME(6);
+  DECLARE v_off INT DEFAULT 0;
+  DECLARE v_ver BIGINT;
+  SET v_end = SYSDATE(6) + INTERVAL p_secs SECOND;
+  WHILE SYSDATE(6) < v_end DO
+    START TRANSACTION;
+      INSERT INTO lab.pose_data_scale (session_id, timestamp_sec, joint_coordinates, sync_rate, is_correct, feedback_message)
+        SELECT p_session, ts, jc, 75.0, 1, fb FROM lab._tpl WHERE n >= v_off AND n < v_off + p_rows;
+      UPDATE lab.session_probe SET version = version + 1, last_active_at = SYSDATE(6) WHERE id = p_session;
+      SELECT version INTO v_ver FROM lab.session_probe WHERE id = p_session;
+    COMMIT;
+    SELECT p_session, v_ver, ROUND(UNIX_TIMESTAMP(SYSDATE(6)) * 1000000);
+    SET v_off = (v_off + p_rows) % (750 - p_rows);
+  END WHILE;
+END //
+DELIMITER ;
+SQL
+  docker exec -i "$c" mysql -uroot -p"$PW" < "$WORK/_proc.sql" 2>/dev/null || die "프로시저 생성 실패"
+}

loadtest/results/binlog-replay-time-2026-11-07/ec2/D0_stage.txt

@@ -0,0 +1,12 @@
+# D0 — 무대 (2026-11-07T20:22:07Z UTC)
+source  version                                  8.0.46
+source  innodb_buffer_pool_size                  2147483648
+source  innodb_flush_log_at_trx_commit           1
+source  sync_binlog                              1
+source  binlog_format                            ROW
+source  binlog_transaction_dependency_tracking   COMMIT_ORDER
+source  max_binlog_size                          1073741824
+BASE_ROWS=10000000 LEVELS_MB=512 2048 8192 REPS=3 CONNS=15 ROWS_PER_TX=25 WORKERS=4
+M2 판별 실제 병렬 설정 (workers · type · preserve_commit_order):
+4	LOGICAL_CLOCK	1
+nproc=4

loadtest/results/binlog-replay-time-2026-11-07/ec2/box.txt

@@ -0,0 +1,7 @@
+instance_type=m6i.xlarge
+4
+               total        used        free      shared  buff/cache   available
+Mem:              15           0          10           0           4          14
+Swap:              0           0           0
+Filesystem      Size  Used Avail Use% Mounted on
+/dev/nvme0n1p1  200G  6.8G  194G   4% /

loadtest/results/binlog-replay-time-2026-11-07/ec2/levels.tsv

@@ -0,0 +1,4 @@
+level_mb	binlog_bytes	files	count	max_id	probe_checksum	write_s
+512	668501071	binlog.000004 binlog.000005 	10310650	16761817	2972404902	41
+2048	2330284850	binlog.000004 binlog.000005 binlog.000006 binlog.000007 	11082875	17719376	130493612	149
+8192	8887414918	binlog.000004 binlog.000005 binlog.000006 binlog.000007 binlog.000008 binlog.000009 binlog.000010 binlog.000011 binlog.000012 binlog.000013 binlog.000014 	14129950	21497749	2855583576	635