[Test] WAL 완료 확인 후 성공 응답 65건의 DB·GCS 복구 재검증

[Gimini-3]

목적

Closes #563

#564에서 필요한 WAL 보관·외부 복사 완료를 확인하는 계약을 추가했습니다. 이번에는 #562와 같은 65건 부하를 실제 OpenSQL·GCS에서 다시 복구해 개선 효과를 확인했습니다.

마지막 외부 보존 완료 구간 60건은 전부 복원됐고 그 구간의 누락은 0건입니다. 전체 성공 응답 65건 중 60건 복원, 마지막 전송 뒤 5건 누락입니다. 전체 무손실이나 운영 RPO 0으로 표현하지 않습니다.

테스트 환경

• Run ID: DR-RESTORE-20261018-FRESHNESS1. 모든 원장 시각은 UTC(+00:00)입니다.
• 실제 OpenSQL 17.8의 시험 소유 논리 DB, Barman 3.19.1, 시험 전용 비공개 GCS 버킷 3개, 실제 Spring Boot JVM·BGE-M3·시험 Valkey를 사용했습니다.
• 이전과 같은 Java 소스 3bff887a5f6abdf4155957a658599f8f0366a141와 동일 SHA-256 JAR입니다. WAL 대기 함수는 #564에서 병합한 코드이며 실행 전에 소스 해시를 고정했습니다.
• 복원은 네트워크 없는 Barman 도구로 준비하고 라이선스가 있는 기존 비동기 replica 호스트의 별도 PGDATA에서 수행했습니다. 별도 물리 클러스터를 새로 만든 시험은 아닙니다. 원래 replica 프로세스만 잠시 중단하고 1,800초 자동 원복을 준비했으며, Primary·동기 Standby는 유지했습니다.
• 공개 설정과 개인 환경 파일은 보존했습니다. Ollama 생성 답변·공개 트래픽 전환·OpenProxy 경로·전체 사이트 소실은 제외했습니다.

테스트 방법

1. 완료 문서 4건과 실제 모델 응답을 기다리는 Job 1건을 준비했습니다. 해당 JVM을 SIGKILL한 뒤 Worker=false로 재기동해 중단 상태를 보존했습니다. 준비 검사 24/24와 새 기준 백업 DONE·pg_verifybackup를 확인했습니다.
2. 추가 업로드 60건을 목표 11초 간격으로 보내고 300초 주기의 외부 전송을 두 번 실행했습니다. 전송 뒤 남은 요청도 보내고 추가 백업으로 보충하지 않았습니다.
3. 전환한 정확한 WAL이 실제 Barman 보관소에 도착할 때까지 기다리고, 외부의 고정 generation을 실제 재읽어 SHA-256·크기를 대조했습니다. 다음 구간 진행에는 합성 restore point를 썼습니다. 공개 대기 함수와 실제 Docker Barman 명령을 연결했고, 원격 단계는 기존 REST publisher를 썼습니다. 전체 gsutil CLI 실행으로 표현하지 않습니다.
4. T0 2026-10-18T14:36:26.952847+00:00에 원본 API·수집기·터널 중단을 시작하고 2026-10-18T14:36:37.353+00:00에 외부 입력을 동결했습니다. 복구 도구의 원본 DB 연결은 비활성화하고 원본 객체 추가 취득도 차단했습니다.
5. Worker·Flyway·수선·버킷 재연결 전에 최초 상태를 감사했습니다. 마지막 확인 구간 ACK의 누락이 있으면 활성화를 거부하는 조건을 통과한 후에만 복원 JVM·Worker를 켰습니다.
6. 다운로드·검색·같은 Job 재개·새 업로드·인덱싱·새 다운로드를 확인하고 최종 정합성을 감사했습니다. 원래 클러스터·공개 설정을 확인하고 시험 DB·역할·프로세스·컨테이너·키·버킷을 정리했습니다.

변경 파일은 이번 실행의 보고서·개별 증거·집계뿐입니다. 기존 애플리케이션이나 공개 설정은 변경하지 않았습니다.

관측 결과

항목	이전 #562	이번 재시험
성공 응답	65건	65건
마지막 전송 원본	60건, 필요한 WAL 완료 미검사	60건, 정확한 WAL 외부 확인
최초 복원	33건	60건
DB 누락	32건	5건
마지막 전송 구간까지의 누락	원본 60건 중 27건	0건
마지막 전송 뒤 요청 누락	5건	5건
관측한 마지막 연속 ACK~T0 간격	412.061초	113.978초

기능	T0부터 완료까지	결과
download	162.9초	통과
search	178.447초	통과
job_resume	234.365초	통과
new_upload	241.423초	통과
new_indexing	910.719초	통과
new_download	912.801초	통과

중단 Job은 같은 Job 1개·Attempt 2회·INDEXED를 확인했습니다. 실제 복원 서버는 마지막 외부 WAL 끝까지 재생했습니다. 최종 감사·정리 결과와 모든 개별 원장·전송·스냅샷은 상세 결과와 증거에 있습니다.

검증 과정에서 확인된 사항

• 실행 판정은 PASS입니다. 전체 65건을 무손실로 복구한 결과가 아닙니다. 마지막 전송 뒤 요청은 원본이 성공했어도 외부 입력에 포함되지 않아 손실될 수 있습니다.
• 개선한 것은 필요한 WAL이 외부에 도착하기 전 성공으로 취급하던 판정 공백입니다. 기존 인자 없는 복사 타이머·health는 그대로 복사 최근성 검사이고 운영 최신성 보장이 아닙니다.
• 최초 감사와 구간 누락 판정이 기록된 뒤 Worker를 켰습니다. 복원본의 버킷 참조 변경과 Flyway·Job 재개로 최초 상태를 덮어쓰기 전에 증거를 보존했습니다.
• 실제 요청 간격은 전송 대기·이후 따라잡기로 달라졌습니다. 같은 문서 수·생성기·목표 간격·전송 주기·JAR을 유지했지만, 실제 시간과 실행별 marker·ID는 다릅니다. 두 회차를 엄밀한 처리량 벤치마크로 취급하지 않습니다.
• 원본 접근 차단은 리스너 중단·네트워크 없는 도구·클라이언트 가드입니다. 클라우드 IAM 거부나 원본 사이트 파괴를 시험한 것은 아닙니다.
• 시험 소유 버킷 3개와 임시 인증 복사본은 정리했고 사용자 원본 버킷·기존 OAuth·개인 환경 파일은 보존했습니다. GCS soft-delete 세대가 남을 가능성과 즉시 물리 삭제는 구분합니다.
• 앞선 수신 역할 준비 중단은 #564의 별도 LIVE1로 남겼습니다. 이번 전체 복구 실행과 섞어 통과로 계산하지 않았습니다. 공개 증거는 사전 비식별 검사와 해시 대조 후 선택한 파생물만 게시합니다.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Repository: DocGrid/docgrid/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 214c8150-929f-43f8-83b4-67185c52904a

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Gimini-3]

실행 결과·증거 검토 기록

검토 대상 head: c6456cc9ed585c21220625f73336d743734dd1ec

작성자가 전체 추가 파일·원장·집계를 대조했습니다. 별도 사람의 승인이나 자동 리뷰 완료라고 표현하지 않습니다. CodeRabbit의 자동 검토는 저장소 조건 때문에 건너뛰었습니다.

• 초기 65건 성공 응답은 기능 5건·손실 관측 60건입니다. 최초 감사는 RESTORED 60건·DB_MISSING 5건이며 HTTP 오류·결과 불명은 0건입니다.
• 마지막 전송 구간 60건 모두 원래 ID·관계·외부 원본 해시·generation까지 복원됐습니다. 이후 5건은 DB와 원본 모두 외부 입력 범위 밖입니다. 전체 무손실로 보고하지 않았습니다.
• 원장 순서는 복원 312 → 최초 감사 313 → 구간 누락 검사 314 → 복원본 버킷 연결 315 → 활성화 319입니다. 최초 스냅샷의 Worker/Flyway/repair/source_access가 모두 false인지 확인했습니다.
• 동일 JAR을 사용했고 마지막 외부 WAL의 끝과 실제 replay LSN 0/31000000이 일치합니다. 이후 새 쓰기 LSN과 구분했습니다.
• 기능 6/6, 중단 Job 1개·Attempt 2회·INDEXED, 최종 61문서의 미완료·중복·누락 벡터 0건을 개별 증거와 대조했습니다.
• 새 인덱싱은 T0+910.719초, 마지막 다운로드는 T0+912.801초입니다. 이전보다 많은 작업을 복원해 동시성 2로 처리했으므로 성능 개선·회귀 수치로 일반화하지 않았습니다.
• 공개 설정 보존·원래 클러스터 복귀·소유 자원 제거를 확인했습니다. 개인 env 2개 일치, 원래 작업의 tracked 변경 0·기존 untracked 28·HEAD/branch 유지, 기존 BGE 실행 유지도 확인했습니다.
• 공개 증거 50개 SHA-256 일치·민감 패턴 0건·깨진 상대 링크 0건입니다. 이번 diff는 새 결과 디렉터리에 한정되며 기존 개인 파일·공개 설정·애플리케이션 변경이 없습니다.
• 격리 PGDATA가 기존 비동기 replica 호스트를 재사용했다는 점, 원본 가드가 IAM 거부 시험이 아니라는 점, 실제 GCS REST 실행과 gsutil CLI 계약 단위 시험의 차이를 명시했습니다.

현재 증거 검토에서 병합을 막는 불일치는 발견하지 못했습니다. 필수 CI 완료와 현재 head를 확인한 후 병합합니다.