Split Brain : MySQL HA 예시로 보는 대응 전략 (using pacemaker)

1. Split Brain 이란

스플릿 브레인은 클러스터 환경에서 둘 이상의 노드가 동시에 자신을 마스터(Primary)라고 판단하는 비정상 상태다.
짧은 네트워크 단절 후 헬스 체크 오판으로 양쪽이 동시에 활성화되고, 네트워크가 복구되는 순간 데이터 충돌, 손실, 불일치가 발생한다.
데이터베이스, 스토리지 등 무결성이 중요한 서비스에서 특히 치명적이다.


2. 전형적 예시

대표적인 사례로 Pacemaker + Corosync + MySQL Dual Master Replication 구성을 들 수 있다.

  • MySQL Dual Master Replication은 기본적으로 양쪽 노드에서 쓰기를 허용할 수 있다.
  • Pacemaker는 VIP와 MySQL 서비스를 관리하며 장애 시 절체를 담당한다.
  • Corosync는 노드 간 통신과 헬스 체크, quorum을 관리한다.
  • 네트워크 단절 시 두 노드가 동시에 VIP를 가져가고, 각자 마스터로 동작하면서 스플릿 브레인이 발생할 수 있다.

3. 복구 순간의 위험성

  • 단절 상태에서는 단순히 두 개의 독립 노드처럼 보인다.
  • 그러나 네트워크가 복구되면 각각의 노드가 보관한 데이터가 충돌한다.
  • DB 환경에서는 트랜잭션 불일치와 무결성 훼손으로 이어진다.

4. 주요 원인

  • 헬스 체크 한계: heartbeat 수준의 체크만으로는 실제 서비스 장애를 감지하지 못함.
  • 2노드 구성의 한계: quorum 동수 상황에서 tie-break 불가.
  • 펜싱 실패: 문제가 있는 노드를 격리하지 못하고 VIP·서비스가 중복 실행됨.
  • 자동 복구 로직 부재: 네트워크 복구 시 충돌 방지 메커니즘이 부족.

5. 방지와 대응 전략

환경과 요구사항에 따라 여러 방법을 조합하거나 선택적으로 적용할 수 있다.

Quorum

  • 3대 이상의 홀수 노드 또는 quorum 디바이스를 두어 과반수 원칙을 적용한다.
  • 2노드 환경에서는 tie-breaker 없이는 안정성이 떨어진다.

Fence Device (STONITH)

  • IPMI, 전원 차단, NIC 비활성화 등으로 문제 노드를 완전히 격리한다.
  • 가장 확실한 방법이지만 장비 의존도와 운영 복잡도가 높다.

네트워크 단절 시간 기반 자동 배제

  • Corosync 파라미터(token, consensus)를 통해 일정 시간 이상 응답 없는 노드를 자동으로 제외한다.
  • VIP는 항상 한쪽 노드에만 귀속되도록 migration-threshold, failure-timeout 같은 제약을 둔다.
  • 짧은 네트워크 글리치에는 반응하지 않고 일정 임계 시간을 넘어서는 경우에만 failover를 수행한다.

Pacemaker 제약 조건 활용

  • MySQL 리소스는 clone 모드로 제한(각 노드에 1개만 실행).
  • VIP와 network monitoring 리소스를 결합해 스플릿 브레인 상황을 최소화한다.
  • 실패 시 on-fail=standby 옵션으로 자동 대기 전환을 적용할 수 있다.

6. 모니터링 포인트

  • Pacemaker: fencing 로그, VIP 활성 노드 확인.
  • Corosync: ring 상태, quorum 이벤트.
  • MySQL: replication delay, dual master 중복 활성화 여부.
  • VIP: 다중 활성화 여부.

7. 예방 체크리스트

  • 2노드 클러스터에서는 tie-breaker 또는 네트워크 배제 로직을 반드시 고려한다.
  • STONITH는 이상적이지만, 복잡할 경우 네트워크 모니터링 기반 배제를 보완책으로 삼을 수 있다.
  • VIP는 반드시 단일 노드 전용으로 설정한다.
  • 정기적으로 chaos 테스트(네트워크 단절 → 복구 → VIP/MySQL 동작 확인)를 수행한다.

8. 결론

스플릿 브레인은 단순한 네트워크 장애가 아니라 재결합 순간의 충돌에서 발생한다.
MySQL HA 환경과 같이 실제 운영에서 흔히 쓰이는 구조에서도 언제든 나타날 수 있는 문제다.

대응 전략은 하나의 정답이 아니라 선택지의 조합이다.

  • 인프라 복잡성을 감수할 수 있다면 STONITH와 quorum 기반 설계를 선택할 수 있다.
  • 환경 제약이 크다면 네트워크 단절 감지 기반 배제와 VIP 제약만으로도 일정 수준 방어가 가능하다.
ⓒ 2025 엉뚱한 녀석의 블로그 [quirky guy's Blog]. 본문 및 이미지를 무단 복제·배포할 수 없습니다. 공유 시 반드시 원문 링크를 명시해 주세요.
ⓒ 2025 엉뚱한 녀석의 블로그 [quirky guy's Blog]. All rights reserved. Unauthorized copying or redistribution of the text and images is prohibited. When sharing, please include the original source link.