앞선 글에서는 레플리케이션(Replication) 방식의 DB 다중화를 다뤘다.
레플리케이션은 읽기 성능 향상에는 효과적이지만, 쓰기 성능과 고가용성(HA) 측면에서는 한계가 있다.
이번 글에서는 그 한계를 보완하는 클러스터(Cluster) 방식을 정리한다.
클러스터란?
DB 클러스터는 여러 DB 서버가 동등한 노드로 구성되어 하나의 DB처럼 동작하는 구조다.
모든 노드가 읽기와 쓰기를 모두 처리할 수 있으며, 특정 노드 장애 시에도 서비스가 지속된다.
이번 실습에서는 MariaDB + Galera Cluster를 사용한다.
클러스터의 핵심 특징
- 모든 노드가 Read / Write 가능
- 데이터는 동기식(Synchronous) 복제
- 특정 노드 장애 시에도 서비스 지속 가능
- 고가용성(HA) 구조에 적합
레플리케이션이 성능 분산에 초점이라면
클러스터는 무중단 서비스에 초점이 맞춰져 있다.
RDB / NoSQL에서의 클러스터 사용 예
RDB
- MariaDB (Galera Cluster)
- MySQL (InnoDB Cluster)
NoSQL
- MongoDB (Replica Set / Sharding)
- Redis (Cluster Mode)
- Elasticsearch (Cluster 기본 구조)
Galera Cluster 동작 개념
- 트랜잭션 발생
- 모든 노드에 동시에 전파
- 모든 노드가 OK를 반환해야 커밋
- 하나라도 실패하면 전체 트랜잭션 실패
이 구조 때문에 데이터 정합성이 매우 높음
대신 쓰기 지연이 발생할 수 있음
클러스터 구성 전 준비
- 노드 수는 홀수(3대 이상) 권장
- 이유: 과반수 합의 구조
- 과반수 미만이 살아있으면 클러스터 중단
1대 먼저 설정 (Bootstrap 노드)
클러스터 최초 생성 시 1대만 먼저 실행해야 한다.
# 서버 중지
systemctl stop mariadb
# mariadb 설정 추가(마지막 줄에 다음 내용 추가)
vi /etc/mysql/mariadb.conf.d/50-server.cnf
[galera]
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://"
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
wsrep_cluster_name="MariaDB_Cluster" # 3대의 컴퓨터를 묶었을 때 내가 지어줄 이름
wsrep_node_address="192.168.146.210" # 현재 컴퓨터의 IP 주소
# mariadb 재실행
systemctl restart mariadb
# 클러스터 구성 실행
galera_new_cluster이 단계에서 클러스터가 생성된다.
나머지 서버 설정 (Join 노드)
# 서버 중지
systemctl stop mariadb
# mariadb 설정 추가(마지막 줄에 다음 내용 추가)
vi /etc/mysql/mariadb.conf.d/50-server.cnf
[galera]
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://192.168.146.210,192.168.146.211,192.168.146.212"
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
wsrep_cluster_name="MariaDB_Cluster"
wsrep_node_address="192.168.146.211" # 현재 컴퓨터의 IP 주소
# mariadb 재실행
systemctl restart mariadb최초 노드 (Bootstrap 노드) 설정 변경 및 최종 확인
# mariadb 설정 변경
vi /etc/mysql/mariadb.conf.d/50-server.cnf
wsrep_cluster_address="gcomm://192.168.146.210,192.168.146.211,192.168.146.212"
# mariadb 재실행
systemctl restart mariadb클러스터 상태 확인
show status like 'wsrep_cluster_status';
-- Primary
show status like 'wsrep_cluster_size';
-- 3
show status like 'wsrep_local_state_comment';
-- Synced
모든 노드에서 동일하게 출력되어야 정상이다.
장애 상황 복구 시나리오
클러스터는 전체 노드가 내려가면 자동 복구되지 않는다.
가장 최신 데이터를 가진 노드를 기준으로 재구성해야 한다.
# 모든 서버 중지
systemctl stop mariadb
# grastate.dat 확인
cat /var/lib/mysql/grastate.dat
safe_to_bootstrap: 1값이 1인 노드가 마지막으로 정상 동작하던 노드
# 해당 노드 부트스트랩
vi /etc/mysql/mariadb.conf.d/50-server.cnf
wsrep_cluster_address="gcomm://"
# mariadb 재실행
systemctl start mariadb
# 클러스터 구성 실행
galera_new_cluster
# 나머지 노드 재실행
systemctl restart mariadb
# 설정 복구
vi /etc/mysql/mariadb.conf.d/50-server.cnf
wsrep_cluster_address="gcomm://192.168.146.210,192.168.146.211,192.168.146.212"로그 확인
tail -f /var/log/syslog
클러스터 방식 정리
- 모든 노드가 OK해야 데이터 저장
- 레플리케이션보다 부하 분산 효과 큼
- 쓰기 지연 발생 가능
- 홀수 노드 구성
- 과반수 이상 장애 시 클러스터 중단
레플리케이션 vs 클러스터
- 레플리케이션: 읽기 성능 중심
- 클러스터: 고가용성 + 쓰기 분산 중심
마무리
클러스터는 단순히 DB를 여러 대로 늘리는 기술이 아니라, 장애 상황에서도 데이터 일관성과 서비스 연속성을 지키기 위한 구조다.
클러스터는 모든 노드의 합의를 전제로 동작하기 때문에 쓰기 지연이라는 비용이 따르지만, 그만큼 데이터 정합성과 신뢰성을 확보할 수 있다.
실제 운영 환경에서는 트래픽 특성, 장애 허용 범위, 운영 난이도를 함께 고려해 레플리케이션과 클러스터 중 하나를 선택하거나 두 방식을 혼합 구성하는 경우도 많다.
'🔗 CS > 💿 DATABASE' 카테고리의 다른 글
| [DATABASE] DB 다중화 - 레플리케이션 (0) | 2025.12.28 |
|---|
