MySQL/MariaDB 환경에서 다중 마스터 복제를 지원하는 Galera Cluster 알아보기

MySQL/MariaDB 환경에서 다중 마스터 복제를 지원하는 Galera Cluster 알아보기

 

l  Version : MySQL, MariaDB, Galera Cluster

 

Galera Cluster (이하 “갈레라 클러스터”)는 다중 마스터 동기 복제를 제공하는 솔루션으로 DB 간의 직접적인 데이터 공유가 없는 형태의 오픈소스 고가용성 솔루션이다.  현재 갈레라 클러스터는 MySQL Percona Xtradb 클러스터와 MariaDB 두 가지 버전을 지원한다. 특히 MariaDB에서는 Galera Cluster를 공식적으로 지원한다. 이번 포스트에서는 갈레라 클러스터의 개념과 장단점에 대해서 알아본다.

 

갈레라 클러스터는 동기 방식의 복제구조를 사용하는 멀티마스터 RDB 클러스터로 제공된다. 갈레라 클러스터는 인증 기반 복제를 제공하며 노드간 통신을 위해 wsrep API를 사용한다. 데이터 복제는 논리적으로는 완전 동기이지만 실제 write와 tablespace에 commit하는 과정은 별개이고 각 노드간에는 비동기로 동작한다. 그래서 갈레라 클러스터에서는 이러한 방식을 virtually synchronous replication이라 부른다.

 

 

[Galera Cluster 특징]

l  다중 쓰기 : Active-Active 방식의 다중 Master 구조이기 때문에 모든 노드에서 Read/Write 가능하다.

l  동기 복제 : 슬레이브 지연이 없고 노드 충돌시 데이터 손실이 없다.

l  일관적 데이터 유지 : 모든 노드는 항상 같은 데이터 상태를 유지 한다.

l  장애조치 : 노드 장애가 발생하였을 때 빠르게 모니터링 되어 전환되므로 서비스 중단이 최소화 된다. 멀티 포인트 쓰기를 지원하므로 전환이 쉽다. 특정 노드 장애가 전체 서비스에 영향을 미치지 않는다. 이론적으로 모든 노드가 쓰기 가능하기 때문에 모든 노드가 다운되기 전까지는 서비스 유지가 가능하다.

l  자동 노드 복제 : 노드를 추가하거나 관리를 위해 종료 또는 노드에서 제거 해야 할 경우 증분 데이터 또는 기본 데이터를 수동으로 백업할 필요가 없다. 갈레라 클러스터는 노드를 추가할 경우 자동으로 온라인 노드의 데이터를 가져오고 일관성을 유지한다.

 

[Galera Cluster 단점]

l   동기 복제 특성상 클러스터의 성능은 가장 성능이 낮은 노드에 의해 결정된다. 그래서 최대한 동일한 성능의 서버로 구성하는 것이 좋다.

l   동기 복제이기 때문에 쓰기가 많이 발생할 경우 다른 아키텍처(비동기 복제 등)보다 상대적으로 성능이 저하되며 스케일 아웃에 한계가 있다.

l   신규 노드가 조인되거나 대규모 노드 조인시 지연이 발생하면 데이터 전체를 복사(SST, 상태 스냅샷 전동) 하는 문제가 발생한다. 이때 데이터를 제공하는 서버를 Donor라고 하는데 Donor 노드는 복제 데이터를 전송하는 동안 읽기 및 쓰기 서비스가 중단된다.

l   인증 기반 복제를 사용하기 때문에 인증이 실패할 경우 데드락이 발생할 가능성이 있다.

 

[Galera Cluster 제약사항]

l   MyISAM 일부와 InnoDB 스토리지 엔진 테이블만 지원한다.

l   노드 간의 쿼리 실행 순서를 피하기 위해 모든 테이블에서 기본키를 필수적으로 사용한다.

n  기본 키가 없는 테이블에서는 DELETE 작업이 지원되지 않는다.

n  기본 키가 없는 테이블의 행은 다른 노드에서 다른 순서로 나타날 수 있다.

l   Query Cache를 비활성화한다

l   XA 트랜잭션 (전역 트랜잭션)은 지원하지 않는다.

l   일반 쿼리 로그와 슬로우 쿼리 로그는 테이블로 보낼 수 없다. 이러한 로그를 활성화하는 경우 log_output=FILE을 설정하여 로그를 파일로 전달해야 한다.

 

 

Galera Cluster는 wsrep(Write-Set Replication) API를 통해 각 노드와 데이터를 동기화 한다. 여기서 wsrep API는 DBMS간 복제를 위한 인터페이스이며 실제 동기화 구현은 Galera Replication Plugin에서 이루어 진다.

 

 

각 노드에서 쓰기나 업데이트가 발생할 경우 노드간에 데이터를 복제하고 업데이트 내용을 GCache 영역에 저장한다. GCache는 복제된 트랜잭션을 위한 임시 저장소 역할을 한다.

 

 

Galera Cluster는 인증기반 복제를 사용한다. 인증 기반 복제의 주요 컨셉은 트랜잭션이 충돌이 없다고 가정하고 커밋 지점에 도달할 때까지 관례적으로 실행된다는 것이다. 이를 낙관적 실행이라고 한다.

Galera Cluster에서 인증 기반 복제 구현은 트랜잭션의 전역 순서에 따라 다르다. Galera Cluster는 복제 중에 각 트랜잭션에 전역 시퀀스 번호 또는 seqno를 할당한다. 트랜잭션이 커밋 지점에 도달하면 노드는 마지막으로 성공한 트랜잭션의 시퀀스 번호와 시퀀스 번호를 확인한다. 둘 사이의 간격을 통해 모든 트랜잭션은 해당 트랜잭션과 기본 키 충돌이 있는지 확인한다. 충돌이 감지되면 인증 테스트에 실패한다.

 위 그림에서 데이터가 변경되고 커밋되기 까지의 순서를 나타내면 아래와 같다.

1.          클라이언트가 데이터를 수정하고 커밋 요청을 서버에 요청한다.

2.          서버는 커밋 요청을 받으면 실제 커밋을 실행하기 전에 트랜잭션 및 변경된 행의 기본 키에 의해 데이터베이스에 대한 모든 변경 사항이 쓰기 세트로 수집된다.

3.          데이터베이스는 이 쓰기 세트를 다른 모든 노드로 전송한다.

4.          쓰기 세트는 기본 키를 사용하여 결정적 인증 테스트를 거친다. 이 작업은 쓰기 세트를 생성한 노드를 포함하여 클러스터의 각 노드에서 수행된다.

5.          각 노드가 쓰기 세트를 적용할 수 있는지 여부를 결정한다.

6.          인증 테스트에 실패하면 노드는 쓰기 세트를 삭제하고 클러스터는 원래 트랜잭션을 롤백한다. 그러나 테스트가 성공하면 트랜잭션이 커밋되고 쓰기 세트가 클러스터의 나머지 부분에 적용된다.

 

 

Galera Cluster Replication의 Write 정책은 First Committer Win이다. 트랜잭션이 커밋되는 시점에 다른 노드에 유효한 트랜잭션인지 여부를 체크하는 방식으로 동작한다. 클러스터 내에서 트랜잭션은 모든 서버에 동시에 반영되거나 전부 반영되지 않는 경우 둘 중 하나로 동작한다. 이러한 이유로 Write 트랜잭션은 하나의 서버로 사용하는 것을 권장한다.

트랜잭션을 시작하는 시점(BEGIN)에는 자신의 노드에서는 Pessimistic Locking으로 동작하나, 노드 사이에서는 Optimistic Locking Model로 동작한다. 먼저 트랜잭션을 자신의 노드에 수행을 하고, 커밋을 한 시점에 다른 노드로부터 해당 트랜잭션에 대한 유효성을 확인한다. 일반적으로 InnoDB와 같이 트랜잭션을 지원하는 시스템인 경우 SQL이 시작되는 시점에서 Lock을 확인할 수 있으나, 갈레라 클러스터에서는 커밋되는 시점에 노드 간 트랜잭션 유효성 체크한다.

 

 

트랜잭션 커밋 또는 롤백 결정은 네트워크를 통한 다른 노드와 통신에서 결정된다. 결정 요소에는 아래 항목들의 상태가 포함된다.

l   네트워크 왕복 시간

l   타 노드에서 유효성 체크 시간

l   각 노드에서 데이터 반영 시간

 

Galera Cluster에 필요한 최소 노드 수는 2개이다. 그러나 최소 3개의 노드가 권장된다. 최대 노드 수 제한은 없다. 그러나 10개 이상의 노드가 있는 단일 클러스터는 네트워크 또는 인터넷에서 너무 많은 노드를 동기화하는 데 지연이 발생할 수 있다. 최대 노드 수 구성은 네트워크 구성에 따라 달라지므로 각자의 환경에 맞게 구성하도록 한다.

 

Galera Cluster는 트랜잭션 크기를 명시적으로 제한하지 않지만 쓰기 집합은 단일 메모리 상주 버퍼로 처리되므로 결과적으로 매우 큰 트랜잭션(예: LOAD DATA)은 노드 성능에 부정적인 영향을 미칠 수 있다. 이를 방지하기 위해 wsrep_max_ws_rows 및 wsrep_max_ws_size 시스템 변수는 기본적으로 트랜잭션 행을 128K로, 트랜잭션 크기를 2Gb로 제한한다. 필요한 경우 사용자는 이러한 제한을 늘릴 수 있다. (향후 버전에서는 트랜잭션 조각화에 대한 지원을 추가할 예정이라고 한다.)

 

 

MySQL 및 MariaDB에서 고가용성을 위한 솔루션으로 Galera Cluster에 대해서 살펴보았다. 다양한 솔루션이 있지만 Galera Cluster의 특징은 모든 노드가 마스터 역할로 클러스터에 참여하는 구조로 운영되며, 각 데이터베이스 사이의 연결이 아닌 외부 wsrep API를 통한 데이터 복제가 이루어진다는 점에서 흥미로웠다. 이후 클러스터 구성 방법과 장애조치시 마스터 선정, 옵션에 대한 설정 과정을 다른 포스트에서 다뤄볼 예정이다.

 

[참고자료]

l   https://galeracluster.com/library/documentation/

l   http://galeracluster.com/documentation-webpages/galera-documentation.pdf

l   http://galeracluster.com/documentation-webpages/index.html

l   https://www.percona.com/doc/percona-xtradb-cluster/LATEST/index.html

l   https://mariadb.com/kb/en/library/getting-started-with-mariadb-galera-cluster/

l   https://severalnines.com/resources/whitepapers/galera-cluster-mysql-tutorial/

l   https://www.slideshare.net/marcotusa/galera-explained-3

l   MariaDB Galera Cluster - Known Limitations : https://mariadb.com/kb/en/mariadb-galera-cluster-known-limitations/

l   https://galeracluster.com/library/faq.html

l   https://www.slideshare.net/AbdulManaf19/mariadb-galera-cluster-63088921

 

 

 

2023-08-07 / Sungwook Kang / http://sungwookkang.com

 

MySQL, MariaDB, Galera Cluster, 마리아디비, 마이에스큐엘, 갈레라 클러스터, MariaDB 복제, MariaDB Cluster, MySQL Cluster, MariaDB Replication