[MariaDB] Galera 클러스터 구축7: 전체 노드 정지 후 재시작과 부트스트랩 복구

6월 17, 2025

이번 글에서는 Galera Cluster의 모든 노드를 완전히 종료했다가 다시 시작하는 시나리오와, 클러스터가 자동으로 복구되지 않을 때 필요한 수동 부트스트랩 복구 절차를 설명합니다. 이 상황은 실제 운영 환경에서도 발생할 수 있기 때문에 정확한 이해와 절차 숙지가 필요합니다.

1. 정상적인 클러스터 재시작

1.1 클러스터 전체 노드 종료

테스트 환경에서는 세 개의 노드(mariadb1, mariadb2, mariadb3)를 모두 종료합니다.

# 각 노드에서 실행
$ sudo shutdown -h now

노드가 완전히 꺼졌는지 확인한 뒤 다음 단계로 진행합니다.

1.2 전체 노드 재시작 후 클러스터 상태 확인

모든 노드를 다시 기동한 후, 각 노드에서 MariaDB 서비스 상태와 클러스터 크기를 확인합니다.

$ sudo systemctl status mariadb

mysql> SHOW STATUS LIKE 'wsrep_cluster_size';
-- 예상 결과: 3

대부분의 경우 클러스터는 자동으로 복구되며, 이전과 동일한 구성으로 재합류합니다. 데이터베이스 상태도 유지되어야 합니다.

mysql> SELECT * FROM products;

2. 비정상 종료 후 수동 부트스트랩 복구

2.1 비정상 종료 상황 만들기 (테스트 환경)

실제 운영 환경에서는 전원 장애, 시스템 크래시, 강제 재부팅 등으로 인해 클러스터가 비정상 종료될 수 있습니다. 테스트 환경에서 이 상황을 재현하려면 VMware, VirtualBox 같은 가상머신 환경에서 Power Off 기능을 사용하여 세 개 노드를 모두 강제로 종료할 수 있습니다.

VMware vSphere Client / VMware Workstation
1. 각 VM을 선택
2. "Power" → "Power Off" (graceful shutdown이 아닌 강제 종료)
3. 모든 노드에 대해 반복

이렇게 강제 종료하면 MariaDB가 정상적인 종료 절차를 거치지 못하게 되어, 다음과 같은 상황이 발생합니다.

2.2 비정상 종료 후 발생하는 문제

모든 노드가 비정상 종료된 상태에서 재시작하면, 다음과 같은 오류 메시지가 나타날 수 있습니다

Jun 14 15:07:06 mariadb1 mariadbd[2706]: 2025-06-14 15:07:06 0 [Note] WSREP: Failed to establish connection: Connection refused

이 메시지는 Galera가 어느 노드를 기준으로 클러스터를 재구성해야 할지 판단하지 못해 MariaDB 서비스가 기동되지 않는 경우에 출력됩니다. 이때는 수동으로 클러스터를 부트스트랩해야 합니다.

2.3 수동 부트스트랩이 필요한 이유

모든 노드의 /var/lib/mysql/grastate.dat 상태가 다음과 같이 되어 있다면

# GALERA saved state
version: 2.1
uuid:    00bf5689-479a-11f0-b7ef-8e5cfffc9f2a
seqno:   -1
safe_to_bootstrap: 0

seqno: -1은 해당 노드가 비정상 종료되었음을 의미합니다.
safe_to_bootstrap: 0이면 Galera는 이 노드를 기준으로 클러스터를 재구성할 수 없다고 판단합니다.

즉, Galera가 클러스터를 자동으로 시작하지 못하게 되는 것입니다.

3. 수동 부트스트랩 절차

3.1 최신 데이터를 가진 노드 확인

클러스터의 모든 노드가 동시에 다운되었을 때, 각 노드의 데이터 최신성(시퀀스 번호)을 파악하는 것이 중요합니다.

# 각 노드에서 실행
$ sudo -u mysql mysqld --wsrep-recover

명령어 실행 결과 출력에서 [Note] WSREP: Recovered position: <UUID>:<seqno> 형태의 메시지를 찾아 콜론(:) 뒤의 <seqno> 값을 비교합니다.

예시

mariadb1: seqno 19
mariadb2: seqno 21
mariadb3: seqno 21

위 예시에서는 mariadb2와 mariadb3가 seqno 21로 가장 최신 데이터를 가지고 있으므로, 이 중 하나를 Primary Component로 선정합니다.

3.2 Primary Component 부트스트랩

선정된 노드(예: mariadb2)에서 새로운 클러스터를 시작합니다.

# grastate.dat 파일의 safe_to_bootstrap 값이 0이라면 1로 변경
$ sudo sed -i 's/safe_to_bootstrap: 0/safe_to_bootstrap: 1/' /var/lib/mysql/grastate.dat

# 새로운 클러스터 부트스트랩
$ sudo galera_new_cluster

galera_new_cluster 명령을 실행하면 터미널에 즉시 반응이 없을 수 있지만, 다른 터미널에서 서비스 상태를 확인해보세요

$ sudo systemctl status mariadb

로그에서 WSREP: New primary component 메시지를 통해 해당 노드가 성공적으로 Primary Component로 시작되었음을 확인할 수 있습니다.

3.3 나머지 노드들을 클러스터에 조인

Primary Component가 성공적으로 시작된 후, 나머지 노드들을 클러스터에 합류시킵니다.

# 나머지 노드들에서 실행
$ sudo systemctl start mariadb

systemctl status mariadb 로그에서 다른 노드들이 성공적으로 조인하여 데이터 동기화(State transfer ... complete. Member ... synced with group.)를 완료했는지 확인합니다.

3.4 클러스터 상태 최종 확인

모든 노드에서 MariaDB에 접속하여 클러스터 상태를 확인합니다

mysql> SHOW STATUS LIKE 'wsrep_cluster_size';
mysql> SHOW STATUS LIKE 'wsrep_local_state_comment';

wsrep_cluster_size가 모든 노드에서 3으로 나타나고
wsrep_local_state_comment가 모든 노드에서 Synced로 나타나면

클러스터가 완전히 복구되고 정상적으로 동기화되었음을 의미합니다.

4. 결론 및 운영 환경 고려사항

Galera Cluster는 대부분의 경우 노드를 재시작하면 자동으로 복구됩니다. 그러나 모든 노드가 비정상적으로 종료되었거나, 클러스터 상태를 기억할 수 없게 된 경우에는 수동 부트스트랩을 통해 기준 노드를 명확히 지정해줄 필요가 있습니다.

운영 환경에서는 다음을 반드시 고려해야 합니다

수동 부트스트랩 시 반드시 최신 seqno를 가진 노드를 Primary Component로 선정할 것
재기동 시 mysqld --wsrep-recover를 통해 각 노드의 seqno를 먼저 점검할 것
수동 부트스트랩은 데이터 손실 위험이 있으므로 신중히 진행할 것

이번 실습을 통해 배운 복구 절차는 실제 운영 환경에서 클러스터 장애 상황을 해결하는 데 매우 중요한 지식이 됩니다. 특히 seqno 비교를 통한 최신 데이터 노드 선정은 데이터 무결성을 보장하는 핵심 단계입니다.

관련 포스팅

이 블로그 검색

WOOZOO LINUX