DB 복제 구성의 스플릿 브레인 자동 복구 실패

증상 확인: 스플릿 브레인 발생 후 자동 복구 메커니즘이 작동하지 않음

데이터베이스 고가용성(HA) 구성을 운영 중, 주 서버와 대기 서버 간의 네트워크 연결이 일시적으로 단절된 후 복구되었을 때 발생하는 전형적인 문제입니다. 증상은 다음과 같습니다. 네트워크 단절 시 양측 노드가 각자 자신을 주 서버로 승격시키고, 네트워크 복구 후에도 이 상태가 지속됩니다. 클러스터 관리 소프트웨어(예: Pacemaker, Windows Server Failover Cluster)의 자동 복구 스크립트나 펜싱(fencing) 메커니즘이 실패하여, 양쪽 서버에서 동시에 쓰기 작업이 가능한 ‘스플릿 브레인’ 상태가 수동 개입 없이 해결되지 않습니다. 이로 인해 애플리케이션은 데이터 불일치, 쓰기 실패, 또는 연결 오류를 보고합니다.

원인 분석: 왜 자동 복구는 실패하는가

스플릿 브레인은 물리적 또는 네트워크 장애로 인해 발생하지만, 자동 복구 실패의 근본 원인은 대부분 구성 오류와 예측하지 못한 장애 시나리오에 대한 대비 부족입니다. 첫째, 펜싱 장치(IPMI, iDRAC, 스토리지 차단 등)의 구성이 불완전하거나 신뢰할 수 없어, 문제 노드를 강제로 격리시키지 못합니다. 둘째, 쿼럼(Quorum) 정책이 제대로 설정되지 않아, 노드 과반수 확보 실패 시 자동으로 안전 모드로 전환되지 않습니다. 셋째. 네트워크 복구 후의 자동 재조정 스크립트가 복잡한 데이터 동기화 충돌을 처리할 수 없거나, 복제 지연(replication lag)이 임계값을 초과하여 안전한 자동 장애 복구(failback)를 보장할 수 없습니다. 구형 시스템일수록 하드웨어 펜싱 장치의 호환성 문제나 펌웨어 오류가 원인일 확률이 높습니다.

해결 방법 1: 즉각적인 수동 개입으로 위기 확산 차단

스플릿 브레인이 확인된 즉시, 데이터 손상과 서비스 중단을 최소화하기 위해 수동으로 상태를 정리해야 합니다. 가장 안전한 접근법은 한쪽 노드를 명시적으로 서비스에서 제외시키는 것입니다.

1. 쓰기 작업 전면 중지: 가능한 모든 애플리케이션의 DB 연결을 즉시 차단합니다. 로드 밸런서나 애플리케이션 서버 설정에서 DB 연결 풀을 비활성화하세요.
2. 데이터 무결성 우선 평가: 두 노드의 데이터를 신속히 비교합니다. 가장 최근의 성공적인 트랜잭션 로그(예: MySQL의 binlog position, PostgreSQL의 LSN)를 기준으로, 더 많은 쓰기 작업을 처리한 노드를 ‘승자’로 간주합니다. 이 판단은 애플리케이션 로그와 결합되어야 합니다.
3. 노드 강제 격리: 데이터 손실이 적은 쪽(또는 명백히 오래된 데이터를 가진 쪽)의 노드를 선택합니다, 해당 노드에서 db 서비스 프로세스를 강제 종료(systemctl stop [서비스명] 또는 kill -term)하고, 클러스터 관리 소프트웨어에서 제거합니다.
4. 단일 주 노드 복원: 남아있는 노드를 유일한 주 서버로 확립합니다. 애플리케이션의 연결을 이 노드로만 우회시킵니다.
5. 대기 노드 재동기화: 격리된 노드의 데이터를 완전히 삭제한 후(rm -rf [데이터 디렉토리] *주의), 정상 주 노드로부터 초기 백업 또는 스냅샷을 이용해 완전히 새로 복제 구성을 시작합니다. 증분 복제만으로는 불일치 데이터가 남을 수 있습니다.

경고: 수동 개입 중 가장 큰 위험은 잘못된 노드를 주 서버로 선택하는 것입니다. 반드시 트랜잭션 로그 시점과 애플리케이션 비즈니스 로직을 교차 검증하십시오. ‘데이터 무결성’이 속도나 가용성보다 항상 우선합니다.

해결 방법 2: 자동 복구 실패의 근본 원인 진단 및 수정

수동 복구 후, 동일한 재앙이 반복되지 않도록 자동 복구 체계의 결함을 찾아 수정해야 합니다. 이 작업은 시스템의 안정성을 근본적으로 높입니다.

1단계: 펜싱(Fencing) 구성 검증 및 테스트

펜싱은 스플릿 브레인 상황에서 클러스터가 스스로를 보호하는 최후의 보루입니다. 구성이 ‘작동한다고 가정’해서는 안 되며, 반드시 테스트해야 합니다.

1. 펜싱 에이전트 확인: 클러스터 관리 도구에서 현재 구성된 펜싱 장치를 확인하세요. (Pacemaker: pcs stonith show, WSFC: 장애 조치 클러스터 관리자) 에이전트가 하드웨어(서버의 전원 관리 인터페이스)와 정상 통신하는지 로그(/var/log/messages 또는 클러스터 로그)를 확인합니다.
2. 권한 및 네트워크 접근성 점검: 펜싱을 수행하는 계정(예: IPMI 사용자)에 필요한 권한이 있는지, 관리 네트워크가 분리되어 있다면 해당 네트워크 경로가 항상 사용 가능한지 확인합니다.
3. 안전한 환경에서 펜싱 테스트 실행: 비수기 시간에, 대기 노드에서 pcs stonith fence [노드명] 명령을 실행하거나 WSFC의 테스트 장애 조치 기능을 사용하여 주 노드가 강제로 재시작되는지 확인합니다. 서버가 실제로 전원 꺼짐/재시작 되고, 클러스터가 이를 인지하는지 전체 흐름을 모니터링하십시오.

2단계: 쿼럼(Quorum) 정책 재정의

2노드 클러스터는 기본적으로 쿼럼(과반수)을 달성할 수 없어, 네트워크 단절 시 두 노드 모두 자신이 유효하다고 판단할 수 있습니다. 이를 방지하기 위한 명시적 정책이 필요합니다.

1. 쿼럼 장치 도입: 가장 강력한 해결책은 제3의 투표 노드(쿼럼 장치)를 추가하는 것입니다. 이는 전용 위트니스 서버, 공유 스토리지, 또는 클라우드의 경우 쿼럼 파일 공유일 수 있습니다. 이 장치는 네트워크 분할 시 어느 쪽이 서비스를 계속할지 결정하는 데 결정적 역할을 합니다.
2. 2노드 특수 구성 적용: 제3의 장치가 불가능한 경우, 소프트웨어 수준의 차선책을 적용해야 합니다, pacemaker에서는 pcs property set no-quorum-policy=freeze 또는 stop으로 설정하여 쿼럼 손실 시 모든 노드의 자원을 중지시킬 수 있습니다. Corosync의 two_node: 1 옵션을 사용하여 2노드 클러스터를 명시적으로 선언할 수도 있습니다. Windows Server Failover Cluster에서는 ‘동적 쿼럼 관리’와 ‘클라우드 감시’ 기능을 활용합니다.
3. 자동 페일백 비활성화: 원래 주 서버가 복구되었을 때 자동으로 다시 주 역할을 되찾는 ‘페일백’은 네트워크 불안정 환경에서 추가적인 스플릿 브레인과 불필요한 장애 조치를 유발할 수 있습니다. 대부분의 경우 자동 페일백을 비활성화하고, 안정성이 확인된 후 수동으로 전환하는 것이 더 안전합니다.

3단계: 복제 건강도 모니터링 및 사전 차단 스크립트 강화

자동 복구 실패는 복제 상태가 이미 비정상임을 감지하지 못했기 때문일 수 있습니다. 사전에 차단하는 로직을 추가하십시오.

1. 복제 지연 임계값 설정: 복제 지연이 특정 시간(예: 30초)을 초과하면, 해당 대기 노드를 자동 페일오버 후보에서 제외시키도록 클러스터 제약 조건을 설정합니다. 이와 같은 pacemaker의 resource stickiness와 결합된 위치 제약 조건으로 구현 가능합니다.
2. 사전-페일오버 검증 스크립트 구현: 클러스터가 장애 조치를 실행하기 직전에 호출되는 스크립트를 작성합니다. 이 스크립트는 최종 데이터 일관성 점검, 대상 노드의 부하 확인, 특정 비즈니스 애플리케이션 상태 확인 등을 수행하고, 조건이 맞지 않으면 장애 조치를 중단하도록 할 수 있습니다.
3. 네트워크 이중화 및 링크 상태 모니터링: 복제 전용 네트워크 링크를 이중화하고, OS 수준에서 본딩(bonding) 또는 팀링(teaming)을 구성합니다. 클러스터 소프트웨어가 물리적 링크와 논리적 연결 상태를 모두 모니터링하도록 합니다.

해결 방법 3: 아키텍처적 재설계를 통한 스플릿 브레인 근절

반복적으로 스플릿 브레인 문제에 시달리고, 자동 복구에 대한 신뢰를 확보할 수 없다면, 현재의 HA 아키텍처 자체를 재평가해야 합니다. 지금 당장 작동하는 해결책이 가장 훌륭한 기술적 자산이지만, 장기적 안정성을 위해서는 근본적인 변화가 필요할 수 있습니다.

1. 클러스터 관리 솔루션 전환 평가: 현재 사용 중인 솔루션이 너무 오래되었거나 커뮤니티 지원이 약한 경우, 더 활발히 개발되고 검증된 솔루션(예: 오래된 Heartbeat에서 Pacemaker/Corosync로, 또는 Patroni for PostgreSQL)으로의 전환을 고려하십시오.
2. 동기식 복제 및 컨센서스 프로토콜 도입: 비동기 복제는 본질적으로 스플릿 브�레인 리스크를 내포합니다. 데이터 일관성이 극도로 중요한 시스템에서는, 쓰기가 다수 노드에 동기적으로 전파될 때까지 완료로 간주하지 않는 동기 복제 모드나, Raft/Paxos 같은 컨센서스 프로토콜을 사용하는 데이터베이스(예: etcd, Consul, 또는 MySQL Group Replication, PostgreSQL with synchronous_commit = remote_apply)를 검토하세요. 이는 성능을 희생시키지만 데이터 무결성을 보장합니다.
3. 오케스트레이션 플랫폼 활용: Kubernetes와 같은 컨테이너 오케스트레이션 플랫폼 위에서 StatefulSet과 함께 운영자(Operator) 패턴(예: MySQL Operator, PostgreSQL Operator)을 사용할 경우, 페일오버와 복제 관리를 플랫폼이 더욱 엄격하고 선언적인 방식으로 처리하도록 위임할 수 있습니다.

주의사항 및 예방 조치

스플릿 브레인은 복구 과정 자체가 새로운 데이터 손실을 초래할 수 있는 위험한 상황입니다. 다음 예방 조치는 시스템 설계 단계부터 통합되어야 합니다.

• 정기적인 펜싱 및 페일오버 재난 복구 훈련: 최소 분기별로, 실제와 유사한 환경에서 네트워크 단절, 노드 다운 시나리오를 시뮬레이션하고 복구 절차를 팀원이 숙지하도록 합니다. 모든 자동화 스크립트의 로그는 상세하게 기록되고 중앙 집중화되어야 합니다.
• 모니터링과 알림의 다중화: 클러스터 상태, 복제 지연, 네트워크 연결 상태를 중복된 모니터링 시스템으로 관찰합니다. 단일 경고 채널에 의존하지 말고, SMS, 이메일, 채팅알림 등을 모두 활용하여 문제를 조기에 인지하도록 합니다.
• 구성 변경 관리의 엄격화: 클러스터 관련 모든 구성 변경(네트워크, 스토리지, 클러스터 소프트웨어 설정)은 변경 관리 절차를 통해 진행되어야 하며, 반드시 비프로덕션 환경에서 먼저 검증됩니다. 동일 문제 재발 방지를 위한 시스템 최적화 설정값은 버전 관리 시스템에 문서화되어야 합니다.
• 데이터 백업의 최종 보험 확보: 아무리 완벽한 HA 구성도 백업을 대체할 수 없습니다. 스플릿 브레인 후 최악의 시나리오(양쪽 노드 데이터 모두 훼손)를 대비해, 트랜잭션 로그를 포함한 정기적이고 검증된 백업을 오프사이트 또는 객체 스토리지에 보관하십시오. 백업 복원 시간 목표(RTO)와 백업 주기는 비즈니스 요구사항에 따라 명확히 정의되어야 합니다.

전문가 팁: 스플릿 브레인 자동 복구 실패 문제를 해결한 후, 반드시 ‘사후 분석’ 문서를 작성하십시오. 이 문서에는 문제 발생 시간, 근본 원인, 수동 개입에 소요된 시간, 개입 중 발생한 데이터 손실량(있었다면), 그리고 해결 방법 2에서 수행한 모든 구성 수정 내역이 상세히 기록되어야 합니다. 이 문서는 단순한 보고서가 아니라, 향후 유사 장애 발생 시 복구 시간을 획기적으로 단축시키고, 시스템 신뢰성을 높이는 가장 소중한 조직의 기술적 자산이 됩니다.