WOOZOO LINUX

 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)의 상태를 확인한 후, 누락된 트랜잭션만 전송합니다. 전체 데이터를 복제할 필요가...

 분산 데이터베이스 환경에서 데이터 무결성과 일관성을 유지하는 것은 시스템 신뢰성의 핵심입니다. 특히 여러 트랜잭션이 동시에 동일한 데이터를 수정할 때 발생할 수 있는 Lost Update 문제는 치명적인 결과를 초래할 수 있습니다. 이번 글에서는 Galera Cluster가 이 문제를 어떻게 해결하는지 알아보겠습니다. Lost Update 문제란? Lost Update는 두 개 이상의 트랜잭션이 같은 레코드를 동시에 수정하려고 할 때 발생합니다. 한 트랜잭션의 변경 사항이 다른 트랜잭션에 의해 덮어씌워져 데이터 유실이 일어나는 현상입니다. 일반적으로 Repeatable Read 격리 수준을 사용하면 트랜잭션은 시작 시점의 데이터를 스냅샷으로 읽기 때문에 읽기 일관성은 보장되지만, 이 방식만으로는 쓰기 충돌(Lost Update)을 막을 수 없습니다. 전통적 MySQL InnoDB 환경에서의 문제 MySQL InnoDB는 row-level locking 을 사용해 트랜잭션 간 충돌을 최소화하려 합니다. 그러나 트랜잭션 간 락이 해제된 후, 다른 트랜잭션이 이전 스냅샷의 데이터를 기반으로 업데이트를 수행하게 되면 여전히 Lost Update 문제가 발생할 수 있습니다. Galera Cluster의 해결 전략 Galera Cluster는 이 문제를 근본적으로 해결하기 위해 두 가지 메커니즘을 제공합니다. Snapshot Isolation과 First Committer Wins Galera Cluster는 Snapshot Isolation 을 지원하며, 트랜잭션 커밋 시점에 First Committer Wins 규칙을 적용합니다. 먼저 커밋을 시도한 트랜잭션이 성공하고, 이후 커밋을 시도하는 트랜잭션은 Certification 단계 에서 충돌이 감지되어 롤백됩니다. 이를 통해 Lost Update뿐만 아니라 Dirty Write와 같은 다른 동시성 문제도 효과적으로 방지할 수 있습니다. SELECT FOR UPDATE를 통한 사전 충돌 ...

  Isolation이란? Isolation 은 여러 트랜잭션이 동시에 실행될 때, 서로의 작업에 간섭하지 않도록 하는 성질입니다. 격리 수준이 없으면 데이터 충돌이나 무결성 오류가 발생할 수 있습니다. 높은 격리 수준 → 데이터 무결성 확보, 성능 저하. 낮은 격리 수준 → 성능 향상, 무결성 위험 증가. Isolation Level이 필요한 이유 동시에 두 트랜잭션이 같은 레코드( X=500 )를 업데이트하려 할 때: 트랜잭션1: X + 500 (→ 1000으로 업데이트 후 커밋) 트랜잭션2: 이전 값 500 을 읽고 500 - 500 = 0 을 저장 (잘못된 결과) Isolation 이 없다면 트랜잭션2가 잘못된 오래된 데이터를 기반으로 처리하게 되어 데이터 불일치 가 발생. Galera Cluster의 Isolation Level 종류 1. Read Uncommitted (Dirty Read) 커밋되지 않은 데이터도 읽을 수 있음. Isolation이 거의 없음 , 데이터 무결성 위험. 2. Read Committed 커밋된 데이터만 읽을 수 있음. 각각의 쿼리는 다른 스냅샷 을 참조할 수 있어 읽을 때마다 값이 변할 수 있음. 3. Repeatable Read 첫 SELECT 시점 의 데이터 스냅샷을 기준으로 모든 쿼리 수행. 이후 커밋된 다른 트랜잭션의 변경사항은 보이지 않음. MySQL InnoDB의 기본값 . Galera Cluster의 동기식 복제 메커니즘 과 충돌 감지 특성 때문에, 멀티마스터 환경에서는 사실상 Repeatable Read 가 유일하게 안정적으로 작동 하는 격리 수준입니다. 4. Serializable 모든 행에 읽기 잠금(Read Lock)을 걸어 데이터 충돌 방지. 사실상 Read Only 트랜잭션 처럼 동작. 가장 높은 격리 수준으로, Phantom Read 를 포함한 모든 이상 현상을 방지. 그러나 동시성을 크게 저해하여, Galera Clu...

 Galera Cluster는 Certification 기반 복제(Certification-Based Replication)를 통해 데이터베이스 동기화를 구현하며, 고가용성과 데이터 일관성이라는 두 가지 목표를 동시에 추구합니다. 이 글에서는 Galera Cluster의 동작 원리, 핵심 메커니즘, 그리고 실무 운영 전략까지 다루어 보겠습니다. Galera Cluster란? Galera Cluster는 멀티 마스터(Multi-Master) 구조를 가진 데이터베이스 클러스터입니다. 모든 노드가 읽기와 쓰기 작업을 처리할 수 있으며, Virtually Synchronous Replication 방식을 통해 분산 환경에서도 데이터 일관성을 유지합니다. Virtually Synchronous Replication Galera Cluster는 완전 동기 복제 가 아니라, 트랜잭션을 로컬에서 낙관적으로 실행한 후 커밋 시점에 Certification 을 통해 충돌 여부를 검증하는 방식을 채택합니다. 이 과정을 통해 거의 실시간 동기화 를 달성하며, 이를 Virtually Synchronous Replication 이라고 부릅니다. Certification 기반 복제란? Certification 기반 복제는 트랜잭션을 커밋하기 전에 충돌 검증(certification)을 통해 데이터의 무결성을 확인하는 방식입니다. 이 방식은 Galera Cluster가 Virtually Synchronous Replication을 구현하는 데 필수적인 여러 핵심 기술을 포함합니다. 주요 기술로는 다음이 있습니다: 그룹 커뮤니케이션 (Group Communication) Write Set 트랜잭션 재정렬 (Transaction Reordering) 데이터베이스 상태 기계 (Database State Machine) 핵심 구성 요소 그룹 커뮤니케이션 (Group Communication) 클러스터 내 노드 추가/제거 를 관리합니다. 장애 감지 를 수행...

 데이터베이스 복제는 시스템의 확장성과 안정성을 위해 필수적인 기술입니다. 이번 글에서는 비동기(Asynchronous), 동기(Synchronous), 세미 동기(Semi-Synchronous) 복제 방식을 비교하고 각각의 특성을 살펴보겠습니다. 비동기 복제 (Asynchronous Replication) 비동기 복제는 데이터베이스 서버가 클라이언트로부터 업데이트 요청을 받으면 먼저 로컬 데이터베이스에만 적용 하고, 클라이언트에게 커밋 응답을 보낸 후 다른 노드로 변경 사항을 전파 하는 방식입니다. 특징 변경사항은 binary log 를 통해 전파됩니다. 복제 지연이 발생할 수 있으며, 일부 노드는 최신 데이터 반영이 늦어질 수 있습니다. 장점 저대역폭 , 장거리 네트워크 환경에서도 효율적으로 동작합니다. 빠른 처리 속도로 높은 성능을 제공합니다. 단점 노드 간 데이터 불일치 가능성이 존재합니다. 장애 발생 시, 데이터 손실 가능성이 있습니다. 동기 복제 (Synchronous Replication) 동기 복제는 모든 노드에 데이터가 동시에 적용 된 것을 확인한 후에야 클라이언트에게 커밋 응답을 보내는 방식입니다. 특징 모든 노드의 데이터가 항상 일관성 을 유지합니다. 하나의 노드라도 업데이트 실패 시 전체 트랜잭션이 롤백 됩니다. 장점 데이터 손실이 없습니다 . 장애 발생 시에도 데이터 일관성 이 보장됩니다. 항상 일관성을 유지 해야 하는 금융, 통신 등 무결성이 최우선인 환경 에서 이상적인 선택입니다. 단점 노드 수가 많아질수록 응답 시간이 증가 합니다. 충돌 및 교착 상태(Deadlock) 발생 가능성이 커집니다. 세미 동기 복제 (Semi-Synchronous Replication) 세미 동기 복제는 최소 한 개 이상의 노드에 복제가 완료 되었음을 확인한 후 클라이언트에 커밋 응답을 보내는 절충형 방식입니다. 특징 일부 데이터 일관성을 확보하면서 처리 속도를 개선합니다. 장점 일부 무결성 확보가 가능합니다. 동기 복제보다 빠르고, 비...

  ACID 모델 은 데이터베이스 트랜잭션의 무결성과 일관성을 보장하기 위한 핵심 속성 집합입니다. 특히 데이터 복제나 동시 처리 환경에서 이 모델을 준수하면 데이터가 항상 정확하고 일관되며 장애 상황에서도 복구가 가능합니다. ACID는 다음 네 가지 속성의 약자입니다: Atomicity (원자성) Consistency (일관성) Isolation (격리성) Durability (내구성) 각 속성의 의미는 다음과 같습니다. 원자성 (Atomicity) 원자성은 트랜잭션이 모두 성공하거나, 전혀 반영되지 않아야 함을 의미합니다. 트랜잭션 내부의 작업이 일부만 처리되고 중단되는 일이 없어야 하며, 중간에 문제가 발생하면 전체 작업을 되돌려야 합니다. 즉, 시스템은 트랜잭션을 하나의 단위 로 처리해야 합니다. 일관성 (Consistency) 일관성은 트랜잭션이 수행되기 전과 후에 데이터베이스의 상태가 항상 정해진 규칙을 만족해야 함을 의미합니다. 예를 들어, 계좌 잔액이 음수가 되면 안 되는 제약 조건이 있다면, 어떤 트랜잭션도 이 조건을 위반해서는 안 됩니다. 트랜잭션 실행 후 데이터는 반드시 유효한 상태 여야 합니다. 격리성 (Isolation) 격리성은 동시에 실행되는 여러 트랜잭션이 서로 영향을 주지 않아야 함을 의미합니다. 하나의 트랜잭션이 실행 중일 때 다른 트랜잭션이 그 작업 결과를 중간에 볼 수 없어야 하며, 결과적으로는 트랜잭션들이 순차적으로 실행된 것처럼 보여야 합니다. 내구성 (Durability) 내구성은 트랜잭션이 성공적으로 커밋되면 그 결과가 영구적으로 저장 되어야 함을 의미합니다. 시스템 장애가 발생하더라도 데이터는 손실되지 않고 유지되어야 하며, 보통 디스크와 같은 안정적인 저장소에 기록됨으로써 이 속성이 보장됩니다. 마무리 ACID 모델은 신뢰할 수 있는 데이터베이스 시스템을 구성하기 위한 기본이자 필수 원칙 입니다. 이 네 가지 속성이 제대로 작동하지 않으면, 데이터는 쉽게 ...

  대규모 시스템에서 데이터베이스의 부하 분산과 고가용성 확보는 중요한 과제입니다. 이를 위한 대표적인 방법이 데이터베이스 복제이며, 흔히 사용되는 구조로는 Master-Slave 복제와 Multi-Master 복제가 있습니다. 이 글에서는 두 방식의 구조와 동작 원리를 비교하고, 개발자가 고려해야 할 사항들을 정리해 봅니다. Master-Slave Replication 구조 기본 개념 Master-Slave 구조에서는 하나의 Master 서버 와 여러 개의 Slave 서버 로 구성됩니다. 쓰기 연산(Insert, Update, Delete 등 DML)은 반드시 Master 서버로 전달되며, 읽기 연산(SELECT 등)은 Slave 서버로 분산하여 처리할 수 있습니다. DML: Data Manipulation Language의 약자로, 데이터를 조작하는 SQL 구문 (INSERT, UPDATE, DELETE 등) 동작 방식 클라이언트는 Master 서버에 DML 쿼리를 전송합니다. Master 서버는 해당 변경 사항을 binary log 파일 에 기록합니다. 각 Slave 서버는 이 binary log 파일을 복사 및 재생(Replay) 하여 동일한 데이터를 반영합니다. SELECT와 같은 읽기 쿼리는 Slave 서버로 분산 처리 되어 읽기 부하를 줄입니다. [Client] ---(DML)---> [Master DB] --- Binary Log ---> [Slave DB 1] \---> [Slave DB 2] 장단점 장점 단점 읽기 성능 확장 가능         Master 서버에 쓰기 병목 발생 구현이 단순하고 안정적         데이터 반영 지연(latency) 가능성 특정 사용 패턴(읽기 위주)에 적합       ...