Khyojae · Nov 8, 2026 · Nov 8, 2026 · Nov 8, 2026 · Nov 8, 2026
diff --git a/docs/decisions/rpo-rto-targets.md b/docs/decisions/rpo-rto-targets.md
@@ -1,6 +1,6 @@
 # RPO·RTO 목표 — «얼마나 잃어도 되고, 얼마 안에 돌아와야 하나» 를 정하는 분기점
 
-작성일: 2026-11-07 · 갱신: 2026-11-08 (§8-1 읽기 : 쓰기 비율 가정 추가 · §6-2 측정 둘 — 재생 시간·호스트 상실 RPO)
+작성일: 2026-11-07 · 갱신: 2026-11-08 (§8-1 읽기 : 쓰기 비율 가정 추가 · §6-2 측정 둘 — 재생 시간·호스트 상실 RPO · 측정 셋 — 새 서버 준비·반출 업로드·리플리카 승격)
 상태: 🟡 **방향 확정 · 숫자 미정.** 구성 2(백업 + binlog 서버 밖 반출) 채택, 리플리카 보류, 반동기 미채택
 (2026-11-07 사용자 confirm). **반출 주기·백업 주기·보존 기간 숫자는 아직 없다** — 추천안이 숫자를 정하지
 않았고, 근거 없이 채우지 않는다(§6 Q4·Q6).
@@ -102,7 +102,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 재생 — 1GB 당 약 2분 15초(표준), 병렬이면 약 절반** ([재생 실측](../../loadtest/results/binlog-replay-time-2026-11-07/README.md)) |
-| **호스트·디스크 상실** | EBS 고장, 인스턴스 삭제, `compose down -v`, 랜섬웨어 | 🔴 **binlog 도 같이 사라짐** | 🔴 **정의 안 됨** — «마지막 백업 시점» 인데 백업 주기·위치가 없다 | 새 서버 준비(⬜) + 백업 붓기 — **백업이 서버 밖에 없으면 복구 불가** |
+| **호스트·디스크 상실** | EBS 고장, 인스턴스 삭제, `compose down -v`, 랜섬웨어 | 🔴 **binlog 도 같이 사라짐** | 🔴 **정의 안 됨** — «마지막 백업 시점» 인데 백업 주기·위치가 없다 | 새 서버 준비(**약 140초** — 빈 EC2 → MySQL 쿼리 받음, [실측](../../loadtest/results/server-prep-and-ship-cost-2026-11-08/README.md)) + 백업 붓기 — **백업이 서버 밖에 없으면 복구 불가** |
 
 ⚠️ 복구 시간 실측은 m6i.xlarge · gp3 · 1억 행(합성) 조건이고 «운영에서 N분» 으로 인용 금지(백업 문서 §5).
 ⚠️ 운영 구성(`docker-compose.prod.yml`)에는 백업 설정이 **없다** — 볼륨 `mysql_data` 하나에 데이터·binlog 가 같이 있다(`:53`·`:226`).
@@ -120,12 +120,12 @@ Flyway 마이그레이션의 테이블 기준. «재생성» 칸은 코드·문
 |---|---|---|---|---|---|
 | **0** | 지금 (백업 없음, binlog 같은 디스크) | 🔴 전부 | 🔴 복구 불가 | 없음 | 없음 |
 | **1** | 주기 백업 → 서버 밖(S3 등) | **백업 주기** (예: 하루면 최대 24시간) | 새 서버 + 백업 붓기 (물리 약 174초 · 논리 약 21분 실측, 1억 행) | 없음 (백업 중 정지 42~126ms 실측) | 저장 요금 · 백업 잡 |
-| **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 를 주기적으로 서버 밖에 (회전 때 업로드) | **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)). 새 서버 약 140초 + 붓기 174초 + 하루치 재생을 더하면 **약 6.5~7분**(서로 다른 실험의 합, 사람 시간 제외 — [합산](../../loadtest/results/server-prep-and-ship-cost-2026-11-08/README.md#4-구성-2-의-복구-시간에-대입하면)) | 없음 | 2 와 비슷 · 업로드 잡 · 주기적 `FLUSH BINARY LOGS` — 가정 피크에서 반출 1번 **업로드 0.48~0.71초 · FLUSH 52~56ms**([실측](../../loadtest/results/server-prep-and-ship-cost-2026-11-08/README.md)) |
 | **2'** | 1 + binlog 실시간 스트리밍 (`mysqlbinlog --stop-never` 를 다른 서버에서) | 수 초 | 2 와 같음 | 없음 | 받는 서버 1대 상시 |
-| **3** | 2 + **비동기 리플리카** | 리플리카가 못 받은 양 — 쓰기 부하에서 **약 60초 밀림** 실측(같은 AZ·SQL writer) | **승격 시간** — 밀린 양 적용 + 앱 연결 전환 (⬜ 미측정, 수동이면 사람 시간 추가) | 없음 | 서버 1대 상시 · 복제 감시 |
+| **3** | 2 + **비동기 리플리카** | 리플리카가 못 받은 양 — 쓰기 부하에서 **약 60초 밀림** 실측(같은 AZ·SQL writer) | **승격 시간** — DB 쪽은 밀림 없으면 **약 0.25초**, 약 21초 밀리면 **약 7.8초**(거의 전부 밀린 것 적용, 한 박스 · [실측](../../loadtest/results/replica-promotion-2026-11-08/README.md)). 앱 연결 전환·감지·사람 시간은 ⬜ 미측정 | 없음 | 서버 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)) |
 
-미측정 칸(⬜)은 «0» 이 아니다. 특히 **binlog 재생 시간**은 2·2' 의 RTO 를 정하는 값인데 아직 없다.
+미측정 칸(⬜)은 «0» 이 아니다. 2·2' 의 RTO 를 정하는 binlog 재생 시간·새 서버 준비 시간과 3 의 승격 시간은 11-08 에 쟀다(§6-2).
 
 ---
 
@@ -141,7 +141,8 @@ Flyway 마이그레이션의 테이블 기준. «재생성» 칸은 코드·문
 - [x] **Q3. RPO 를 하나로** → 🟢 **하나로 둔다.** 저장소를 나누지 않는다(§7)
 - [~] **Q4. 호스트 상실 RPO** → 🟢 **구성 2 채택** — 백업 + binlog 를 주기적으로 서버 밖에. RPO = binlog 반출 주기.
       🟡 **반출 주기 숫자는 미정** — 추천안이 정하지 않았다. 고르는 근거는 «주기를 줄일수록 늘어나는 것»
-      (업로드 횟수·`FLUSH BINARY LOGS` 빈도·작은 binlog 파일 수)이고 그건 아직 안 쟀다
+      (업로드 횟수·`FLUSH BINARY LOGS` 빈도·작은 binlog 파일 수) — 11-08 에 쟀다: 가정 피크에서 반출 1번에 업로드
+      0.48~0.71초·FLUSH 52~56ms, 하루 횟수는 60초 주기 1,440번 · 300초 주기 288번(§6-2). FLUSH 가 쓰기를 막는 시간과 요금은 안 쟀다
 - [~] **Q5. 호스트 상실 RTO** → 🟢 **리플리카(3) 보류.** 🟡 목표 숫자는 미정 — 구성 2 의 실제 RTO(백업 붓기 +
       **binlog 재생**)를 먼저 재고, 그 값이 받아들일 수 없을 때 3 을 다시 연다
 - [~] **Q6. 백업 주기·보관 위치·보존 기간** → 🟢 **위치는 서버 밖**(구성 2 의 정의). 🟡 **주기·보존 기간은 미정** —
@@ -164,6 +165,9 @@ Flyway 마이그레이션의 테이블 기준. «재생성» 칸은 코드·문
 |---|---|---|
 | ~~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) |
+| ~~새 서버 준비 시간~~ ✅ 11-08 | 구성 2 RTO 의 첫 단계(§4 의 빈칸) | [준비·업로드 실측](../../loadtest/results/server-prep-and-ship-cost-2026-11-08/README.md) |
+| ~~반출 업로드 비용~~ ✅ 11-08 | Q4 반출 주기의 대가 · «최대 손실 = 주기 + 업로드 시간» 의 업로드 시간 | 같은 실측 §2 |
+| ~~리플리카 승격 시간~~ ✅ 11-08 | 구성 3 이 구성 2 보다 실제로 얼마나 짧은가 — Q5 · R1 | [승격 실측](../../loadtest/results/replica-promotion-2026-11-08/README.md) |
 | 프로세스 재기동 RTO | §4 첫 줄의 빈칸 | 로컬로 충분 (메커니즘) |
 
 ---
@@ -260,3 +264,12 @@ DAU 와 비교해 판단을 닫지 않는다는 원칙과도 어긋난다([[feed
   🔴 300초의 최악이 299.5초로 주기에 붙었다 — «최대 손실 = 주기» 로 약속하려면 업로드 시간을 더해 잡아야 한다.
   쓰기 중 XtraBackup 은 EC2 7판 모두 1회 성공(로컬에선 redo 경합으로 실패한 판 있음).
   다음에 잴 것: 복구 중에만 디스크 기록을 늦춘 재생(다른 세션 제안) · 기준 1억 행 · 새 서버 준비 시간.
+- 2026-11-08: **§6-2 측정 셋 — 새 서버 준비 · 반출 업로드 비용 · 리플리카 승격** (EC2 m6i.xlarge · 8.0.46 · 커밋 `8200b521`·`96677a25`).
+  숫자 결정(Q4·Q5·Q6)은 **여전히 사용자 몫**이고 이 항목은 근거만 붙인다.
+  ① [준비 실측](../../loadtest/results/server-prep-and-ship-cost-2026-11-08/README.md): 빈 EC2 → 복구 대상 MySQL 이 쿼리를 받기까지 **약 140초**(3대, 139.5~142.9초) —
+  그중 bootstrap 약 107~110초. 미리 구운 AMI 경로는 안 쟀다. 구성 2 의 복구 시간을 다른 실험 값과 더하면 **약 6.5~7분**(사람 시간 제외).
+  ② 같은 실측 §2: 가정 피크(초당 45행)에서 반출 1번의 **업로드 0.48~0.51초(60초 주기, 약 5.8MB) · 0.70~0.71초(300초 주기, 약 29MB)**, FLUSH 52~56ms.
+  → 호스트 상실 실험이 남긴 «최대 손실 = 주기 + 업로드 시간» 의 업로드 시간은 이 조건에서 1초 미만. 최대 속도로 쓰면 1GB 파일이 2.3~12초.
+  ③ [승격 실측](../../loadtest/results/replica-promotion-2026-11-08/README.md): DB 쪽 승격 **밀림 없으면 약 0.25초 · 약 21초 밀리면 약 7.8초**(본판 8, 잃은 트랜잭션 0).
+  한 박스 동거라 «잃은 0» 은 다른 박스에선 성립하지 않고, 감지·결정·앱 연결 전환 시간은 빠져 있다.
+  → Q5 를 다시 열지는 «구성 2 의 약 7분이 목표 RTO 안에 드나» 로 가른다 — 목표 숫자는 아직 없다.
diff --git a/loadtest/results/binlog-replay-time-2026-11-07/README.md b/loadtest/results/binlog-replay-time-2026-11-07/README.md
@@ -40,7 +40,7 @@ RUN_ID `replay-ec2-20261107-173709` · 커밋 `7c5e4900` · 19판 전부 검증
 | 백업 붓기 | 물리(XtraBackup) 약 174초 · 논리 약 21분 | 08-13 백업 라운드 — **1억 행**(합성), m6i.xlarge |
 | 백업 붓기 (작은 무대) | 내려받기 2.4~2.6초 + prepare·copy-back 53~57초 | 짝 실험(호스트 상실) — **1,000만 행** |
 | binlog 재생 | 위 표 — 1GB 당 약 2분 15초(M1) | 이 실험 |
-| 새 서버 준비 | ⬜ 안 쟀다 | — |
+| 새 서버 준비 | 약 140초 (빈 EC2 → MySQL 쿼리 받음, 3대) | 11-08 [준비 실측](../server-prep-and-ship-cost-2026-11-08/README.md) — 미리 구운 AMI 경로는 안 쟀다 |
 
 예) DAU 1,000 가정에서 **백업을 하루 한 번** 뜨면, 최악(백업 직전 상실)의 재생 몫은 하루치(약 0.6GB) ≈ **약 1분 20초~1분 35초(M1)**
 (잰 칸은 1.1일치 93~95초), **일주일에 한 번**이면 약 7일치 ≈ 4.1GB ≈ **약 9~10분(M1, 환산)** 이다. 여기에 백업 붓기(1억 행이면 약 3분)와 새 서버
@@ -76,7 +76,7 @@ EC2 에서 몇 시간 돌린 뒤에야 만났을 것들 — 커밋 `7c5e4900`
   ① 재생 중 서버가 죽으면 처음부터 다시 해야 한다 ② 끝나고 설정을 되돌려 운영으로 넘기는 시간은 이 값에 안 들어간다.
   M1 이 트랜잭션당 약 7.6ms(31만 행 ÷ 25행 ÷ 94초)라 «커밋마다 fsync» 만으로 설명되는지는 이 데이터로 갈리지 않는다
 - 기준 1억 행에서 같은 재생 — 조건 2
-- 새 서버 준비 시간 — §2 의 빈칸
+- ~~새 서버 준비 시간 — §2 의 빈칸~~ → 11-08 약 140초([준비 실측](../server-prep-and-ship-cost-2026-11-08/README.md))
 
 ## 6. 재현
 

diff --git a/loadtest/results/hostloss-rpo-2026-11-07/README.md b/loadtest/results/hostloss-rpo-2026-11-07/README.md
@@ -26,7 +26,7 @@ N초였다** — 60초 주기에서 6~51초, 300초 주기에서 109~300초. 언
 
 - **잃은 시간 ≈ «주기 안에서 잃은 시점» × 주기** — 주기 끝 무렵에 잃을수록 많이 잃는다. 최악은 주기 하나만큼이다
 - 🔴 **300초 주기의 최악(299.5초)은 주기에 바짝 붙었다.** 반출은 «닫고 → 올리기» 라서 올리는 동안 쌓인 몫이 더해질 수 있다 —
-  주기를 «최대 손실» 로 약속하려면 **주기 + 업로드 시간** 으로 잡아야 한다(이 무대의 업로드 시간은 따로 안 쟀다)
+  주기를 «최대 손실» 로 약속하려면 **주기 + 업로드 시간** 으로 잡아야 한다(이 무대의 업로드 시간은 따로 안 쟀다 → 11-08 가정 피크에서 반출 1번 0.48~0.71초, [업로드 실측](../server-prep-and-ship-cost-2026-11-08/README.md) §2)
 - 잃은 «시간» 은 쓰기 속도와 무관하지만, 잃은 «행 수» 는 쓰기 속도에 비례한다 — 이 실험의 writer 는 최대 속도(15개 연결,
   초당 수천 행)라 행 수는 DAU 1,000 가정보다 훨씬 크다. **인용은 «초» 로 한다**
 - 「커밋 성공 받은」 = writer 클라이언트(소스 밖 컨테이너)가 COMMIT 응답을 받은 것. 서버가 사라져도 이 기록은 남는다

diff --git a/loadtest/results/replica-promotion-2026-11-08/README.md b/loadtest/results/replica-promotion-2026-11-08/README.md
@@ -0,0 +1,64 @@
+# 리플리카 승격 시간 — 소스가 죽은 순간부터 리플리카가 새 쓰기를 받기까지 (2026-11-08, EC2)
+
+설계 문서: [`../../../docs/decisions/rpo-rto-targets.md`](../../../docs/decisions/rpo-rto-targets.md) §5 구성 3 · §8 R1
+짝 실험: [`../server-prep-and-ship-cost-2026-11-08/`](../server-prep-and-ship-cost-2026-11-08/README.md) §4 (구성 2 의 복구 시간 약 6.5~7분)
+무대: **EC2 `m6i.xlarge` 1대** · gp3 200GB · `ap-northeast-2d` · MySQL **8.0.46**(`mysql:8.0`) · GTID 복제(비동기) ·
+`flush=1`·`sync_binlog=1` · 버퍼풀 1GB · RUN_ID `promote-ec2-20261108-034706` · 커밋 `96677a25` · 10판(버림 2 + 본판 8)
+
+질문: 리플리카(구성 3)를 붙이면 호스트 상실 RTO 가 구성 2 의 약 7분보다 실제로 짧아지나? 문서는 그렇게 가정만 했고 승격 시간을 잰 적이 없다.
+
+## 0. 한 줄
+
+**DB 쪽 승격은 밀린 게 없으면 약 0.25초, 약 21초 밀려 있으면 약 7.8초였다 — 승격 시간은 거의 전부 «밀린 것 따라잡기» 다.**
+구성 2 의 약 7분보다 두 자릿수 짧다. 단 장애를 알아채고 · 승격을 결정하고 · 앱 연결을 바꾸는 시간은 **빠져 있다.**
+
+## 1. 결과 (본판)
+
+| 팔 | 판 | 죽일 때 밀림 | 밀린 트랜잭션 | 받기 중지 | **적용** | 전환 | 첫 쓰기 | **승격 합** | 잃은 트랜잭션 |
+|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|
+| paced | 4 | 0초 | 0 | 48 | 89 | 64 | 49 | **250ms** | 0 |
+| paced | 5 | 0초 | 0 | 47 | 92 | 66 | 49 | **254ms** | 0 |
+| paced | 8 | 0초 | 0 | 48 | 89 | 68 | 50 | **255ms** | 0 |
+| paced | 9 | 0초 | 0 | 45 | 91 | 57 | 47 | **240ms** | 0 |
+| stress | 3 | 22초 | 3,440 | 51 | 7,868 | 74 | 52 | **8,045ms** | 0 |
+| stress | 6 | 22초 | 3,440 | 52 | 7,657 | 76 | 51 | **7,836ms** | 0 |
+| stress | 7 | 20초 | 3,258 | 52 | 7,627 | 75 | 52 | **7,806ms** | 0 |
+| stress | 10 | 21초 | 3,380 | 49 | 7,635 | 89 | 49 | **7,822ms** | 0 |
+
+(버림판: paced 254ms · stress 21초 밀림 → 7,822ms. 단위 없는 칸은 ms)
+
+- **paced(가정 피크 초당 45행)는 밀림이 0 이고 승격이 240~255ms** 다. 이 중 대부분은 rig 의 고정 비용이다 — 구간마다
+  `docker exec` 로 mysql 클라이언트를 새로 띄우는데 한 번에 43~44ms(`exec_ms`)이고, 승격 경로에서 5번 띄운다(약 220ms)
+- **stress 는 승격의 97% 이상이 «적용»(받아 둔 릴레이 로그를 끝까지 적용)** 이다. 밀린 3,258~3,440건을 7.6~7.9초에 적용 —
+  초당 약 430건(건당 25행이라 초당 약 1만 행)
+- 🟡 죽이기 직전 리플리카는 약 21초 밀려 있었는데 따라잡는 데는 약 7.8초였다. 추정: 소스와 리플리카가 한 박스라 부하 중엔
+  CPU 를 나눠 썼고, 소스가 죽은 뒤엔 리플리카가 혼자 썼다(§3-3). 확인하지 않았다
+- 잃은 트랜잭션은 10판 모두 0 — 밀린 것은 «받았지만 아직 적용 안 한» 것이었고, 받는 쪽은 소스를 따라가 있었다(§3-2)
+
+## 2. 구성 2 와 나란히
+
+| | 구성 2 (백업 + binlog 반출) | 구성 3 (+ 비동기 리플리카) |
+|---|---|---|
+| DB 가 다시 쓰기를 받기까지 | **약 6.5~7분** (새 서버 140초 + 붓기 174초 + 하루치 재생 80~95초, [합산](../server-prep-and-ship-cost-2026-11-08/README.md#4-구성-2-의-복구-시간에-대입하면)) | **0.25~8초** (이 실험) |
+| 빠진 것 | 사람 시간 · S3 내려받기 | 사람 시간 · 앱 연결 전환 |
+
+→ 사람 시간을 같은 크기로 더해도 구성 3 이 몇 분 짧다. 그 몇 분이 **목표 RTO 안에 들어가야 하는지**가 Q5 의 결정이다(이 실험은 정하지 않는다).
+
+## 3. 조건 — 인용할 때 떼면 안 되는 것
+
+1. **사람·앱 시간 제외.** 장애 감지 · 승격 결정 · 앱 연결(DataSource URL·DNS) 전환은 안 쟀다. 이 값은 «스크립트로 자동화했을 때의 하한» 이다
+2. **비동기 복제인데 잃은 게 0 인 건 한 박스라서다.** 소스와 리플리카가 같은 박스의 컨테이너라 전송이 거의 즉시였다. 실제로 다른 박스·다른
+   AZ 에 두면 «아직 못 받은» 몫이 생기고 그건 잃는다 — 그 양은 [다른 AZ 복제 실험](../replication-aws-cross-az-2026-09-02/README.md)을 본다
+3. **한 박스 동거.** 부하 중 CPU 를 나눠 써서 밀림이 두 박스일 때와 다를 수 있고, 소스가 죽은 뒤엔 리플리카가 CPU 를 다 쓴다. 두 박스의 승격 시간은 안 쟀다
+4. «죽음» 은 `docker kill` 이다 — 프로세스·네트워크가 한꺼번에 사라지는 호스트 상실의 대리
+5. 리플리카 적용 스레드 수는 기본값(8.0.46 은 `replica_parallel_workers` 기본 4)이고 판마다 기록하지는 않았다
+6. paced 는 문서 §8-1 **가정** 피크(측정 아님), stress 는 4개 연결이 240초간 최대 속도 — 상한 확인용이지 운영 값이 아니다
+
+## 4. 재현
+
+```bash
+bash launch.sh <커밋 SHA>                         # EC2 1대. 결과는 S3 의 RUN_ID 아래
+OUT=$PWD/_out STRESS_SECS=60 PACED_SECS=30 bash promote.sh   # 로컬 스모크
+```
+
+산출물: `ec2/trials.tsv`(판 1줄) · `ec2/CONDITIONS.txt` · `ec2/run.log` · `ec2/box.txt` · `ec2/round.log`.
diff --git a/loadtest/results/replica-promotion-2026-11-08/ec2/CONDITIONS.txt b/loadtest/results/replica-promotion-2026-11-08/ec2/CONDITIONS.txt
@@ -0,0 +1,7 @@
+# 승격 실험 조건 (2026-11-08T03:49:25+00:00)
+mysql image      : mysql:8.0
+server opts      : --log-bin=binlog --binlog-format=ROW --gtid-mode=ON --enforce-gtid-consistency=ON --innodb-flush-log-at-trx-commit=1 --sync-binlog=1 --innodb-buffer-pool-size=1G --innodb-redo-log-capacity=2G
+replica workers  : (판마다 시작 후 기록하지 않음 — 기본값, 8.0.46 은 replica_parallel_workers 기본 4)
+trials           : paced stress stress paced paced stress stress paced paced stress (앞 paced·stress 각 첫 판은 버림)
+paced            : 45 행/초(문서 §8-1 가정) 120s · stress: 4 연결 240s
+제외             : 감지·판단·앱 연결 전환 시간
diff --git a/loadtest/results/replica-promotion-2026-11-08/ec2/box.txt b/loadtest/results/replica-promotion-2026-11-08/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% /