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.09.19

ⓒ 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.

💡 도움이 필요하신가요?
Zabbix, Kubernetes, 그리고 다양한 오픈소스 인프라 환경에 대한 구축, 운영, 최적화, 장애 분석, 광고 및 협업 제안이 필요하다면 언제든 편하게 연락 주세요.

📧 Contact: jikimy75@gmail.com
💼 Service: 구축 대행 | 성능 튜닝 | 장애 분석 컨설팅

📖 E-BooK [PDF] 전자책 (Gumroad): Zabbix 엔터프라이즈 최적화 핸드북
블로그에서 다룬 Zabbix 관련 글들을 기반으로 실무 중심의 지침서로 재구성했습니다. 운영 환경에서 바로 적용할 수 있는 최적화·트러블슈팅 노하우까지 모두 포함되어 있습니다.


💡 Need Professional Support?
If you need deployment, optimization, or troubleshooting support for Zabbix, Kubernetes, or any other open-source infrastructure in your production environment, or if you are interested in sponsorships, ads, or technical collaboration, feel free to contact me anytime.

📧 Email: jikimy75@gmail.com
💼 Services: Deployment Support | Performance Tuning | Incident Analysis Consulting

📖 PDF eBook (Gumroad): Zabbix Enterprise Optimization Handbook
A single, production-ready PDF that compiles my in-depth Zabbix and Kubernetes monitoring guides.