Repository navigation
measure(rpo-rto): binlog 재생 1GB 당 약 2분 15초 · S3 반출 주기 N초면 최악 ≈ N초 손실 (EC2) - #842
Merged
Merged
Conversation
…운드 준비
RPO·RTO 분기점(rpo-rto-targets.md §6-2)이 «재야 정할 수 있다» 고 남긴 두 값을 재는 rig.
binlog-replay-time-2026-11-07/
- replay_sweep.sh: 백업 이후 binlog 를 양별(기본 0.5/2/8GB)로 재생. M1 mysqlbinlog|mysql ·
M2 릴레이 로그 + 병렬 SQL 스레드. 판마다 같은 기준 datadir 사본에서 복구 서버를 새로 띄우고
COUNT·MAX(id)·CHECKSUM 으로 검증
- _writer_common.sh: 두 rig 공용 writer. 페이로드는 실제 33 랜드마크 JSON(≈2KB/행, 사용자 결정) —
'{}' 로 GB 를 재면 행 수가 수십 배 부풀어 재생 시간이 실제보다 크게 나온다
- ec2_userdata.sh: 무인 라운드 공용 user-data — bootstrap 을 커밋 SHA 로, 감시견·10분 업로드·terminate
hostloss-rpo-2026-11-07/hostloss_rpo.sh: 쓰는 도중 소스 컨테이너·볼륨을 통째로 지우고 S3 만으로 복구,
writer 클라이언트가 받은 «커밋 성공» 과 복구된 version 을 대조해 잃은 양(RPO)을 센다. 반출 주기 60/300초.
스모크가 걸러낸 rig 결함(EC2 에서 몇 시간 뒤에야 만났을 것들):
- 헬퍼 컨테이너가 root 가 아니라 datadir 를 못 읽음 → --user 0
- M2 완료 판정을 릴레이 파일명으로 해서 영영 안 끝남(적용 끝난 릴레이 파일이 지워진다) → 원본 binlog 좌표로
- SELECT 1 대기가 엔트리포인트 임시 서버에 붙음 → skip_networking=0 대기
- 쓰기 중 XtraBackup 이 redo 를 못 따라감 → redo 2G + 3회 재시도, 시도 횟수를 결과 칸으로
- 기준 사본의 시딩 binlog 를 반출기가 먼저 올림 → RESET MASTER + 판 시작 파일부터
- writer 를 소스 컨테이너 안에서 돌려 상실 때 «커밋 성공» 기록이 같이 사라짐(받은 수 < 복구 수) → 소스 밖 클라이언트
- 반출기를 백업 뒤에 켜서 첫 파일이 커짐 → 판 시작부터 상시
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…(EC2) rpo-rto-targets.md §6-2 가 «재야 정할 수 있다» 고 남긴 두 값을 m6i.xlarge · 8.0.46 에서 쟀다. 숫자 결정은 사용자 몫. binlog 재생 (19판 전부 검증 일치): - 표준(mysqlbinlog|mysql) 1GB 당 135~141초, 양에 거의 정비례. 0.67/2.33/8.89GB → 93~95/318~322/1,187~1,212초 - 병렬(SQL 스레드 4개) 적용은 약 2배 빠름, 릴레이 로그 준비 포함 1.6~1.9배 - writer 는 실제 JSON(≈2KB/행) — DAU 1,000 가정이면 세 단계 ≈ 1.1/4/15일치 호스트 상실 (7판 전부 S3 만으로 끝까지 복구): - 잃은 시간 ≈ 주기 안에서 잃은 시점 × 주기. 60초 주기 6.3~51.0초, 300초 주기 108.9~299.5초 - 300초의 최악이 주기에 붙음 → «최대 손실 = 주기» 로 약속하려면 업로드 시간을 더해야 한다 - XtraBackup 은 EC2 에서 7판 모두 1회 성공 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
 |
…-time # Conflicts: # docs/decisions/rpo-rto-targets.md
… 살려 정리 직전 머지 커밋에서 해결 스크립트가 실패했는데 이어지는 커밋이 그걸 확인하지 않아 충돌 표시가 그대로 들어갔다. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
요약
RPO·RTO 분기점(
docs/decisions/rpo-rto-targets.md§6-2)이 «재야 정할 수 있다» 고 남긴 두 값을 EC2(m6i.xlarge · MySQL 8.0.46)에서 쟀다. 숫자 결정(반출 주기·백업 주기·리플리카 필요 여부)은 하지 않았다 — 근거만 붙인다.binlog 재생 시간 (구성 2 의 RTO)
46초 (+준비 913초)156초 (+2632초)621초 (+124131초)표준은 1GB 당 135~141초로 양에 거의 정비례. 19판 전부 검증 일치.
호스트 상실 (구성 2 의 RPO)
쓰는 도중 소스를 통째로 지우고 S3 만으로 복구(7판 전부 성공). 잃은 시간 ≈ «주기 안에서 잃은 시점 × 주기» — 60초 주기 6.3
51.0초, 300초 주기 108.9299.5초. 300초의 최악이 주기에 붙어서, 최대 손실을 주기로 약속하려면 업로드 시간을 더해야 한다.로컬 스모크가 걸러낸 rig 결함 7가지
커밋
7c5e4900메시지 참고 (헬퍼 권한 · M2 완료 판정 · 임시 서버 오판 · XtraBackup redo 경합 · 시딩 binlog 반출 · writer 기록 유실 · 반출기 시작 시점).변경
loadtest/results/binlog-replay-time-2026-11-07/— rig · 공용 writer · EC2 user-data · 결과loadtest/results/hostloss-rpo-2026-11-07/— rig · 결과docs/decisions/rpo-rto-targets.md— §4·§5 미측정 칸에 값, §6-2 완료 표시, 결정 로그조건
기준 1,000만 행(1억 행 아님) · 복구 서버도 flush=1/sync_binlog=1 · 같은 리전 S3 · 새 서버 준비 시간 미측정. 인스턴스 두 대는 스스로 terminate 됐고 남은 볼륨 없음.
🤖 Generated with Claude Code