Galera Cluster를 통한 MariaDB 이중화 구성 (1) MariaDB 이중화 종류(Replication, Galera Cluster)

DB 혹은 스프링 부트 서버와 같은 시스템을 구성할 때, 단 하나의 서버보다는 이중화 혹은 그 이상으로 하여 아키텍처를 설계하는 경우가 많다. 이중화의 목적은 고가용성인데, 재해 발생이나 예상치 못한 장애 상황에서도 시스템이 멈추지 않고 정상적으로 운영되도록 하고자 함이다. 

 

오늘은 DB 중에서도 관계형 데이터베이스의 한 종류인 MariaDB를 이중화하는 방법에 대해 알아보고자 한다. 

필자는 MariaDB의 여러 이중화 방법 중에서 Galera Cluster를 사용하여 이중화를 시도했고, 그 과정과 관련된 이론을 정리해 보았다. 

---

⭐MariaDB를 이중화하는 여러가지 방법들

본론에 들어가기에 앞서 MariaDB를 이중화하는 여러 방법에 대해 먼저 알아보자. Galera Cluster를 통한 방법도 있지만, MariaDB 자체에서 지원하는 방법을 통해서도 이중화가 가능하다. 

 

---

1. MariaDB Replication

Master-Slave Replication (비동기 복제, 표준 방식)

MariaDB Replication은 하나의 데이터베이스 서버(Primary, Master)의 데이터를 다른 서버(Replica, Slave)로 복제하여 데이터 무결성을 유지하고, 고가용성과 부하분산을 지원하는 기술이다.  

 

바이너리 로그(Binary Log)를 기반으로 복제가 이루어지는 방식이나 쿼리 혹은 Row 기반의 복제 방식도 지원한다. 

바이너리 로그를 기반으로 복제가 이루어진다는 것은 어떤 의미일까? 동작 방식은 아래와 같다. 

 

1) Master가 Insert, update, delete와 같은 데이터 변경 작업을 수행하면, 이를 Binary Log에 기록한다. 실제 MariaDB에서는 binlog 파일을 통해 변경 사항을 로그로 관리한다. 

2) Slave는 Master의 Binary Log를 I/O Thread를 통해 가져와 Relay Log에 저장한다. 

3) Slave의 SQL Thread가 Relay Log를 실행하여 Master의 변경사항을 반영한다. 

4) Slave의 데이터가 Master와 동기화된다. 

 

Replication에서 Slave 서버는 Master 서버의 변경 사항을 복제하기 위해 두 개의 주요 쓰레드를 사용한다. 

I/O Thread
- Master 서버에 접속해서 바이너리 로그(Binary Log)를 읽어온다. 
- 가져온 로그를 Relay Log(중간 로그 파일)에 저장한다.

SQL Thread
- Relay Log에 기록된 쿼리를 실행하여 실제 데이터에 변경 적용한다. 

 

Slave는 Master에서 변경 사항이 발생함을 감지하기 위해 Polling 방식을 사용한다. 즉, Slave의 I/O Thread는 Master의 Binary Log를 "Polling" 방식으로 확인하고 가져오는 역할을 한다. 

 

Master 서버와 Slave 서버를 설정 후 START SLAVE; 를 통해 Replication을 시작하면, Slave가 I/O Thread가 시작되고, 쓰레드가 Master에 주기적으로 새로운 Binary Log가 있는지 요청하는 것이다. 

 

 

Master-Slave 방식의 복제 방식 외에 Master-Master, Multi-Source 등의 방식 또한 존재한다. 

 

---

2.  MariaDB Galera Cluster

MariaDB Galera Cluster는 동기식 Multi-Master 복제(Synchronous Multi-Master Replication)를 지원하는 클러스터 솔루션으로, 모든 노드가 동등한 Master 역할을 하며 실시간으로 데이터를 공유하는 구조이다. 

 

Galera Cluster를 이해하기 위해서는 몇 가지 개념에 대해 이해할 필요성이 있다. 해당 개념들을 이해함으로써 어떻게 Galera Cluster가 동기식 멀티 마스터를 지원하는지에 대해 대략적으로 알아보자.

 

🔎 인증 기반 복제 (Certification-Based Replication)

Galera Cluster는 그룹 통신과 트랜잭션 정렬 기법을 사용하여 동기 복제를 구현한다. 

트랜잭션은 개별 노드에서 실행되며, 커밋 시점에 전체 클러스터와 동기화되어 일관성을 유지한다. 

이에 대한 내용은 위의 두 문장만으로 이해하기 힘들 것이다. 관련된 내용은 아래의 Galera Cluster 복제 과정과 통신 방식 부분을 읽으면 어느 정도 이해가 될 것이다. 

 

🔎 Replication API

Galera Cluster는 wresp API를 사용하여 Write-set 복제를 수행한다. 

1. 한 노드에서 데이터의 상태가 변경된다. 
2. wsrep API가 변경 사항을 쓰기 집합(write-set)으로 변환한다. 
3. Galera 복제 플러그인(Galera Replication Plugin)이 인증 및 복제를 수행한다. 
4. 모든 노드가 동일한 순서로 트랜잭션을 적용한다. 

 

🔎 격리 수준(Isolation Levels)

Galera Cluster는 아래의 격리 수준을 지원한다. 

• READ-UNCOMMITED: 트랜잭션이 커밋되지 않은 데이터도 읽을 수 있음
• READ-COMMITED: 커밋된 데이터만 읽을 수 있지만, 반복 불가능한 읽기가 발생할 수 있음
• REPEATABLE-READ: 첫 번째 SELECT 실행 시점의 스냅샷을 유지하여 반복 가능성을 보장함
• SERIALIZABLE: 트랜잭션 간 완전한 격리를 보장하지만 성능이 저하될 수 있음

🔎 상태 전송 (State Transfer)

클러스터 내 노드 간 동기화를 위한 두가지 방법이 있다. 

• State Snapshot Transfer (SST)
  • 노드 전체 데이터의 스냅샷을 전송하여 동기화하는 방식
  • mysqldump, rsync, xtrabackup 등을 사용
  • 새 노드가 클러스터에 추가될 때 사용
• Incremental State Transfer (IST)
  • 기존 노드의 누락된 트랜잭션만 전송하여 동기화
  • gcache를 이용해 필요한 데이터만 전달
  • 네트워크 트래픽을 줄이고 속도를 향상시킴

🔎 흐름 제어 (Flow Control)

Galera Cluster는 피드백 기반의 흐름 제어를 사용하여 노드 간 동기화를 조정한다. 

노드가 너무 느리게 트랜잭션을 처리하면 복제를 일시 중지하고 따라잡을 수 있도록 한다. 

gcs.fc_limit 등의 파라미터를 통해 트랜잭션 처리 속도를 조정할 수 있다. 

 

🔎 노드 장애 및 복구 (Node Failure & Recovery)

노드가 클러스터와의 연결을 잃으면 장애 상태로 간주되는데 장애 발생 시 쿼럼(quorum) 계산을 통해 클러스터 상태를 유지한다. 노드 복구 시에는 SST 또는 IST를 사용하여 동기화를 진행한다. 

 

🔎 쿼럼(Quorum) 구성 요소

Galera Cluster에서는 클러스터의 가용성을 유지하기 위해 쿼럼 기반의 의사 결정을 수행한다. 

• 쿼럼(Quorum): 클러스터 내에서 과반수 이상(50% + 1)의 노드가 동작하는 경우 클러스터가 유지된다. 
• 무게 기반 쿼럼(Weighted Quorum): 특정 노드에 더 높은 가중치를 부여하여 안정성을 확보한다. 
• 네트워크 분할 발생 시, 클러스터는 Primary Component와 Non-Primary Component로 나뉜다. 

Galera Cluster는 쿼럼(Quorum) 문제와 네트워크 분할(Split-Brain) 방지를 위해 최소 3개의 노드를 사용하고 홀수 개의 노드를 사용할 것을 권장한다.

 

✅ 1. 클러스터 쿼럼 문제

Galera Cluster는 과반수 투표 방식을 사용하여 클러스터의 상태를 유지한다. 

그런데 만약 노드가 2개 뿐이라면, 1개의 노드가 장애가 발생해 다운됐을 경우 남은 한 개의 노드는 단독으로 Primary Component가 될 수 없다. 즉, 한 개의 노드가 죽으면 나머지 노드도 비활성화 상태가 되는 것이다. 

따라서 클러스터를 유지하려면 최소 3개의 노드가 있어야 다수결을 통해 정상적인 Primary Component를 유지할 수 있다. 

 

✅ 2. 네트워크 분할(Split Brain) 방지

네트워크 장애가 발생하여 클러스터가 2개의 그룹으로 나뉠 가능성이 있다. 만약 짝수개의 노드를 사용하게 되면 어느 쪽도 과반수를 확보하지 못해 클러스터가 비활성화 될 수 있다. 예를 들어, 총 4개의 노드로 구성되어 있었는데 네트워크 문제로 2개의 노드끼리만 네트워크 통신이 되어 2:2로 나뉠 수 있다. 2:2인 경우 어느쪽도 과반수 이상이 아니므로 두 개의 그룹이 모두 비활성화 노드가 되어 버린다. 

반면, 총 5개의 노드로 구성이 되었는데 네트워크 장애로 그룹이 2개로 나뉠 경우 하나의 그룹은 3개의 노드로 구성되고, 다른 노드는 2개의 노드로 구성된다. 그럴 경우 3개의 노드가 속한 그룹이 과반수 이상이기 때문에 3개의 노드 그룹은 비활성화 되지 않고 계속 운영이 된다. 

 

 

🔎 스트리밍 복제 (Streaming Replication)

일반적으로 트랜잭션은 커밋될 때만 복제 및 인증된다. 그러나 대용량의 트랜잭션이 발생할 경우 스트리밍 복제를 사용하여 트랜잭션을 여러 조각으로 나눠 복제할 수 있다. 

 

---

 

기존 Master-Slave 방식과의 차이점

비교 항목	Master-Slave 방식	Galera Cluster
복제 방식	비동기(Asynchronous)	동기(Synchronous)
쓰기 가능 노드	1개(Master)	모든 노드
Failover	수동으로 Slave를 승격해야 함	자동 Failover 가능
데이터 정합성	Replication Lag 발생 가능	모든 노드가 같은 데이터를 가짐
성능	쓰기는 단일 Master가 처리	여러 Master에서 분산 가능

 

💖 Galera Cluster는 모든 노드가 동일한 데이터를 유지하므로, 읽기/쓰기를 부하 분산할 수 있고, Master 장애 시에도 자동 복구가 가능하다. 

 

Galera Cluster 복제 과정

1. 클라이언트(스프링부트 서버)가 INSERT, UPDATE, DELETE와 같은 쓰기 작업을 요청한다.  

 

2. 요청 받은 노드의 Galera Cluster에서 트랜잭션이 처리되고 Write Set으로 변환된다. 

아래와 같은 UPDATE 요청이 들어오면 트랜잭션이 처리되고

UPDATE users SET email = 'bob.newemail@mail.com' WHERE id = 2;

 

해당 쿼리의 결과로 Write Set이 생성된다. 

{
    "transaction_id": 12345,
    "changes": [
        {
            "table": "users",
            "operation": "UPDATE",
            "primary_key": 2,
            "old_values": {
                "email": "bob@mail.com"
            },
            "new_values": {
                "email": "bob.newemail@mail.com"
            }
        }
    ]
}

 

3. Certification 단계에서 트랜잭션 충돌을 검증한 후, Write set이 Galera Cluster를 구성하는 또 다른 서버로 전파된다.  만약 이 단계에서 충돌이 발생하면 트랜잭션이 롤백된다. 

 

4. Galera Cluster를 구성하는 또 다른 노드가 Write Set을 받아서 해당 트랜잭션을 실행한다. 

 

5. 모든 노드에서 해당 트랜잭션을 처리하고 데이터가 동기화되면, MariaDB에 커밋이 이루어지고, 커밋 결과를 클라이언트가 응답 받는다. 

 

6. 장애가 발생하면 Galera Cluster는 다른 노드에서 트랜잭션을 처리하고 이를 동기화하여 클라이언트에게 정상 응답을 보낸다. 

 

Galera Cluster 노드 간 통신 방식

Galera Cluster에서 클러스터를 구성하는 노드들은 서로 데이터 동기화 및 트랜잭션 검증을 위해 특별한 방식으로 통신한다. 

 

1. 트랜잭션 실행

노드 A에서 INSERT 쿼리가 실행되면, 이 쿼리는 Write Set으로 변환되어 Galera Cache(GCache)에 저장된다. 

 

- GCache(Galera Cache)

GCache는 Galera의 쓰기 캐시로, 노드 간에 데이터를 동기화할 때 사용된다. 각 노드는 자신의 변경된 데이터를 GCache에 저장하고, 이를 다른 노드들과 공유하여 동기화한다. GCache는 트랜잭션을 검증하고, Write Set를 저장한다. 

 

2. 트랜잭션 전파(I/O Thread)

노드 A에서 발생한 Write Set은 Replication Bus를 통해 다른 노드(예: 노드 B, 노드 C)로 전파된다. 

 

- Replication Bus

Galera Cluster의 노드들은 Replication Bus를 통해 서로 통신한다. Replication Bus는 내부 통신 채널로, 트랜잭션을 다른 노드에 전달하고, 트랜잭션을 인증하는데 사용된다. 

Replication Bus는 통신 프로토콜로 TCP/IP 기반의 Gcomm(Galera Communication Protocol)을 사용한다. 

Gcomm은 내부 통신을 위해 포트 번호(4567/UDP, 4568/TCP)

** 참고: Gcomm은 UDP로 노드 검색과 연결을 처리하지만, 데이터 전파는 TCP/IP로 이루어진다. 

 

- WSREP(Write Set Replication Protocol) 

WSREP는 Write Set을 전파하고 동기화하는 데 사용되는 프로토콜로, Write Set 전파 시 필요한 양식과 규칙을 정의한다. 

 

3. 트랜잭션 인증(SQL Thread)

노드 B와 C는 해당 Write Set을 인증하고, 충돌이 없으면 이를 처리하여 동기화한다. 

 

4. 데이터 동기화 (SQL Thread)

트랜잭션이 인증되면, 각 노드는 데이터를 동기화하여 동일한 데이터 상태를 유지한다. 

SQL Thread는 각 노드에서 수신된 Write Set을 적용하고, 이를 데이터베이스에 반영한다. 

 

5. 트랜잭션 커밋 (SQL Thread)

모든 노드가 트랜잭션을 처리하고, 커밋이 이루어지면 클러스터는 동기화된 상태로 유지된다.

 

garbd(Galera Arbitrator)

Galera Cluster에 대해 설명할 때, Galera Cluster는 최소 3개의 노드로 구성할 것을 권장했다고 언급했다. 그러나 만약 서버의 자원이 부족해서 데이터를 저장할 공간이 부족해 2개의 DB만 설치가 가능하다고 하면 어떻게 할 것인가? 

이럴 때 사용하는 것이 garbd이다. 

 

garbd는 Galera Cluster의 보조 구성 요소로 복제에는 참여하지 않지만 클러스터의 투표에는 참여해 실제 노드는 2개뿐이지만 한 개가 죽더라도 garbd가 투표에 참여해 Quorum을 유지해 클러스터가 정상적으로 동작하게 할 수 있다. 

 

Garbd는 클러스터의 투표 결정에 사용되므로, 실제 노드가 다운되도 상관이 없는 별도의 서버에 설치하는 것이 좋다. 만약 Mariadb가 설치된 노드에 설치하게 되면 해당 서버가 죽는 경우 Garbd도 함께 죽기 때문에 서비스가 중단될 가능성이 있기 때문이다. 따라서 garbd는 별도의 서보 또는 가벼운 VM에 설치하는 것이 일반적이다. 

 

---

참고자료

1. https://mariadb.com/kb/en/replication-overview/

Replication Overview