장애 전에 준비하는 구조

HA는 복구 절차보다 먼저, 장애 순간에 바로 넘겨받을 대기 경로를 설계하는 아키텍처입니다

평소에는 Primary가 쓰기를 처리하고 Standby가 변경 로그를 따라갑니다. 장애가 감지되면 같은 복제 경로를 바탕으로 Standby를 새 Primary로 승격해 서비스 중단과 데이터 손실 범위를 줄입니다.

운영 기준 복제 경로 + 장애 감지 + 자동 승격 이 세 축이 준비되어 있어야 "복구 후 재가동"이 아니라 "중단 없이 계속 서비스"에 가까워집니다.

공유 구조를 먼저 보면 HA가 왜 빠른지 보입니다

정상 운영과 장애 전환은 따로 놀지 않습니다. 같은 데이터 흐름을 평소에는 복제로, 장애 시에는 승격으로 사용합니다.

서비스 경로
앱 · 로드밸런서 쓰기 요청을 현재 Primary로 보냄
→
Primary 트랜잭션 처리와 최신 상태 유지
복제 경로
Redo / Binlog / WAL 변경 내용을 계속 전달
→
Standby · Replica 동기 또는 비동기로 상태를 따라감
장애 시
헬스 체크 · 오케스트레이터 장애 판단 후 승격 절차 시작
→
새 Primary 트래픽을 다시 연결해 서비스 계속
복제 모드가 동기 쪽에 가까울수록 데이터 보호는 강해지고, 비동기 쪽에 가까울수록 평상시 성능은 좋아지지만 장애 순간 손실 가능 범위는 커집니다.

DBMS마다 이름은 달라도 보는 축은 같습니다

무엇을 쓰든 먼저 봐야 할 것은 로그 전달 방식, 동기화 수준, 승격 주체입니다.

Oracle
Data Guard Redo를 Standby로 보내고 보호 모드로 일관성 수준을 조정합니다.
MySQL
Replication + 자동 전환 도구 Binlog 복제를 기반으로 MHA나 Orchestrator가 승격을 관리합니다.
PostgreSQL
Streaming Replication WAL 스트리밍과 Patroni 같은 도구로 리더 선출과 Failover를 자동화합니다.
학습 포인트

HA의 본질은 복구 절차를 길게 적어 두는 것이 아니라, 장애 전에 어떤 로그가 어디까지 복제되고 누가 언제 승격을 결정하는지 명확히 정해 두는 것입니다.