Split Brain 방지: Pacemaker + Corosync 기반 MySQL HA 운영 가이드

1. 서론

이전 글에서 Split Brain 개념과, 그 대표적인 예시로 MySQL HA 환경을 간단히 다뤘다.
이번 글에서는 그 내용을 조금 더 확장하여, 실제 운영했던 환경을 기반으로 Pacemaker + Corosync + MySQL Dual Master Replication 구조에서 Split Brain을 방지하는 방법을 구체적으로 살펴본다.

다만 이 글은 예전에 운영했던 환경을 기억을 되살려 정리한 가이드이므로, 최신 환경에 그대로 적용하기보다는 자기 환경에 맞게 적절히 응용해야 한다.
또한 MySQL 설치와 Replication 설정 방법은 공식 문서가 풍부하므로 여기서는 생략하고, HA 설계와 Failover 로직에 집중한다.

한가지 더 첨언하자면, MySQL HA에는 다양한 방법(InnoDB Cluster, Group Replication, Galera 등)이 존재하며, 여기서 다루는 방식은 그중 하나일 뿐이다.

2. Split Brain이란?

Split Brain은 네트워크 단절이나 헬스 체크 오류로 인해 두 노드가 동시에 자신을 Master라고 판단하는 상황을 의미한다.
데이터베이스 환경에서는 무결성 붕괴와 데이터 충돌을 초래하므로 반드시 방지해야 한다.

3. 구성 개요

• MySQL Dual Master Replication
  양쪽 노드가 Master 복제 관계를 맺되, VIP를 통해 서비스는 항상 Active 노드에서만 처리.
• Pacemaker + Corosync
  • Pacemaker: 서비스 자원 관리 및 Failover 담당
  • Corosync: 노드 간 통신과 Quorum 관리
  • VIP를 Active 노드에만 할당, 장애 발생 시 Passive로 이동
• Failover 흐름
  1. Active 노드 장애 감지
  2. Corosync 모니터링 → Pacemaker가 VIP 회수
  3. Passive 노드로 VIP 이동
  4. Passive 노드 Active 승격
  5. 서비스 지속

4. 주요 개념

• Quorum
  합의 기반 구조. 2노드 환경에서는 한계가 있으므로 네트워크 모니터링 리소스로 보완 필요.
• STONITH(Fence Device)
  • 장애 노드를 강제로 차단하는 방식
  • Split Brain 방지에는 가장 강력하지만, 구성 복잡성이 크다
  • 본 가이드는 네트워크 모니터링 기반으로 Split Brain을 방지하며, STONITH는 선택적 보강책 정도로만 본다
• 네트워크 모니터링 리소스
  단순 헬스 체크만으로는 네트워크 단절 상황을 제대로 감지하지 못한다.
  ethmonitor 리소스를 추가하면 실제 인터페이스 단절을 감시할 수 있어, 짧은 단절은 무시하고 장시간 단절 시에만 Failover를 유도한다.
  본 방식은 실제 운영 환경에서 수년간 안정적으로 검증되었다.

5. 설치 및 설정 요약

(MySQL 설치 및 Replication 설정은 생략)

Pacemaker/pcs 설치
: 아래 설정 예시는 RHEL 계열(yum install pcs) 기준 예시이며, Ubuntu/Debian 계열은 명령어와 도구가 다르므로 별도 응용이 필요하다.

yum install -y pcs
systemctl enable --now pcsd

클러스터 생성

pcs cluster auth DB01 DB02 -u hacluster -p <password>
pcs cluster setup --name mysql_ha DB01 DB02
pcs cluster start --all

클러스터 속성

# STONITH 비활성화 (네트워크 모니터링으로 Split Brain 회피)
pcs property set stonith-enabled=false

# Quorum 정책 무시 (2노드 환경에서는 필수)
pcs property set no-quorum-policy=ignore

VIP 리소스

pcs resource create mysql_vip ocf:heartbeat:IPaddr2 ip=192.10.10.252 cidr_netmask=32 \
   op monitor interval=5s meta migration-threshold=2 failure-timeout=10s

MySQL 서비스 리소스

pcs resource create mysql_service ocf:heartbeat:mysql \
   binary="/usr/local/mysql/bin/mysqld_safe" config="/etc/my.cnf" \
   datadir="/data/mysql_data" user="mysql" group="mysql" \
   pid="/data/mysql_data/mysqld.pid" socket="/tmp/mysql.sock" \
   op monitor interval=5s timeout=10s on-fail=standby
pcs resource clone mysql_service clone-max=2 clone-node-max=1

네트워크 모니터링 리소스

# ethmonitor: 지정된 NIC 인터페이스 상태를 감시
#   - interface: 감시할 네트워크 인터페이스
#   - interval: 체크 주기
#   - timeout: 응답 없을 때 간주 시간
#   - on-fail: 동작 실패 시 standby 처리
pcs resource create network_monitor ocf:heartbeat:ethmonitor interface=eno8 \
   op monitor interval=2s timeout=5s on-fail=standby

# VIP와 네트워크 모니터링을 묶어 항상 함께 이동
pcs constraint colocation add network_monitor with mysql_vip INFINITY
pcs constraint order network_monitor then mysql_vip

6. 운영 포인트

• VIP는 항상 단일 노드에서만 실행 → Active/Passive 구조 유지
• 네트워크 모니터링 리소스로 일정시간 단절 시에만 Failover 발생
• STONITH 기능은 네트워크 모니터링으로 대체
• 본 방식은 실제 운영 환경에서 안정적으로 검증됨

7. 결론

이 글은 이전 글에서 다룬 Split Brain 개념을 이어받아, 실제 운영 환경에서 검증된 Pacemaker + Corosync + MySQL Dual Master Replication 구조를 구체적으로 다룬 가이드다.

최신 환경에서는 반드시 자기 환경에 맞게 응용해야 하며, MySQL 설치 및 Replication 설정은 공식 문서를 참조 바란다.
핵심은 VIP와 네트워크 모니터링 리소스를 통해 두 노드가 동시에 서비스하지 않도록 보장하는 것이다.
STONITH는 선택적인 보강책일 뿐, 본 구성만으로도 충분히 Split Brain을 방지할 수 있다.

또한 고가용성 구성은 클러스터 내부 로직만으로는 한계가 있다.
Pacemaker와 Corosync가 Failover를 담당한다면, 그 위에 통합 모니터링 시스템을 올려 상태를 상시 감시하는 것이 안정적이다.
예를 들어 Zabbix, Prometheus 같은 도구와 연계하면 VIP 전환이나 복제 지연, 네트워크 단절 등의 이벤트를 조기에 감지하고 알림을 받을 수 있다.
이렇게 사전 탐지 체계를 마련해 두면 단순히 장애 복구를 넘어, 서비스 신뢰성과 가용성을 한층 더 높일 수 있다.