Galera Cluster를 통한 MariaDB 클러스터링 구성 (2) Galera Cluster 동작 원리

지난 글에서 MariaDB 클러스터링을 위한 두가지 방법에 대해 알아보았다.

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

 

Replication을 통해 Master-Slave 방식으로 구성하는 방법과 Galera Cluster를 통해 멀티 마스터 방식으로 클러스터를 구성하는 방식에 대해 개념 정도를 알아보았는데, 이번 글에서는 그래서 실제로 Galera Cluster 어떤 동작 방식으로 복제를 진행하는지 작성해보고자 한다. 

 

Galera Cluster 동작 원리 이해하기

https://galeracluster.com/library/galera-documentation.pdf

 

 

※ 해당 그림은 Galera Cluster 동작 순서를 간략하게 나타낸 그림으로 실제와 다를 수 있습니다. 잘못된 부분이 있다면 댓글로 남겨주시면 감사하겠습니다. 

 

✅ Galera Cluster의 데이터 변경(쓰기 트랜잭션) 과정

1. 클라이언트가 Primary 노드에 트랜잭션을 요청한다. 

클라이언트가 Primary 노드(#1)에 쓰기 트랜잭션(ex. INSERT, UPDATE, DELETE)을 요청한다. 

Primary 노드는 이 트랜잭션을 로컬(MariaDB 엔진)에서 실행하고, 변경된 데이터를 Write-Set으로 변환하여 GCache에 저장한다. 이 때 Commit은 하지 않는다. 

 

2. Write Set을 gcomm을 통해 모든 노드로 전파한다. (Broadcast)

Galera의 gcomm 레이어가 Write Set을 모든 노드에 브로드캐스트 한다. 

이 과정에서 모든 노드는 동일한 Global Order를 적용 받아 같은 순서로 Write Set을 수신한다. 

Write Set을 수신한 노드는 Certification Queue에 넣고 트랜잭션 충돌 여부를 검사한다. 

 

Write-Set은 아래와 같은 JSON 형태로 되어있다. Primary 노드로부터 브로드캐스트를 받았을 때는 아직 인증 과정이 이루어지지 않아 certification_Info는 비어있는 상태이다. 

{
  "GTID": "abc123-456-def789:10", //트랜잭션 식별을 위한 고유 ID
  "Seq_Num": 15, //트랜잭션 실행 순서(Global Order)
  "Table": "users", //테이블명
  "Primary_Key": {"id": 1}, 
  "Row_Data": { //변경된 행의 데이터
    "old": {"balance": 500},
    "new": {"balance": 400}
  },
  "Transaction_Type": "UPDATE", 
  "Binlog_Events": [ //Binlog 기반 변경사항
    {
      "Type": "UPDATE",
      "Table": "users",
      "Set": {"balance": 400},
      "Where": {"id": 1}
    }
  ],
  "Certification_Info": { //충돌검사결과
  }
}

 

 

3. 각 노드(#1, #2, #3)에서 Certification을 수행한다. 

각 노드는 자신이 받은 Write Set을 Certification을 진행한다. 

Cetification 과정에서는 아래의 내용을 확인한다. 

• 충돌 검사 (다른 트랜잭션과 충돌하는지 확인)
• Write Set이 현재 트랜잭션 순서와 일관성이 있는지 검증

결과는 인증에 통과하면 OK, 충돌 발생시 WF_ABORT로 정의한다. 

Galera는 이벤트 기반 메시징을 통해 이 Certification 결과를 모든 노드에 공유하며, 한 노드라도 WF_ABORT이면 트랜잭션을 폐기한다.

 

충돌 검사 결과를 포함한 Write Set 데이터는 아래와 같다. 

{
  "GTID": "abc123-456-def789:10",
  "Seq_Num": 15,
  "Table": "users",
  "Primary_Key": {"id": 1},
  "Row_Data": {
    "old": {"balance": 500},
    "new": {"balance": 400}
  },
  "Transaction_Type": "UPDATE",
  "Binlog_Events": [
    {
      "Type": "UPDATE",
      "Table": "users",
      "Set": {"balance": 400},
      "Where": {"id": 1}
    }
  ],
  "Certification_Info": {
    "Status": "OK",
    "Conflict_Check": false
  }
}

 

 

4. 각 노드(#2, #3)는 Certification에 통과한 Write Set을 Apply Queue에 추가한다. 

 

5. Apply Queue에 저장된 Write Set을 트랜잭션에 적용한다. 

모든 노드는 자신의 Apply Queue에 들어온 Write Set을 실제 데이터베이스에 반영한다. 

 

8. Commit 완료 후 클라이언트에게 응답을 반환한다. 

 

⭐ 각 노드에서 Certification 중 충돌을 감지하면?

Certification 중 충돌을 감지하면 어떻게 처리될까?

충돌이 발생한 노드는 WF_ABORT는 Write-Set Certification_Info에 추가한다. 

 

{
  "GTID": "abc123-456-def789:10",
  "Seq_Num": 15,
  "Table": "users",
  "Primary_Key": {"id": 1},
  "Row_Data": {
    "old": {"balance": 500},
    "new": {"balance": 400}
  },
  "Transaction_Type": "UPDATE",
  "Binlog_Events": [
    {
      "Type": "UPDATE",
      "Table": "users",
      "Set": {"balance": 400},
      "Where": {"id": 1}
    }
  ],
  "Certification_Info": {
    "Status": "WF_ABORT", 
    "Conflict_Check": true
  }
}

 

Galera는 충돌이 발생하면 모든 노드가 이를 반영할 수 있도록 설계되었다. Galera의 gcomm 레이어를 통해 트랜잭션 실패 정보가 공유되고 모든 노드는 해당 Write Set을 Apply Queue에 넣지 않고 폐기한다. 

 

이 때 Primary 노드는 클라이언트에게 트랜잭션 실패 응답을 하고 클라이언트는 이 정보를 바탕으로 재시도하거나 롤백 처리를 수행할 수 있다. 

---

 

지금까지 Galera Cluster가 데이터 변경이 일어나면 어떻게 Replication을 진행하는지 알아보았다. 다음 시간부터는 실제 Galera Cluster를 어떻게 적용하는지 알아보고자 한다.