Pacemaker vs Galera

pacemaker vs galera : 내부망(MySQL) 고가용성, 무엇을 선택할까
이전에 썼던 pacemaker 관련 글에 이어 보완적인 글을 써볼까 한다.
특히, failover 가 일어날 경우 정합성 이슈에 대한 보완을 할려고 하는 분들은
이 글을 참조했으면 한다.

요약

• 2노드, 내부 L2 중심, ICMP 제약, 비용 최소, 짧은 다운타임 허용 ⇒ Pacemaker+Corosync(액티브/스탠바이) + 세미싱크(AFTER_SYNC) 가 현실적. ethmonitor로 L2만 감시하면 불필요한 페일오버를 줄일 수 있다.
• 3노드 이상, 장애 시에도 즉시 쓰기 지속, RPO≈0 지향, 읽기 스케일 필요 ⇒ Galera(멀티-프라이머리, 운영은 단일 라이터 권장) + 프록시 계층(HAProxy/ProxySQL) 가 정석.

1) 문제 정의

최적의 HA 방식은 서비스 특성(읽기/쓰기 비중, DDL 빈도), RPO/RTO 목표, 네트워크/보안 제약(ICMP/방화벽), 노드 수·예산, 운영 인력에 의해 갈린다.

• 읽기 위주 + 다운타임 수초~수십초 허용 + 2노드: 단순·견고 구성이 유리
• 쓰기 비중 높음 + 다운타임 최소 + 데이터 손실 불가 + 3노드: 합의 기반 구조가 유리

2) Pacemaker + Corosync (Dual-Master Replication, 액티브/스탠바이)

구조

• 이중화는 “듀얼마스터 복제”로 깔아도 실제 쓰기는 VIP가 붙은 한 노드에서만 수행한다(반대편은 super_read_only=ON).
• VIP 이동으로 라이터가 전환되며, 복제는 GTID+ROW 권장.

장애 감지 전략 (ICMP 없이)

• 내부 L2 세그먼트에서 애플리케이션↔DB가 같은 스위치에 붙어 있는 환경은 L3 핑 기반 감시가 오탐을 유발할 수 있다(게이트웨이 문제=실서비스는 정상인데 failover).
• ethmonitor 로 L1/L2 링크만 감시하면 “실제로 통신이 가능한 상황”에서 불필요한 전환을 피할 수 있다.
  • 필요 시 보조 센서(예: Bond ARP monitor, Route 존재 확인, TCP 핸드셰이크 기반 경량 헬스)를 “추가”로만 쓰고, 기본은 L2로 간다.

정합성·데이터 손실 최소화

• 세미싱크(AFTER_SYNC) 로 “커밋 OK 전에 스탠바이 1대가 이벤트를 수신·기록”하도록 강제하면, 페일오버 시 ‘사라진 커밋’ 위험을 실무적으로 크게 줄인다.
• 단, 세미싱크는 타임아웃 시 비동기로 폴백하므로(기본), 모니터링으로 폴백 상태를 즉시 잡아야 한다.

권장 설정

MySQL(my.cnf)

# 정합성/복제
binlog_format=ROW
gtid_mode=ON
enforce_gtid_consistency=ON
sync_binlog=1
innodb_flush_log_at_trx_commit=1

# 세미싱크 (손실 최소화)
rpl_semi_sync_master_enabled=ON
rpl_semi_sync_slave_enabled=ON
rpl_semi_sync_master_wait_for_slave_count=1
rpl_semi_sync_master_wait_point=AFTER_SYNC
rpl_semi_sync_master_timeout=3000   # ms, 환경에 맞게

Pacemaker (핵심 흐름)

# L2 감시
pcs resource create net_l2 ocf:heartbeat:ethmonitor interface=eno8 \
  op monitor interval=2s timeout=5s on-fail=standby

# MySQL 리소스(예: Percona RA)와 VIP
pcs resource create mysql ocf:percona:mysql op monitor interval=5s timeout=20s
pcs resource create mysql_vip ocf:heartbeat:IPaddr2 ip=10.0.0.50 cidr_netmask=24

# 제약: 승격 → VIP 순, VIP는 Master에만
pcs constraint order promote mysql then start mysql_vip
pcs constraint colocation add mysql_vip INFINITY: mysql Master:mysql

# 플랩 방지
pcs resource defaults resource-stickiness=200
pcs resource defaults migration-threshold=3
pcs property set failure-timeout=60s

장단점

• 장점: 2노드로 충분, 내부망·보안 제약에 강함, 구성 단순, 비용 최소.
• 단점: 세미싱크 폴백 창에서 ‘막 커밋된 데이터’ 손실 가능성, 다운타임은 (짧더라도) 존재, 멀티 리더 스케일 아웃은 구조상 어려움.

3) Galera Cluster (Percona XtraDB Cluster / MariaDB Galera)

구조

• 멀티-프라이머리(모든 노드 쓰기 가능) 이지만 실무에서는 단일 라이터 + 다중 리더 라우팅이 충돌/지연을 줄여 안정적이다.
• 클러스터 내부에 마스터→슬레이브 체인을 세우지 않는다. 외부 DR/리포팅 슬레이브는 “클러스터 밖”으로만 둔다.

정합성·장애 동작

• 커밋 전 전파(WriteSet) + Certification 을 거쳐 Primary Component(쿼럼) 에서만 커밋된다.
• 네트워크 분리 시 과반수 없는 그룹은 Non-Primary 로 전환되어 쓰기 차단 → split-brain 차단.
• RPO는 사실상 0에 가깝다(virtually synchronous).

라우팅(프록시/로더 밸런서)

• ProxySQL: Galera 인지형 모니터가 있어 writer/reader 자동 분리.
• HAProxy: clustercheck(상태 200/503)로 백엔드 판단.
• L4 장비만 사용하려면
  • (A) 라이터-VIP를 라이터 노드에만 붙여 L4는 VIP만 경유하거나
  • (B) 각 노드가 역할 헬스용 TCP 포트(예: 9200)를 노출하고, L4가 그 포트로 헬스체크.

HAProxy 예시

backend be_mysql_writer
  mode tcp
  option mysql-check user clustercheck
  default-server inter 2s fall 3 rise 2
  server n1 10.0.0.11:3306 check
  server n2 10.0.0.12:3306 check backup
  server n3 10.0.0.13:3306 check backup

backend be_mysql_readers
  mode tcp
  balance roundrobin
  option mysql-check user clustercheck
  default-server inter 2s fall 3 rise 2
  server n2 10.0.0.12:3306 check
  server n3 10.0.0.13:3306 check

필수·권장 설정

# 공통
binlog_format=ROW
default_storage_engine=InnoDB
innodb_flush_log_at_trx_commit=1
sync_binlog=1

# Galera
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_name=galera-prod
wsrep_cluster_address="gcomm://10.0.0.11,10.0.0.12,10.0.0.13"
wsrep_node_address=<this_node_ip>
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=sstuser:sstpass
wsrep_slave_threads=<CPU 코어 수 수준>
gcache.size=1G   # IST 성공률 향상

• 모든 테이블 PK 필수, InnoDB 권장(MyISAM 비권장)
• 읽기 직후 일관성 필요 시 wsrep_sync_wait 활용

장단점

• 장점: RPO≈0, 자동 합의/인증으로 정합성 강함, 읽기 스케일아웃 용이.
• 단점: 3자 구조·프록시 포함해 구성 복잡, 네트워크 지연·충돌에 민감, 대형 DDL/핫스팟에 비용 증가.

4) 네트워크·보안 관점 비교

5) 성능·지연·운영

6) 의사결정 매트릭스

• 다음에 해당하면 Pacemaker 쪽
  • 노드 2대로 끝내야 한다
  • ICMP 제약 또는 내부 L2 중심 구조
  • 짧은 다운타임 허용 + 읽기 위주
  • 운영팀이 이미 VIP·제약·세미싱크 패턴을 숙련
• 다음에 해당하면 Galera 쪽
  • 3노드 이상 가능
  • 장애 중에도 쓰기 지속(RPO≈0) 요구
  • 읽기 스케일아웃 필요
  • Proxy(HAProxy/ProxySQL) 운용 수용

7) 운영 체크리스트

Pacemaker

• 세미싱크 AFTER_SYNC + 폴백 모니터링(Zabbix 등)
• 승격 순서 고정: promote → relay 적용 완료 확인 → read_only=0 → VIP
• 스티키니스/플랩 방지: resource-stickiness, migration-threshold
• 백업·복구·DDL 변경은 라이프사이클로 관리

Galera

• 프록시 헬스 조건: wsrep_local_state=4, wsrep_cluster_status='Primary', 라이터는 read_only=OFF
• gcache/IST 튜닝, SST 시 I/O 여유 확보
• DDL은 가급적 온라인 도구(gh-ost/pt-osc 등)
• 2노드만 운용 금지(또는 garbd로 3자 구도 확보)

8) L4만 쓰는 경우의 패턴(요약)

• Pacemaker: Writer-VIP 1개만 노출 → L4는 VIP로 단순 포워딩(TCP 헬스만)
• Galera:
  • (A) Writer-VIP(라이터 전용) + Reader 개별 IP
  • (B) 각 노드의 역할 헬스용 TCP 포트(예: 9200) 체크로 Writer/Reader 풀 분리

결론

• 내부 L2, 2노드, 비용 최소, 다운타임 수 초 허용이면 Pacemaker+Corosync(액티브/스탠바이) + 세미싱크(AFTER_SYNC) + L2 ethmonitor 가 가장 실전적이다.
• 3노드 이상 가능하고 RPO≈0에 가깝게 쓰기 지속이 필요하면 Galera + 프록시 계층이 정석이다.
• 동일 조직에서도 핵심 트랜잭션 DB는 Galera, 캐시성/읽기 위주 DB는 Pacemaker 처럼 혼합 전략이 현실적일 때가 많다.

🛠 마지막 수정일: 2025.09.30