[MariaDB] Galera 클러스터 구축3: Garela Cluster 환경 설정

 Galera Cluster는 고가용성과 동기식 복제를 제공하는 MySQL/MariaDB 기반 클러스터입니다. 이번 글에서는 Galera Cluster를 구성하기 위한 server.cnf 파일의 설정 방법과 각 노드에 맞춘 설정 적용 과정을 단계별로 설명합니다.


설정 파일 위치

Galera Cluster 설정은 각 노드의 /etc/my.cnf.d/server.cnf 파일을 수정하여 진행합니다.

이 파일은 MariaDB 설치 설정을 포함하며, 여러 섹션으로 구성되어 있습니다. 이 중 galera 섹션이 클러스터 관련 설정을 포함합니다.


Galera 섹션 주요 설정 항목

galera 섹션에서 다음 항목들을 설정합니다.

[galera]
wsrep_on=ON                                           # write-set 복제 기능 활성화
wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so     # wsrep 프로바이더 모듈 경로
wsrep_cluster_address=gcomm://192.168.155.51,192.168.155.52,192.168.155.53 # group communition
binlog_format=row                                      # 복제 형식은 row 기반 권장
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2                             # auto increment 잠금 모드
bind-address=0.0.0.0                                   # 모든 인터페이스에서 접속 허용
wsrep_cluster_name="galera-cluster"                    # 클러스터 이름
wsrep_sst_method=rsync                                 # SST 방식은 rsync
wsrep_node_address="192.168.155.51"                    # 현재 노드의 IP 주소
wsrep_node_name="gdb01"                                # 현재 노드의 호스트명

참고: wsrep_provider 경로는 시스템에 따라 다를 수 있으므로 존재 여부를 반드시 확인해야 합니다.


노드별 설정 반영

모든 노드에 동일한 설정을 반영하되, 다음 두 항목은 각 노드마다 다르게 지정합니다.

  • wsrep_node_address
  • wsrep_node_name

1번 노드(mariadb1, 192.168.155.51)

기본 템플릿을 작성한 후 아래 명령으로 두 번째, 세 번째 노드에 복사합니다.

# scp /etc/my.cnf.d/server.cnf root@mariadb2:/etc/my.cnf.d/server.cnf
# scp /etc/my.cnf.d/server.cnf root@mariadb3:/etc/my.cnf.d/server.cnf

2번 노드(mariadb2, 192.168.155.52)

server.cnf 수정

wsrep_node_address="192.168.155.52"
wsrep_node_name="mariadb2"

3번 노드(mariadb3, 192.168.155.53)

server.cnf 수정

wsrep_node_address="192.168.155.53"
wsrep_node_name="mariadb3"

Galera Cluster 방화벽 설정 (필수 포트)

포트 번호 프로토콜 용도
3306 TCP MySQL 클라이언트 연결 (기본 포트)
4567 TCP/UDP Galera 클러스터 통신 (gcomm)
4568 TCP State Snapshot Transfer (SST) 시 사용
4444 TCP Incremental State Transfer (IST) 요청 시 사용

firewalld 사용 시 포트 열기 명령

모든 노드에서 다음 명령을 실행해야 합니다

[all]# firewall-cmd --add-port=3306/tcp --permanent
success
[all]# firewall-cmd --add-port=4567/tcp --permanent
success
[all]# firewall-cmd --add-port=4567/udp --permanent
success
[all]# firewall-cmd --add-port=4568/tcp --permanent
success
[all]# firewall-cmd --add-port=4444/tcp --permanent
success
[all]# firewall-cmd --reload
success

Galera Cluster 시작 및 노드 조인 절차

Galera Cluster의 설정을 모두 완료한 후에는 실제로 클러스터를 시작하고 각 노드를 순차적으로 조인(join)시켜야 합니다. 이 과정은 특정 순서와 명령어를 따라야 하며, 부트스트랩 초기화 단계에서는 특별한 주의가 필요합니다.


1. 첫 번째 노드: 클러스터 부트스트랩

왜 galera_new_cluster 명령을 실행하는가?

Galera는 멀티 마스터 구조지만, 클러스터를 처음 시작할 때는 반드시 하나의 노드가 기준이 되어 클러스터를 초기화해야 합니다. 이 역할을 수행하는 것이 바로 galera_new_cluster 명령입니다.

[root@mariadb1 ~]# galera_new_cluster

이 명령은 Galera의 내부 상태를 "Primary Component"로 설정하여, 이후 다른 노드들이 해당 노드를 기준으로 조인할 수 있게 만듭니다. 오직 이 명령은 첫 번째 노드에서만 1회 실행해야 하며, 다른 노드에서 실행하면 클러스터 분할(split-brain) 문제가 발생할 수 있습니다.

클러스터 상태 확인

초기화 후 MySQL에 접속하여 클러스터 상태를 확인합니다.

[root@mariadb1 ~]# mysql -u root -p

-- 클러스터에 참여 중인 노드 수 확인
MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+

1 row in set (0.002 sec)

wsrep_cluster_size = 1 → 현재 노드만 클러스터에 참여한 상태


2. 두 번째 노드: 조인

두 번째 노드는 부트스트랩된 첫 번째 노드를 기준으로 자동 조인되므로, MariaDB 서비스만 시작하면 됩니다.

[root@mariadb2 ~]# systemctl start mariadb

조인 후 클러스터 상태를 다시 확인합니다:

MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 2     |
+--------------------+-------+
1 row in set (0.002 sec)

wsrep_cluster_size = 2 → 두 개의 노드가 클러스터에 연결됨


3. 세 번째 노드: 조인

마지막 노드도 동일하게 MariaDB 서비스만 시작합니다:

[root@mariadb3 ~]# systemctl start mariadb

그리고 모든 노드에서 클러스터 크기를 다시 확인합니다:

MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+
1 row in set (0.001 sec)

wsrep_cluster_size = 3 → 세 노드 모두 클러스터에 정상적으로 참여


확인: 모든 노드 상태 동기화

클러스터가 올바르게 구성되었다면, 세 노드 모두에서 wsrep_cluster_size 값이 3으로 동일해야 합니다. 이 외에도 사용자 계정 정보나 설정값도 자동으로 복제되며, root 비밀번호 등도 클러스터 내에서 공유됩니다.


마치며

이번 글에서는 MariaDB Galera Cluster의 환경 설정부터 클러스터 구축까지의 전체 과정을 다뤘습니다. Galera Cluster는 동기식 복제와 멀티 마스터 구조를 통해 높은 가용성을 제공하지만, 올바른 설정과 절차를 따르는 것이 무엇보다 중요합니다.

특히 주의해야 할 점들을 정리하면

  • 각 노드의 wsrep_node_address와 wsrep_node_name은 반드시 고유해야 합니다
  • 필수 포트(3306, 4567, 4568, 4444)가 모든 노드에서 열려있어야 합니다
  • 클러스터 초기화는 반드시 galera_new_cluster 명령으로 한 번만 수행해야 합니다
  • 나머지 노드들은 순차적으로 MariaDB 서비스를 시작하여 조인시킵니다

댓글

댓글 쓰기

이 블로그의 인기 게시물

[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  모듈을 이용해 관리 노드의...
자세한 내용 보기