페일오버 훈련 / 계획된 역할 전환

역할 변경 유형(계획된 스위치오버, 긴급 페일오버, 운영 환경을 건드리지 않는 훈련)을 식별하고 각 시나리오에 맞는 올바른 명령 순서와 검증 단계를 제공하는 의사결정 트리. 목표: 계획된 전환은 데이터 손실 없이, 긴급 시에는 최소 손실로, 훈련에서는 다운타임 없이 전환할 준비를 갖추는 것.

무엇을 하려는가?

역할 변경의 상황을 선택한다. primary가 정상인 상태에서 계획된 전환(유지보수/마이그레이션)을 하는가, primary가 실제로 중단되어 긴급 전환이 필요한가, 아니면 운영 환경을 건드리지 않고 훈련/준비 상태 검증을 하는가?

• 계획된 스위치오버(primary 정상)
• 긴급 페일오버(primary 중단)
• 훈련 / 준비 상태 테스트(운영 환경 미변경)

계획된 전환 — 먼저 준비되었는가?

계획된 스위치오버의 목표는 데이터 손실 제로다. 이를 위해 전환 전에 복제본이 primary를 따라잡았고(지연 ~0) 정상인지 확인해야 한다. 아래 명령으로 지연을 확인하고, 지연이 0에 가까우면 전환 단계로 진행한다.

SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#;   -- DG: SELECT name, value FROM v$dataguard_stats WHERE name LIKE '%lag%';

• 지연이 0에 가깝다, 전환 준비 완료
• 지연이 큼 — 먼저 동기화를 기다림

계획된 스위치오버(데이터 손실 없는 통제된 전환)

primary와 standby가 정상이고 동기화된 상태에서 통제된 방식으로 역할을 교체한다. 순서가 중요하다: 쓰기를 중지하고, 남은 변경 사항이 standby에 도달했는지 확인한 뒤, 역할을 넘기고 애플리케이션을 새 primary로 전환한다.

긴급 전환 — primary가 정말 중단되었는가?

페일오버를 강제하기 전에 primary에 정말 접근할 수 없는지 확인하고 split-brain 위험을 평가한다. primary가 실제로 살아 있다면(예: 일시적인 네트워크 장애) 강제 전환은 쓰기 가능한 두 개의 별도 사본(split-brain)을 만든다. 또한 지연을 비교해 가장 최신 상태의 standby를 선택한다.

-- try to reach the primary: tnsping primary_db; and on the standby: SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#;

• 예, primary가 중단됨 — 전환을 강제한다
• 확실하지 않음 / primary가 복귀할 수 있음

긴급 페일오버(primary 중단, 데이터 손실 위험이 있는 전환)

primary에 접근할 수 없고 복귀를 기다릴 수 없다. standby를 강제로 승격해야 하며, 비동기 복제에서는 마지막 트랜잭션 일부가 손실될 수 있다. 우선순위는 서비스 복구이며, 이후 손실 구간을 파악하고 이전 primary를 안전하게 복귀시킨다.

훈련 / 준비 상태 테스트(운영 환경을 건드리지 않고 검증)

실제 전환 없이 페일오버 준비 상태를 입증한다. 운영 환경에 영향을 주지 않고 복제본 상태, 허용 가능한 지연, 애플리케이션 전환 가능 여부를 검증한다. 선택적으로 격리된 사본에서 실제 스위치오버를 리허설한다.