[PostgreSQL 운영] Day 5: 연결·복제·백업 - 복구 가능한 데이터베이스
이 글은 AI(Claude)의 도움을 받아 작성하고, 작성자가 검토·편집했습니다.
서론: 백업 파일이 아니라 복구 시간을 약속하라
운영 데이터베이스의 목표는 단순히 살아 있는 것이 아니다. 부하 급증에도 연결을 통제하고, 장애 때 정해진 데이터 손실과 시간 안에 서비스를 복구해야 한다. 백업 성공 로그만 있고 복원 훈련이 없다면 그 약속은 검증되지 않았다.
1. 연결 수는 한정된 자원이다
각 연결은 메모리와 백엔드 프로세스 자원을 사용한다. 애플리케이션 인스턴스가 늘면 인스턴스별 풀 크기의 합도 늘어난다.
1
2
전체 잠재 연결 = 인스턴스 수 × 인스턴스별 maximumPoolSize
+ 배치·관리·모니터링 연결
DB 최대 연결을 가득 채우지 말고 운영·복구용 여유를 남긴다. 짧은 트랜잭션이 많은 환경에서는 PgBouncer 같은 외부 풀러도 검토한다.
2. 복제본의 역할과 지연
1
2
Primary: 쓰기와 정합성 기준
Replica: 읽기 확장, 장애 대기, 백업 부하 분리
복제는 보통 비동기 시간차가 있어 방금 쓴 값을 복제본에서 즉시 못 볼 수 있다. 쓰기 직후 읽기, 결제 상태, 권한 변경처럼 최신성이 필요한 흐름은 Primary를 사용하거나 세션 일관성 전략을 둔다.
1
2
3
4
5
관찰:
WAL 생성률
전송·재생 위치 차이
시간 기준 replication lag
replica replay 충돌과 쿼리 취소
3. RPO와 RTO부터 정하기
1
2
3
4
5
RPO (Recovery Point Objective):
최대 허용 데이터 손실 — 예: 5분
RTO (Recovery Time Objective):
최대 허용 복구 시간 — 예: 30분
이 목표가 백업 주기, WAL 보관, 동기 복제 여부, 자동 장애조치 비용을 결정한다. 모든 시스템에 RPO 0·RTO 0을 요구하는 것은 현실적인 설계가 아니다.
4. 논리 백업과 물리 백업
1
2
3
4
5
6
7
pg_dump 같은 논리 백업:
객체·데이터를 SQL/아카이브로 저장
선택 복원·버전 이동에 유리, 대규모 복원은 오래 걸릴 수 있음
물리 Base Backup + WAL:
클러스터 파일과 변경 로그 기반
큰 시스템의 전체 복구·PITR에 적합
PITR(Point-in-Time Recovery)은 Base Backup 이후 WAL을 원하는 시점까지 재생해 실수 직전으로 돌아간다. WAL 보관 누락 하나가 복구 사슬을 끊을 수 있다.
5. 복구 훈련은 별도 환경에서 끝까지
1
2
3
4
5
6
1. 새 인프라 준비
2. 최신 유효 백업 선택
3. 키·설정·확장 모듈 포함 복원
4. 목표 시점까지 WAL 재생
5. 행 수·업무 불변식·애플리케이션 smoke test
6. 실제 소요 시간과 수동 단계 기록
복원한 DB가 기동되는 것과 서비스가 정상인 것은 다르다. 주문 합계, 최신 이벤트, 사용자 로그인 같은 업무 검증을 포함한다.
6. 장애조치의 숨은 문제
Replica를 승격한 뒤 애플리케이션이 새 Primary를 찾고, 이전 Primary가 다시 쓰기를 받지 않게 격리해야 한다. 이중 Primary(split-brain)를 막는 fencing과 DNS/프록시 전환, 연결 재수립을 함께 검증한다.
1
2
3
Failover Runbook:
감지 → 이전 Primary 격리 → 승격 → 라우팅 전환
→ 쓰기 검증 → 복제 재구성 → 사후 분석
7. 시리즈 종합 체크리스트
- MVCC·격리·잠금으로 동시 변경을 예측했다. (Day 1)
- EXPLAIN과 실제 실행 통계로 쿼리·인덱스를 튜닝했다. (Day 2)
- 타입·제약·파티션과 호환 가능한 마이그레이션을 설계했다. (Day 3)
- VACUUM·ANALYZE로 MVCC가 남긴 운영 부채를 관리했다. (Day 4)
- 연결 예산, 복제 지연, RPO/RTO와 복구 훈련을 갖췄다. (Day 5)
시리즈 마무리
PostgreSQL 운영의 핵심은 설정값 암기가 아니라 행 버전·실행 계획·데이터 수명·복구 목표를 연결해 보는 것이다. 빠른 쿼리도 복구할 수 없으면 안전하지 않고, 백업이 있어도 복원 시간이 목표를 넘으면 준비된 것이 아니다. 데이터베이스의 건강은 성능과 정합성, 복구 가능성을 함께 증명할 때 완성된다.