---
status: SYNTHETIC_MONGO_THREE_NODE_MAJORITY_FAILOVER_PROVEN_AND_CLEANED
replica_nodes: 3
production_mongo_changed: false
temporary_data_deleted: true
current_continuity: false
---

# MongoDB 3노드 격리 failover rehearsal

## 범위

production MongoDB와 application DB를 읽거나 변경하지 않았다. 설치된 MongoDB 8.2 `mongod.exe`를 사용해 Windows Temp 하위의 새 임시 디렉터리 세 개와 loopback port 57117~57119에 합성 replica set을 구성했다.

## 통과한 절차

1. 세 mongod의 빈 dbPath와 동일 replica set 생성
2. primary 선출 확인
3. 합성 record 1개를 `w:majority`로 기록
4. 선출된 primary 프로세스 종료
5. 남은 두 노드 중 다른 primary 자동 선출 확인
6. 두 번째 합성 record를 `w:majority`로 기록
7. 장애 전 record와 장애 후 record가 모두 보존됐는지 확인
8. 모든 Mongo client와 mongod 종료
9. loopback port 폐쇄 확인
10. Temp 하위 합성 dbPath 자동 삭제

첫 실행은 Windows 비지원 옵션 때문에 mongod가 뜨기 전에 종료됐고, 두 번째는 검증 후 Windows file lock 해제 전 cleanup에서 `EPERM`이 발생했다. 불필요한 옵션을 제거하고 child exit 대기와 bounded cleanup retry를 추가했다. 세 번째 실행에서 전체 절차와 cleanup이 통과했다. 남은 단일 임시 경로는 port와 process 부재 및 Temp prefix를 확인한 뒤 삭제했으며 합성 데이터만 포함했다.

## 의미

현재 서버의 standalone Mongo를 곧바로 replica set으로 바꾼 것은 아니다. 이 결과는 동일 MongoDB binary와 OS에서 3노드 majority election/failover 절차가 동작함을 격리 환경에서 증명한 것이다.

production 전환 전에는 다음이 추가로 필요하다.

- 서로 다른 failure domain PC 3대의 storage latency와 port 정책
- TLS·authorization·keyFile 또는 동급 member authentication
- production logical backup과 복원 증명
- application URI의 replica-set 옵션과 retry/write concern 검증
- 계획정지·rollback plan
- Mongo session store와 Socket.IO shared adapter 검증

증거: `evidence/synthetic-mongo-three-node-failover-redacted.json`
