WOOZOO LINUX

 내부 서비스에서 TLS 보안 연결을 구성할 때 외부 인증 기관(CA)을 사용하는 대신, 자체 서명된 인증서를 기반으로 사설 CA(Private CA)를 구성하는 방식이 종종 사용됩니다. 특히 비용 절감이나 내부 네트워크 전용 인증이 필요한 경우 적합한 접근법입니다. 이 문서에서는 OpenSSL을 사용하여 자체 서명된 CA를 구성하는 방법을 단계별로 안내합니다. 1. 준비 사항 루트 권한 또는 sudo 명령을 사용할 수 있는 계정 OpenSSL이 설치된 리눅스 시스템 2. 자체 서명된 CA 생성 절차 2.1 CA용 개인 키 생성 256비트 ECDSA(Elliptic Curve Digital Signature Algorithm) 기반의 키를 생성합니다. 키 생성 속도는 하드웨어 성능과 엔트로피 수준에 따라 달라질 수 있습니다. # openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out ca.key 2.2 자체 서명된 CA 인증서 생성 위에서 생성한 ca.key 를 기반으로 CA 인증서를 생성합니다. 인증서는 X.509 형식이며, 유효 기간은 10년(3650일)로 설정합니다. # openssl req -key ca.key -new -x509 -days 3650 \\ -addext keyUsage=critical,keyCertSign,cRLSign \\ -subj "/CN=Example_CA" -out ca.crt /CN=Example_CA 는 CA의 Common Name입니다. 필요에 따라 적절한 명칭으로 변경하세요. 3. 보안 설정 CA 개인 키 파일의 권한을 적절히 설정하여 무단 접근을 차단합니다. # chown root:root ca.key # chmod 600 ca.key 4. 클라이언트에 인증서 등록 (선택사항) 생성한 ca.crt 파일을 시스템 전체에서 신뢰하도록 하려면, trust 명령어를 사용해 볼 수 있습니다. 이 명...

 Galera Cluster를 처음 도입하려는 개발자들이 가장 자주 묻는 질문이 있습니다. "왜 최소 3개의 노드가 필요한가요? 비용 절감을 위해 2개로는 안 되나요?" 이 질문의 답은 데이터베이스 클러스터링의 핵심 개념인 Weighted Quorum 과 Split Brain 문제에서 찾을 수 있습니다. 오늘은 이 두 개념을 깊이 있게 살펴보고, 안정적인 Galera Cluster 구축 방법을 알아보겠습니다. Split Brain 문제란 무엇인가? Split Brain은 다중 마스터 데이터베이스 시스템에서 발생하는 가장 심각한 문제 중 하나입니다. 이는 클러스터 내 노드들 간의 네트워크 통신이 끊어졌지만, 각 노드가 여전히 클라이언트와 연결되어 독립적으로 작동할 때 발생합니다. 실제 상황으로 이해하는 Split Brain 온라인 쇼핑몰의 재고 관리 시스템을 예로 들어보겠습니다 상황 : Server A와 Server B 간의 네트워크 연결이 끊어짐 문제 발생 : 두 서버 모두 각각의 웹 애플리케이션으로부터 주문 요청을 받음 Server A : 상품 재고를 100개에서 95개로 업데이트 (5개 판매) Server B : 같은 상품 재고를 100개에서 80개로 업데이트 (20개 판매) 각 서버는 상대방이 장애 상태라고 판단하고 독립적으로 운영을 계속합니다. 결과적으로 동일한 상품에 대해 서로 다른 재고 수량이 기록되어 데이터 정합성 에 치명적인 오류가 발생하게 됩니다. 네트워크가 복구된 후에는 어떤 데이터가 올바른지 판단하기 어려워지고, 수동으로 데이터를 정리해야 하는 상황이 발생할 수 있습니다. Weighted Quorum의 핵심 원리 Quorum의 기본 개념 Quorum(정족수)은 클러스터 내에서 유효한 결정을 내리기 위해 필요한 최소 투표 수 를 의미합니다. Galera Cluster에서는 각 노드를 하나의 투표권으로 간주하고, 현재 활성화된 노드 수에 따라 정족수를 동적으로 계산합니다. Galera는 클러스터...

 이번 글에서는 기존에 구성된 Galera 클러스터(3노드)에 새로운 노드( mariadb4 )를 추가하는 과정을 단계별로 설명합니다. 이 과정을 통해 클러스터의 가용성과 확장성을 높일 수 있으며, 실무 환경에서도 자주 활용되는 중요한 작업입니다. 1. 환경 정보 노드 이름 IP 주소 mariadb1 192.168.155.51 mariadb2 192.168.155.52 mariadb3 192.168.155.53 mariadb4 192.168.155.54 2. 신규 노드 초기 설정 (mariadb4) IP설정 및 hostname 설정 # hostnamectl set-hostname mariadb4 # nmcli connection modify enp1s0 ipv4.addresses 192.168.155.54/24 ipv4.gateway 192.168.155.1 ipv4.dns 8.8.8.8 autoconnect on ipv4.method manual 방화벽 설정 새로운 노드에서 Galera 클러스터 통신을 위한 포트를 열어줍니다. # firewall-cmd --add-port=3306/tcp --permanent # MySQL/MariaDB 포트 # firewall-cmd --add-port=4567/tcp --permanent # Galera 복제 트래픽 # firewall-cmd --add-port=4567/udp --permanent # Galera 복제 트래픽 (UDP) # firewall-cmd --add-port=4568/tcp --permanent # IST (Incremental State Transfer) # firewall-cmd --add-port=4444/tcp --permanent # SST (State Snapshot Transfer) # firewall-cmd --reload 호스트 파일 설정 모든 노드(기존 노드 포함)에서 새로운 노드의 호스트 정...

 이번 글에서는 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 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 명령어가 아닌 강제 전원 차단 방식으로 종...

  Galera Cluster의 가장 강력한 기능 중 하나는 노드가 재시작되거나 일시적으로 오프라인이 되더라도 데이터 일관성을 유지하는 동기 복제 구조 입니다. 이번 글에서는 일부 노드를 정상적으로 종료(shutdown)한 후, 재시작했을 때 데이터가 정상 복제되는지 확인하는 과정을 실습을 통해 검증해보겠습니다. 클러스터 상태 확인 먼저 현재 클러스터가 정상적으로 3개 노드로 구성되어 있는지 확인합니다. mysql> SHOW STATUS LIKE 'wsrep_cluster_size'; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 3 | +--------------------+-------+ 클러스터 크기가 3이면 모든 노드가 정상 참여 중입니다. 테스트 데이터 준비 테스트를 위해 inventory 데이터베이스의 products 테이블에 몇 개의 데이터를 미리 삽입해둡니다. mysql> USE inventory; mysql> SELECT * FROM products; +------------+--------------+----------+ | product_id | product_name | quantity | +------------+--------------+----------+ | 1 | Notebook | 50 | | 2 | Pen | 100 | | 3 | Monitor | 30 | +------------+--------------+----------+ 여기에 새 데이터를 추가합니다: mysql> INSERT INTO products VALUES (4, 'Keyboard', 20); 모든 노드에서 SEL...

 Galera Cluster의 가장 중요한 특징 중 하나는 각 노드 간의 실시간 데이터 복제입니다. 이번 글에서는 이를 직접 테스트해보는 과정을 소개합니다. 새롭게 구성한 예제를 기반으로 데이터베이스를 생성하고, 테이블을 만들고, 각 노드에 데이터를 삽입하여 복제가 제대로 이루어지는지 확인해보겠습니다. 테스트 시나리오 데이터베이스 이름: inventory 테이블 이름: products 테이블 구성: 제품 ID, 제품명, 수량 엔진: InnoDB (Galera는 InnoDB만 지원) Galera Cluster 노드: mariadb1, mariadb2, mariadb3 1. 데이터베이스 생성 $ mysql -u root -p Enter password: ****** -- 데이터베이스 생성 mysql> CREATE DATABASE inventory; -- 확인 mysql> SHOW DATABASES; 생성된 inventory 데이터베이스는 Galera의 복제를 통해 나머지 노드에도 자동으로 생성됩니다 . mariadb2와 mariadb3에서도 동일하게 확인합니다. 2. 테이블 생성 이제 inventory 데이터베이스에 products 테이블을 생성합니다. mysql> USE inventory; mysql> CREATE TABLE products ( product_id INT PRIMARY KEY, product_name VARCHAR(100), quantity INT ) ENGINE=InnoDB; mysql> SHOW TABLES; 각 노드에서 SHOW TABLES 를 실행하면 동일한 테이블이 존재함을 확인할 수 있습니다. 3. 데이터 삽입 및 복제 확인 세 노드 각각에서 서로 다른 데이터를 삽입해보고, 복제가 잘 되는지 확인해보겠습니다. -- mariadb1에서 실행 mysql> INSERT INTO products VALUES (1, 'Notebook',...

 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 ...

 레드햇 8.8의 경우에도 MariaDB 10.3과 10.5 버전이 제공됩니다. 본 문서에서는 버전을 한단계 더 올려서 10.6으로 레드햇 제공하는 제품이 아닌 MariaDB 공식 사이트에서 제공하는 버전을 이용해서 설치해 보도록 하겠습니다. 사전 준비 세 개의 노드(mariadb1, mariadb2, mariadb3)가 준비되어 있어야 합니다. 1. Mariadb 저장소 추가 Mariadb 공식 웹사이트에서는 버전별 저장소 설정 방법을 제공합니다. 레포주소 참고 사이트 아래와 같이 /etc/yum.repos.d/MariaDB.repo 파일을 생성하고 내용을 추가합니다. # vi /etc/yum.repos.d/MariaDB.repo # MariaDB 10.6 RedHatEnterpriseLinux repository list - created 2025-06-11 14:02 UTC # <https://mariadb.org/download/> [mariadb] name = MariaDB # rpm.mariadb.org is a dynamic mirror if your preferred mirror goes offline. See <https://mariadb.org/mirrorbits/> for details. # baseurl = <https://rpm.mariadb.org/10.6/rhel/$releasever/$basearch> baseurl = <https://tw1.mirror.blendbyte.net/mariadb/yum/10.6/rhel/$releasever/$basearch> module_hotfixes = 1 # gpgkey = <https://rpm.mariadb.org/RPM-GPG-KEY-MariaDB> gpgkey = <https://tw1.mirror.blendbyte.net/mariadb/yum/RPM-GPG-KEY-MariaDB> gpgcheck =...

 Galera 클러스터는 고가용성 데이터베이스 시스템을 위한 강력한 솔루션이에요. 이 가이드는 RHEL 8.8 환경에서 Galera 클러스터를 성공적으로 구축하기 위한 필수적인 사전 준비 단계를 안내합니다. 이 문서에서는 RHEL설치에 관련된 내용을 다루지 않으므로 설치 관련해서는 아래 글을 참고해 주시기 바랍니다. RHEL 무료 다운로드 방법 링크 RHEL 설치 가이드 링크 1. 하드웨어 및 가상 머신 요구사항 Galera 클러스터를 구성하려면 최소 3개의 노드 가 필요해요. 각 노드는 안정적인 클러스터 운영을 위해 충분한 하드웨어 사양을 갖춰야 합니다. 준비된 노드 : mariadb1 (192.168.155.51) mariadb2 (192.168.155.52) mariadb3 (192.168.155.53) 성능 균일성 : 클러스터 성능 저하를 막기 위해 모든 노드의 성능이 균일 해야 합니다. 단일 노드의 성능 저하는 전체 클러스터에 영향을 미칠 수 있습니다. 스왑 공간 : 시스템의 안정적인 동작을 위해 충분한 스왑 공간 을 확보해야 합니다. 2. 네트워크 및 호스트 파일 설정 Galera 클러스터는 호스트 이름을 기반으로 노드 간 통신을 수행하므로, 정확한 네트워크 및 호스트 파일 설정이 필수적입니다. /etc/hosts 파일에 각 서버의 IP 주소와 호스트 이름 을 매핑하여 등록합니다. 이 설정은 클러스터 내 모든 노드에 동일하게 적용 되어야 합니다! 192.168.155.51 mariadb1 192.168.155.52 mariadb2 192.168.155.53 mariadb3 인터넷 연결 확인 나중에 Galera 패키지 다운로드를 위해 각 노드에서 인터넷 연결이 원활한지 확인합니다. [root@mariadb1 ~]# ping google.com PING google.com (142.250.206.238) 56(84) bytes of data. 64 bytes from kix06s10-in-f...

  물리 서버의 수요가 줄고 클라우드 서비스가 보편화되었으며, 클라우드 VM에서는 OS 설치가 필요 없기 때문에 아직 리눅스 설치를 경험해보지 않은 분들도 많으실 것입니다. 하지만 금융권이나 내부망 기반 조직에서는 여전히 물리 서버 또는 VMware 기반의 환경에서 운영체제를 설치하고 사용하는 경우가 많아, 기본적인 설치 방법은 숙지해둘 필요가 있습니다. 또한 개인 테스트 용도로 VirtualBox를 활용하여 RHEL을 설치하면 클라우드 사용에 따른 비용을 절감할 수 있습니다. 본 문서에서는 RHEL 9.4를 기준으로 설치 과정을 정리합니다. 설치 이미지 준비 이전에 받은 설치 이미지를 보면 그 용량이 매우 크다는 것을 알 수 있습니다. RHEL7 버전까지만 하더라도 설치 이미지의 크기는 약 4GB에 불과했지만, RHEL9.4 버전에서는 11GB로 커졌습니다. RHEL8 버전부터 설치 이미지에 변화가 있었는데, 이는 바로 AppStream의 등장 때문입니다. AppStream 관련 내용은 뒷부분의 레포 설정에서 다루고 있습니다. rhel-9.2-x86_64-dvd.iso - 9.0G rhel-9.4-x86_64-dvd.iso - 11G 물리 서버에 RHEL8 이상 버전을 설치해보신 분들은 이제 CD로 설치하는 것이 어려워졌다는 것을 잘 알고 있을 것입니다. 블루레이를 사용할 수도 있지만, 블루레이 전용 CD Writer가 필요하고 이를 휴대하기 번거로우며, CD 비용 또한 이전보다 높습니다. 따라서 가장 효율적인 방법은 USB 부팅 이미지를 만드는 것입니다. 가장 널리 사용되는 도구는 아래에 소개된 Rufus입니다. 다운로드한 ISO 이미지를 Rufus 도구를 사용하여 부팅 가능한 USB로 만들면 물리 서버에 설치할 준비가 완료됩니다. 또한, USB를 사용하는 장점 중 하나는 빠른 설치 속도입니다. 혼자서 설치를 진행하는 경우 USB 두 개면 충분합니다. 설치 시간이 10분도 걸리지 않기 때문에 한 대의 설치를 시작한 후 다른 대의 설치를 진행할 때쯤이...

  리눅스 환경에서 윈도우에서 작성된 파일을 옮겨 사용할 때, 예상치 못한 오류를 만나는 경우가 종종 있습니다. 특히 쉘 스크립트 파일을 실행할 때 다음과 같은 에러를 경험할 수 있습니다. # ./helloworld.sh -bash: ./helloworld.sh: /bin/bash^M: bad interpreter: No such file or directory 파일을 열어보면 정상적인 것처럼 보입니다. # cat helloworld.sh #!/bin/bash echo "Hello World" 그러나 sh 명령어로 강제로 실행을 시도하면 또 다른 문제가 발생합니다. # sh helloworld.sh helloworld.sh: line 2: $'\\r': command not found Hello World 이 문제의 원인은 바로 윈도우와 리눅스의 개행문자 차이 입니다. Windows : CRLF ( \\r\\n ) Linux : LF ( \\n ) 윈도우에서 작성된 파일은 줄 끝마다 \\r (Carriage Return)이 추가되는데, 리눅스 쉘은 이를 인식하지 못하고 오류를 일으킵니다. 파일에 개행문자(^M)가 들어있는지 확인하는 방법 리눅스에서는 파일 끝에 붙어 있는 ^M 과 같은 비가시성 문자를 기본 출력에서는 확인할 수 없습니다. 따라서 다음과 같은 방법을 통해 윈도우 스타일 개행문자( \\r\\n , CRLF)가 포함되어 있는지 확인할 수 있습니다. 1. vi -b 옵션 사용 vi 편집기의 -b (binary mode) 옵션을 이용하면, 바이너리 모드로 파일을 열어 숨겨진 제어 문자를 확인할 수 있습니다. # vi -b <filename> 열어보면 줄 끝마다 ^M 이 붙어 있는 것을 확인할 수 있습니다. test^M ^M Hello World^M Good Morning!!^M 이 방법은 파일 전체를 눈으로 직접 확인하고 수정할 수 있다는 장점이 있습니다. 2. cat -v...

  문제 개요 RHEL 9부터 LVM2는 부팅 속도 향상과 디바이스 식별 정확성을 위해 /etc/lvm/devices/system.devices 파일을 기본 활성화( use_devicesfile=1 )했습니다. 이 파일은 물리 볼륨(PV)의 PVID와 디바이스 식별 정보(IDNAME)를 캐싱합니다. 하지만 디스크 복제나 클라우드 환경에서 디바이스 ID(특히 WWID나 devname)가 변경될 경우, 기존 system.devices 파일과 일치하지 않아 LVM이 PV를 인식하지 못하는 문제가 발생할 수 있습니다. 대표 증상 pvs , vgs , lvs 명령어 실행 시 출력 없음 Devices file PVID last seen on /dev/sdX not found. 경고 발생 근본 원인 system.devices 파일은 sys_wwid(디스크 고유 WWID)나 sys_serial(디스크 Serial Number)을 기준으로 관리됩니다. 그러나 디스크 복제 과정에서 시리얼 넘버가 변경되면서 기존 system.devices 파일에 저장된 정보와 불일치가 발생해 LVM 볼륨 정보를 정상적으로 인식할 수 없게 됩니다. 현재 system.devices 파일은 다음과 같은 형식으로 구성되어 있습니다. IDTYPE=sys_serial IDNAME=a5308b98-fa11-4ae3-b... DEVNAME=/dev/vdb1 PVID=... IDTYPE=sys_serial IDNAME=a6921fd5-d892-4ec1-8... DEVNAME=/dev/vdc1 PVID=... 필드 의미 IDTYPE       장치 식별 방법 (sys_serial) IDNAME       디스크 시리얼 넘버 (UUID 형식과 유사) DEVNAME       디바이스 노드 (예: /dev/vdb1) PVID       ...

 Galera Cluster는 높은 데이터 일관성과 가용성을 제공하지만, 몇 가지 주의해야 할 제한사항이 존재합니다. 안정적인 클러스터 운영을 위해 반드시 알고 넘어가야 할 부분을 정리했습니다. 1. InnoDB 스토리지 엔진만 지원 Galera Cluster는 InnoDB 전용 입니다. 트랜잭션 지원, 행 단위 잠금, 데이터 무결성 보장 등 Galera가 요구하는 기능을 InnoDB만이 충족할 수 있기 때문입니다. MyISAM 같은 다른 스토리지 엔진은 트랜잭션을 지원하지 않아 Galera 환경에서 복제가 불안정할 수 있습니다. 특히 시스템 데이터베이스( mysql DB)는 MyISAM 기반이라 직접적인 데이터 쓰기( INSERT , UPDATE )는 복제되지 않습니다. 대신 CREATE USER 와 같은 DDL 명령어 는 복제됩니다. MyISAM 복제를 실험적으로 지원하는 wsrep_replicate_myisam 설정도 있지만, 실무에서는 사용을 권장하지 않습니다. InnoDB, 왜 중요할까요? InnoDB는 MySQL과 MariaDB에서 기본으로 사용하는 스토리지 엔진입니다. 주요 특징은 다음과 같습니다: 트랜잭션 지원 : 데이터 작업을 안전하게 처리해 일관성과 무결성을 보장합니다. 행(Row) 단위 잠금 : 데이터 수정 시 테이블 전체가 아닌 특정 행에만 잠금을 걸어 높은 동시성을 제공합니다. 참조 무결성(FOREIGN KEY) 지원 : 테이블 간 관계를 강제해 데이터 정합성을 유지합니다. 크래시 복구 : 장애 발생 시 로그 파일을 통해 데이터 복구가 가능합니다. 이런 특성 덕분에 Galera Cluster의 동기식 복제 및 충돌 감지 메커니즘 과 완벽하게 호환됩니다. 참고: MySQL/MariaDB는 InnoDB 외에도 다양한 스토리지 엔진을 제공합니다. MyISAM, MEMORY, CSV, ARCHIVE, Aria, ColumnStore, MyRocks 등이 있지만, 대부분의 실무 환경에서는 InnoDB 사용이...

 Galera Cluster를 운영하다 보면 새로운 노드를 클러스터에 추가하거나, 장애 복구를 위해 노드를 다시 동기화해야 하는 상황이 발생합니다. 이때 기존 클러스터의 데이터를 새 노드에 복제하는 과정을 State Transfer 라고 부릅니다. 이번 글에서는 Galera Cluster의 State Transfer 개념과 그 방법에 대해 정리해보겠습니다. State Transfer란? State Transfer는 클러스터에 조인하는 새로운 노드와 기존 노드 간의 데이터 동기화 과정을 의미합니다. 즉, 기존에 클러스터가 보유하고 있던 데이터를 새 노드로 복제하여 동일한 데이터 상태를 갖게 만드는 작업입니다. 이 과정을 Provisioning 이라고도 부릅니다. Provisioning 방법 Galera Cluster는 노드를 프로비저닝하는 두 가지 주요 방법을 제공합니다. 1. State Snapshot Transfer (SST) SST 는 기존 노드의 전체 데이터를 새로운 노드로 복제하는 방법입니다. SST는 다음 두 가지 방식으로 구분할 수 있습니다. Logical 방법 mysqldump 를 이용해 데이터베이스를 백업한 후, 이를 새 노드에 복구합니다. 비교적 단순하지만, 데이터 용량이 크면 시간이 오래 걸릴 수 있습니다. Physical 방법 데이터 파일 자체를 복사합니다. 대표적으로 rsync 를 사용해 변경된 파일만 효율적으로 복제할 수 있습니다. 파일 복사 방식이기 때문에 대용량 데이터 환경에서 빠른 동기화가 가능합니다. SST는 새로운 노드가 비어 있는 상태이거나, 기존 데이터와 클러스터 데이터 간 차이가 클 때 사용됩니다. 2. Incremental State Transfer (IST) IST 는 기존 데이터를 어느 정도 보유하고 있는 노드에 대해서 누락된 트랜잭션만 복제하는 방법입니다. 클러스터는 새 노드(Joiner)의 상태를 확인한 후, 누락된 트랜잭션만 전송합니다. 전체 데이터를 복제할 필요가...