DB Failover 작업 이해하기 - 실무 가이드

hoho·2025년 7월 3일

들어가며

실무에서 갑자기 "DB failover 작업이 필요하다"는 요청을 받았을 때, 데이터베이스 지식이 부족하면 당황스럽기 마련입니다. 이 포스트에서는 실제 업무에서 마주칠 수 있는 DB failover 상황을 통해 개념과 대응 방법을 정리해보겠습니다.

실제 상황 예시

다음과 같은 요청이 왔다고 가정해봅시다:

DNS: userservice-live.mysql.company.net
DB 구성: web-db01(192.168.1.10), web-db02(192.168.1.11) / VIP: 192.168.1.100

위 LIVE DB 장비가 OS 스토리지 교체로 인해서 failover 작업이 필요하다고 합니다. 
7월 9일에 failover 진행하여도 되는지 확인 가능하실까요? failover시에 DB 순단 발생합니다..!

DB 구성 이해하기

고가용성(HA) 구성

위 요청에서 보이는 DB 구성을 분석해보면:

Primary DB: web-db01 (192.168.1.10)
Secondary DB: web-db02 (192.168.1.11)
VIP (Virtual IP): 192.168.1.100

이는 전형적인 Master-Slave 구성의 고가용성 데이터베이스입니다.

VIP(Virtual IP)의 역할

VIP는 가상 IP로, 현재 Primary DB에 연결되어 있습니다. 애플리케이션은 개별 DB 서버가 아닌 이 VIP를 통해 DB에 접속합니다.

애플리케이션 → VIP (10.140.14.147) → Primary DB (gmscms01)

Failover란?

Failover는 Primary DB에서 Secondary DB로 서비스를 전환하는 작업입니다.

작업 전/후 비교

작업 전:

애플리케이션 → VIP → Primary DB (gmscms01)
                     Secondary DB (gmscms02) [대기 상태]

작업 후:

애플리케이션 → VIP → Secondary DB (gmscms02) [새로운 Primary]
                     Primary DB (gmscms01) [작업 중/복구 중]

왜 Failover가 필요한가?

하드웨어 유지보수

스토리지 교체: 디스크 교체, 스토리지 업그레이드
서버 유지보수: OS 업데이트, 하드웨어 점검
네트워크 작업: 스위치 교체, 네트워크 구성 변경

장애 대응

Primary DB 장애: 하드웨어 실패, 소프트웨어 오류
성능 이슈: 과부하로 인한 서비스 품질 저하

순단 시간 이해하기

일반적인 순단 시간

유형	소요 시간	특징
자동 Failover	1~3분	잘 구성된 HA 환경
수동 Failover	5~15분	관리자가 직접 전환

순단이 발생하는 이유

VIP 전환 시간: Primary → Secondary로 가상 IP 이동
DNS 캐시 갱신: 클라이언트의 DNS 캐시 만료 대기
애플리케이션 재연결: DB 연결 끊김 → 재연결 시간
데이터 동기화 확인: Secondary DB의 데이터 일관성 체크

실무에서의 대응 방법

1. 상황 파악하기

요청을 받았을 때 다음 사항들을 확인해야 합니다:

확인 필요 사항:
1. 예상 작업 시간 (DB 순단 시간)
2. 작업 시간대 (새벽/점심/저녁 등)
3. Rollback 계획 (문제 발생 시 복구 방안)
4. 사전 데이터 동기화 상태 확인 완료 여부

2. 서비스 영향도 검토

순단으로 인한 서비스 중단: 몇 분간 서비스 불가
관련 서비스 확인: 해당 DB를 사용하는 모든 서비스
사용자 영향: 피크 시간대 vs 비피크 시간대

3. 답변 템플릿

안녕하세요.

gamesearch-live DB failover 작업 건 검토 완료했습니다.

**승인 사항:**
- 7월 9일 failover 작업 진행 승인합니다

**확인 사항:**
- 정확한 작업 시간을 알려주시면 관련 팀에 사전 공지하겠습니다
- 예상 순단 시간과 서비스 영향 범위를 미리 안내 부탁드립니다

**협조 요청:**
1. 작업 시작 전 사전 알림 (최소 1시간 전)
2. 작업 진행 중 실시간 상황 공유
3. 작업 완료 후 결과 보고

**우리 쪽 준비사항:**
- 관련 서비스 팀에 사전 공지 예정
- 작업 시간 동안 모니터링 강화

작업 일정이 확정되면 다시 한 번 연락 부탁드립니다.

감사합니다.

추가 고려사항

모니터링 강화

작업 전/중/후 모니터링: 서비스 상태, DB 성능 지표
알림 설정: 문제 발생 시 즉시 대응 가능하도록

커뮤니케이션

사전 공지: 관련 팀, 사용자에게 미리 알림
실시간 소통: 작업 진행 상황 공유
사후 보고: 작업 완료 후 결과 공유

마무리

DB failover는 고가용성 환경에서 필수적인 작업입니다. 처음에는 복잡해 보일 수 있지만, 기본 개념을 이해하고 체계적으로 접근하면 안전하게 수행할 수 있습니다.

핵심은 언제, 얼마나 오래, 어떻게 복구할지를 명확히 하는 것입니다. 이를 통해 서비스 영향을 최소화하면서도 안정적인 운영을 유지할 수 있습니다.

참고 자료:

MySQL High Availability 공식 문서
Database Failover Best Practices

태그: #Database #Failover #HighAvailability #MySQL #실무가이드

hoho

이전 포스트

Apache Spark 실행 구조 정리(내부 구조 기반)

다음 포스트