[MariaDB] Galera 클러스터 구축6: 노드 강제 종료 시 복제와 Quorum 동작 이해

 MariaDB Galera 클러스터를 운영하다 보면 노드 장애는 피할 수 없는 상황입니다. 정상적인 종료와 갑작스러운 전원 차단, 두 상황에서 클러스터가 어떻게 반응하는지 궁금하지 않으신가요?

이전 포스팅에서는 노드를 정상적으로 종료했을 때의 복제 과정을 다뤘습니다. 이번에는 예기치 못한 노드 장애 상황에서 Galera 클러스터가 어떻게 동작하는지, 그리고 핵심 개념인 Quorum이 무엇인지 실제 테스트를 통해 알아보겠습니다.

실습 환경 준비

테스트를 위한 환경 구성은 다음과 같습니다:

  • 클러스터 구성: 3개 노드 (mariadb1, mariadb2, mariadb3)
  • 테스트 테이블: inventory.products
  • 시나리오: 노드 강제 종료 → Quorum 상실 → 복구 과정

1단계: 클러스터 상태 점검

먼저 모든 노드가 정상적으로 클러스터에 참여하고 있는지 확인해보겠습니다.

mysql> SHOW STATUS LIKE 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

좋습니다! 3개 노드가 모두 정상 상태네요. 이제 테스트용 데이터를 하나 추가해보겠습니다.

mysql> INSERT INTO products VALUES (7, 'Desk Lamp', 15);
Query OK, 1 row affected (0.01 sec)

다른 노드들에서도 데이터가 정상적으로 복제되었는지 확인해보세요. 모든 노드에서 동일한 데이터를 조회할 수 있을 것입니다.

2단계: 첫 번째 노드 강제 종료 테스트

이제 본격적인 테스트를 시작해보겠습니다. mariadb1 노드를 정상적인 shutdown 명령어가 아닌 강제 전원 차단 방식으로 종료해보겠습니다.

VM 환경에서 전원 강제 차단 (예: VirtualBox에서 '전원 끄기' 선택)

나머지 노드에서 클러스터 상태를 확인해보면:

mysql> SHOW STATUS LIKE 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 2     |
+--------------------+-------+

클러스터 크기가 3에서 2로 줄어들었습니다. 이 상태에서 새로운 데이터를 삽입해볼까요?

mysql> INSERT INTO products VALUES (8, 'USB Hub', 25);
Query OK, 1 row affected (0.02 sec)

놀랍게도 아무 문제없이 데이터가 삽입되고 복제됩니다! 바로 Quorum(과반수) 때문입니다. 3노드 중 2노드가 남아있어 과반수 조건을 만족하므로 클러스터가 정상 작동하는 것입니다.

3단계: Quorum 상실 실험 - 진짜 문제는 지금부터

이번에는 mariadb3 노드도 강제로 종료해보겠습니다. 그러면 mariadb2 노드 하나만 남게 됩니다.

# mariadb3 노드 강제 전원 차단

이제 mariadb2에서 간단한 조회 쿼리를 실행해보겠습니다:

mysql> SELECT * FROM products;
ERROR 1047 (08S01): WSREP has not yet prepared node for application use

조회조차 안 됩니다! 이것이 바로 Quorum 상실의 결과입니다.

Galera 클러스터는 과반수 원칙을 엄격하게 따릅니다. 3노드 클러스터에서 노드가 1개만 남으면 과반수(2개 이상)를 만족하지 못해 읽기와 쓰기 모두 차단됩니다. 이는 데이터 일관성을 보장하기 위한 안전장치입니다. 다만, 이는 비정상적인 상황에 해당하며, 노드가 정상적으로 종료된 경우에는 남은 단일 노드로도 Primary Component를 유지할 수 있습니다.

정상 종료 vs 강제 종료: 무엇이 다를까?

MariaDB Galera에서 노드 종료 방식에 따른 차이점을 정리해보겠습니다:

정상 종료 (systemctl stop mariadb)

  • 노드가 클러스터에 이탈 예정을 미리 알림
  • 다른 노드들이 예상된 상황으로 인식
  • Quorum을 유지하는 한 서비스 중단 없음
  • 재시작 시 변경분만 동기화 (IST: Incremental State Transfer)

강제 종료 (전원 차단, 네트워크 단절)

  • 클러스터가 예기치 못한 노드 손실로 인식
  • 다른 노드들이 장애 상황으로 판단
  • Quorum 상실 시 전체 서비스 중단
  • 재시작 시 전체 데이터 재동기화 가능성 (SST: State Snapshot Transfer)

핵심 포인트: 정상 종료는 "계획된 유지보수"이고, 강제 종료는 "예상치 못한 장애"로 취급됩니다.

4단계: 클러스터 복구 과정

이제 노드들을 하나씩 복구해보겠습니다. 먼저 mariadb3부터 시작하겠습니다.

$ sudo systemctl start mariadb

클러스터 상태를 확인해보면:

mysql> SHOW STATUS LIKE 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 2     |
+--------------------+-------+

드디어 2노드로 복구되었습니다! 이제 쿼리도 정상적으로 실행됩니다:

mysql> SELECT * FROM products;
+----+-------------+-------+
| id | name        | price |
+----+-------------+-------+
| 7  | Desk Lamp   | 15    |
| 8  | USB Hub     | 25    |
+----+-------------+-------+

새로운 데이터도 삽입해보겠습니다:

mysql> INSERT INTO products VALUES (9, 'External HDD', 40);
Query OK, 1 row affected (0.01 sec)

마지막으로 mariadb1도 재시작하겠습니다:

$ sudo systemctl start mariadb

모든 노드에서 데이터를 확인해보면:

mysql> SELECT * FROM products;
+----+-------------+-------+
| id | name        | price |
+----+-------------+-------+
| 7  | Desk Lamp   | 15    |
| 8  | USB Hub     | 25    |
| 9  | External HDD| 40    |
+----+-------------+-------+

장애 발생 후에도 모든 데이터가 정상적으로 복제되어 있습니다.

핵심 정리: Quorum과 클러스터 안정성

이번 실습을 통해 확인한 중요한 개념들을 정리해보겠습니다:

Quorum의 중요성

  • Galera는 과반수 노드가 있어야만 정상 동작
  • 과반수 미달 시 읽기/쓰기 모두 차단
  • 데이터 일관성 보장을 위한 핵심 메커니즘

장애 대응 원칙

  • 계획된 점검: 항상 정상 종료 명령어 사용
  • 예상치 못한 장애: Quorum 유지 여부가 서비스 지속성 결정
  • 복구 과정: 노드 재시작 시 자동 데이터 동기화

운영 시 고려사항

  • 3노드 클러스터에서는 최대 1개 노드까지 장애 허용
  • 5노드 클러스터에서는 최대 2개 노드까지 장애 허용
  • 노드 수가 홀수인 것이 Quorum 계산에 유리

마무리

MariaDB Galera 클러스터는 매우 견고한 고가용성 솔루션이지만, Quorum 개념을 제대로 이해하지 못하면 예상치 못한 서비스 중단을 경험할 수 있습니다.

특히 운영 환경에서는 노드 점검 시 반드시 정상 종료 절차를 따르고, 전체 클러스터의 노드 수와 장애 허용 범위를 미리 계산해두는 것이 중요합니다.


관련 포스팅

댓글

댓글 쓰기

이 블로그의 인기 게시물

[Linux] RHEL Local YUM Repository 구성

이미지
RHEL(Redhat Enterprise Linux)에 Local YUM Repository 구성하는 방법에 대하여 설명합니다. 레드햇 리눅스 같은 경우 기업환경의 인터넷이 되지 않는 환경에서 사용되는 경우가 많은데 Local YUM Repository를 구성하여 패키지를 쉽게 설치할 수 있습니다.   테스트 환경 • Red Hat Enterprise Linux (RHEL)   Local YUM Repository 구성 목적 Local YUM Repository를 구성하는 방법에 여러 가지가 있지만 가장 간단한 방법인 설치 CD를 이용해 구성하는 방법에 대해 소개합니다. 주로 이 방법은 OS 엔지니어가 RHEL을 설치 후 사용하며, local repo를 서버에 구성한 뒤 철수합니다. 그러면 애플리케이션 측에서 추가 패키지를 요청하여도 서버 관리자분들이 yum 명령어를 사용하여 쉽게 서버에 설치할 수 있습니다.   Local YUM Repository 설정 레드햇 설치 CD에는 기본 RHEL 서브스크립션에서 제공하는 RPM 패키지들이 모두 포함되어 있습니다. 따라서 RHEL을 설치한 버전과 동일한 ISO 파일 이 준비되어 있어야 하며, 이를 통해 로컬 저장소를 구성할 수 있습니다.   VMware Workstation을 기준으로 설명하자면, RHEL ISO 파일을 가상 머신에 마운트 하면 됩니다. ISO 파일이 마운트되면 시스템은 자동으로 /dev/sr0 장치를 생성하게 되며, 이는 udev 에 의해 처리됩니다.   CD가 삽입되면 시스템에서는 /dev/sr0 장치를 자동으로 생성합니다. 이 장치는 **광학 디스크 장치(CD/DVD)**로 인식되며, 이를 확인하는 가장 쉬운 방법은 lsblk 명령어를 사용하는 것입니다. # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 2G 0 disk └─mpatha ...
자세한 내용 보기

[Linux Command] sudo command 설명

이미지
  이번 글에서는 Linux 명령어 중 sudo 명령어에 대해 알아보겠습니다. 일반 사용자에게 "root" 권한을 부여하려면 보통 root 계정의 비밀번호를 제공해야 합니다. 이후 사용자는 su 명령어를 통해 root 계정으로 로그인할 수 있습니다. root 계정은 시스템 내 모든 명령을 실행할 수 있는 강력한 권한을 가지고 있기 때문에, 신중한 관리가 필요합니다. 리눅스에 익숙하지 않은 사용자가 root 권한을 사용할 경우, 시스템 운영에 필요한 핵심 파일이 삭제되거나 권한 설정이 변경되는 등의 사고가 발생할 수 있습니다. sudo 기능을 사용하면 root 전체 권한이 아닌 특정 명령어만 일반 사용자에게 허용할 수 있어 이러한 위험을 줄일 수 있습니다. 또한, 사용 권한은 부여하되 root 비밀번호를 공개하지 않아도 된다는 점도 sudo 의 중요한 장점 중 하나입니다.   환경 : Red Hat Enterprise Linux (RHEL)   sudo command 개념 명령어 사용법을 보기 전에, sudo 명령어로 어떤 작업이 가능한지 먼저 알아보겠습니다. 일반 사용자가 /etc/shadow 파일을 열려고 하면 권한 부족으로 인해 파일을 열 수 없습니다. 아래는 실제 출력 예시입니다. 일반유저로 shadow파일 오픈 실패 [user1@localhost ~]$ cat /etc/shadow cat: /etc/shadow: Permission denied 또한 mount 명령어도 일반 사용자 권한으로는 실행할 수 없습니다. 일반 유저로 mount 명령 실패 [user1@localhost sbin]$ mount /dev/sr0 /media mount: only root can do that 이제 일반 사용자에게 mount 명령어만 sudo 를 통해 root 권한으로 실행할 수 있도록 설정해보겠습니다. [user1@localhost ~]$ sudo mount /dev/...
자세한 내용 보기

[Ansible Modules] Fetch module 설명 및 활용

이미지
  Ansible modules 중 하나인 Fetch module에 대해 알아보겠습니다. Fetch는 관리 대상 노드에서 제어 노드로 파일을 복사해 오는 데 사용되는 모듈입니다 Fetch module 이란 Fetch는 영어로 "가져오다"라는 의미입니다. Ansible의 copy 모듈과 반대로 동작하는 기능으로, copy 가 제어 노드에서 관리 노드로 파일을 전송하는 데 사용된다면, fetch 는 그 반대 방향으로, 관리 대상 노드의 파일을 제어 노드로 복사해 오는 데 사용됩니다. 여기서 제어 노드(control node)는 Ansible을 실행하는 노드를, 관리 노드(managed node)는 Ansible로 관리되는 대상 시스템을 의미합니다. Ansible modules(fetch_module) Fetch module 옵션   fetch 모듈에서 주로 사용되는 주요 옵션은 다음과 같습니다: src : 관리 대상 노드에서 복사해 올 파일의 경로입니다. dest : 제어 노드에 파일을 저장할 경로입니다. flat (기본값: false ) false : {{ inventory_hostname }}/path/to/file 형태의 디렉토리 구조로 파일이 저장됩니다. 호스트별로 디렉토리가 생성되므로 여러 노드에서 같은 파일 경로를 가져올 때 유용합니다. true : 파일 경로 구조 없이 파일만 단순 복사됩니다. 이름이 같은 파일은 덮어써지기 때문에, 관리 노드가 하나이거나 파일명이 충돌하지 않는 경우에 적합합니다. 또한 디렉토리를 지정할 경우 dest 경로 끝에 슬래시( / )를 반드시 붙여야 합니다. Fetch module 사용 방법 예제에서는 다음과 같은 인벤토리 파일을 사용합니다. [test] rocky86.lab.example.com rocky84.lab.example.com   예제 1. 기본값( flat: false )으로 파일 가져오기 fetch  모듈을 이용해 관리 노드의...
자세한 내용 보기