DongHyeonkaandClaude Opus 5
df5af95cb3
Dropping the schema left Keycloak serving realm metadata and JWKS from its Infinispan cache, so the front door stayed at 200 while only the paths that read the database failed. That is a different shape from A-2, where the connection itself broke and readiness pulled the pods out of the Service; here the connection is fine and the tables are simply gone, which the health check does not notice. Restoring the pg_dump took one second with zero errors and no pod restart, and the row counts matched the backup exactly, sessions included. The real RPO is the backup interval plus the synchronous_commit loss measured in A-3, and this dump sits in the host's /tmp, which is the same failure domain as the thing it protects. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
D-1 — 백업·복구 리허설 증거
2026-09-04 16:55–17:05 KST
해설: docs/experiment-d1-backup-restore.md
| 파일 | 무엇을 보여주는가 |
|---|---|
01-backup.txt |
pg_dump --clean --if-exists — 395KB · 101 테이블 · 세션 데이터 포함 |
02-destruction.txt |
DROP SCHEMA public CASCADE → 테이블 0개. 그런데 외부는 HTTP 200 — Keycloak 이 realm 캐시로 서빙한다 |
03-restore.txt |
깨지는 것과 안 깨지는 것(certs 200 / well-known 500 / 토큰 400) · 복구 1초 · 오류 0건 · 데이터 완전 일치 · 재시작 0회 |
핵심 세 줄
- 데이터베이스를 통째로 비웠는데 서비스가 200 을 냈다. 헬스체크는 "DB 가 살아 있다"만 보고 "데이터가 있다"는 안 본다.
- 복구는 1초, 오류 0건, 재시작 불필요. 절차가 맞다는 것은 확인됐다.
- RPO 는 두 겹이다 — 백업 주기 + A-3 에서 측정한
synchronous_commit OFF손실. 그리고 이번 덤프는 호스트의/tmp에 있어 같은 장애 도메인이다.