MariaDB, 갈레라 클러스터 구성하기

개요

• Galera Cluster는 2009년 발표된 MariaDB를 위한 동기식 멀티 마스터 클러스터 기술이다. 오랜 기간의 안정성 입증과 버전업을 통해 2019년 성능이 월등히 향상된 Galera 4.0이 발표되어 MariaDB 10.4 배포본에 포함되면서 현재 상당한 주목을 받고 있다.
• 갈레라 클러스터는 종전의 전통적인 마스터-슬레이브 방식 대비 시간 지연 없이 모든 노드에 대한 CRUD가 가능하며, 특정 노드에 장애가 발생하여 클러스터에서 이탈해도 남은 노드가 마스터 역할을 해주어 궁극적으로 무중단 데이터베이스 운영을 가능하게 해준다. (Oracle 진영에는 RAC라는 선구적인 멀티 마스터 방식을 제공하는데 구축 비용이 상당하다. 반면에 갈레라 클러스터는 완전히 무료이다.) 이번 글에서는 3개 이상의 데이터베이스 노드로 갈레라 클러스터를 구성하는 방법을 설명하고자 한다.

갈레라 클러스터 설정

• 갈레라 클러스터를 위한 최초 환경 설정은 아래와 같다. 갈레라 클러스터를 구성할 모든 노드를 종료한 상태에서 아래 옵션 설정을 추가한다. (각 옵션에 대한 자세한 설명은 아래에서 차례로 다룬다.)
• MariaDB 10.4 아래 버전은 아래와 같이 설정한다.

# 모든 노드에 실행 중인 MariaDB를 완전히 종료
$ sudo yum install psmisc
$ sudo killall -KILL mysql mysqld_safe mysqld mysql-systemd

# Galera 라이브러리 위치 확인
$ sudo find / -name libgalera_smm.so
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so

# 갈레라 클러스터 환경 설정 추가
$ sudo nano /etc/my.cnf
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so
wsrep_cluster_name=some-cluster
wsrep_cluster_address=gcomm://192.168.70.61,192.168.70.62,192.168.70.63
wsrep_node_name=node1
wsrep_node_address=192.168.70.61
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=sstuser:passw0rd
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2

• MariaDB 10.4 버전부터는 아래와 같이 설정한다.

$ sudo nano /etc/my.cnf.d/server.cnf
[galera]
wsrep_on=ON
wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so
wsrep_cluster_address="gcomm://192.168.56.2,192.168.56.3,192.168.56.4"
wsrep_cluster_name="some-cluster"
wsrep_sst_method=mariabackup
wsrep_sst_auth='sstuser:pa55'
wsrep_node_name="node1"
wsrep_node_address="192.168.56.2"
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

wsrep_provider

• wsrep_provider 옵션은 갈레라 클러스터 라이브러리의 경로를 의미한다. Red Hat/CentOS 운영체제라면 아래와 같이 작성한다.

$ sudo nano /etc/my.cnf
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so

wsrep_cluster_name

• wsrep_cluster_name 옵션은 갈레라 클러스터의 이름을 의미한다. 클러스터 이름이 같은 노드끼리만 데이터 동기화를 진행한다.

$ sudo nano /etc/my.cnf
wsrep_cluster_name=some-cluster

wsrep_cluster_address

• wsrep_cluster_address 옵션은 갈레라 클러스터를 구성하는 전체 노드의 IP 주소 목록을 의미한다.

$ sudo nano /etc/my.cnf
wsrep_cluster_address=gcomm://192.168.70.61,192.168.70.62,192.168.70.63

wsrep_node_name

• wsrep_node_name 옵션은 갈레라 클러스터를 구성하는 특정 노드의 이름을 의미한다. 각 노드는 반드시 서로 다른 이름을 가져야 한다.

$ sudo nano /etc/my.cnf
wsrep_node_name=node1

wsrep_node_address

• wsrep_node_address 옵션은 갈레라 클러스터를 구성하는 특정 노드의 IP 주소를 의미한다. 각 노드는 반드시 정확한 IP 주소를 가져야 한다.

$ sudo nano /etc/my.cnf
wsrep_node_address=192.168.70.61

wsrep_sst_method

• wsrep_sst_method 옵션은 갈레라 클러스터의 동기화 방법을 의미한다. 모든 노드의 환경 설정에 아래 내용을 추가한다.

$ sudo nano /etc/my.cnf
wsrep_sst_method=xtrabackup-v2

• rsync는 가장 원시적인 데이터 동기화 방법으로 권장되지 않는다. 왜냐하면 데이터 동기화가 진행되는 동안 Donor(데이터를 제공하는 노드)에서 읽기 및 쓰기 명령이 불가능하기 때문이다. (이 때 클러스터 노드 수가 2개라면 완전한 클러스터 다운 타임이 발생한다.)
• xtrabackup은 rsync와 달리 데이터가 동기화되는 동안 Donor에서 읽기 및 쓰기 명령이 가능하다. 즉, 운영 서비스에 미치는 영향을 최소화할 수 있어 권장된다. MariaDB v5.5.28 이상 버전에서만 사용이 가능하다. xtrabackup이 정상적으로 작동하기 위해서는 모든 노드에 아래 파일들이 설치되어 있어야 한다.

$ sudo find / -name wsrep_sst_common
/usr/local/mariadb/bin/wsrep_sst_common

$ sudo find / -name innobackupex
/usr/bin/innobackupex

• xtrabackup-v2는 xtrabackup을 개선하여 비동기로 작동하여 Donor의 부하를 개선한 방법이다. 다만, MariaDB v5.5.54 이상 버전에서만 사용이 가능하다. (그 이하 버전은 xtrabackup을 사용해야 한다.)
• mariabackup은 xtrabackup-v2을 더욱 개선한 최신 동기화 방법이다. MariaDB v10.2.10 이상 버전에서만 사용이 가능하다.

wsrep_sst_auth

• /etc/my.cnf의 wsrep_sst_auth 옵션에는 갈레라 클러스터의 동기화 인증 정보를 작성한다.
• 먼저 모든 클러스터 노드를 중단하고 아래와 같이 sstuser 사용자를 생성하고 동기화를 위한 권한을 부여한다. Donor 노드가 최초 1개만 존재하는 상황이라면 새로운 Joiner 노드를 추가하기에 앞서 Donor 노드에 아래 명령어를 실행한다.

> CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 'passw0rd';
> SHOW GRANTS FOR 'sstuser'@'localhost';
> GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost' IDENTIFIED BY PASSWORD 'passw0rd';
> FLUSH PRIVILEGES;

• 모든 노드의 환경 설정에 아래 내용을 추가한다.

$ sudo nano /etc/my.cnf
wsrep_sst_auth=sstuser:passw0rd

최초 노드의 실행

• 갈레라 클러스터를 구성할 최초 노드는 아래와 같이 실행한다. --wsrep-new-cluster 옵션은 이 노드가 최초 노드 임을 명시하여 srep_cluster_address=”gcomm://로 실행되도록 해준다.

$ sudo service mysqld start --wsrep-new-cluster
Starting MySQL......... SUCCESS!

• MariaDB 10.4 버전부터는 아래와 같이 실행한다. 실행 전에 모든 노드가 종료되어 있어야 한다.

# 1번 노드에서 클러스터 시작
$ sudo galera_new_cluster
$ sudo mysql -u root -e "SHOW STATUS LIKE 'wsrep_cluster_size'"
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+

새로운 노드의 추가

• 현재 운영 중인 갈레라 클러스터에 새로운 노드를 추가하는 방법은 아래와 같다.

$ sudo service mysqld start --wsrep_cluster_address="gcomm://192.168.70.61,192.168.70.62,192.168.70.63" --wsrep_cluster_name="some-cluster"
Staring MySQL.......SST install progress, setting sleep higher...

• 새로운 노드를 구성하고 기동시 wsrep_cluster_address 옵션에 이미 운영 중인 갈레라 클러스트 노드를 최소 1개 이상 명시하면, 자동으로 Donor(데이터를 제공하는 노드)로부터 데이터 동기화를 시작한다. 이 때 새롭게 추가할 노드는 Joiner(데이터를 제공 받는 노드)가 된다.
• 동기화가 시작되면, Joiner에 존재하는 데이터와 설정은 모두 Donor의 것으로 덮어쓰기 된다. 트래픽 부하를 최소화하기 위해 동시다발적인 여러 노드의 추가는 삼가해야 한다. 한번에 한 노드씩 추가하는 것이 가장 안전하다.
• 새로운 노드의 서비스가 시작되면 콘솔에 접속하여 아래 파라메터를 확인해야 한다.

$ mysql -u root

> SHOW STATUS LIKE 'wsrep%';
+----------------------------+--------------------------------------+
| Variable_name              | Value                                |
+----------------------------+--------------------------------------+
| wsrep_local_state_comment  | Synced                               |
| wsrep_cluster_size         | 2                                    |
+----------------------------+--------------------------------------+

• wsrep_local_state_comment 옵션이 Joiner이면 아직 데이터 동기화가 진행 중으로 이 상태에서 절대 새로운 노드를 추가하면 안된다. Synced로 전환되면 데이터 동기화가 완료되어 새로운 노드 추가가 가능하다.
• wsrep_cluster_size 옵션은 전체 클러스터 구성 노드 수를 의미한다.

참고 글

• Configuring Nodes for Write-Set Replication
• Bootstrapping the First Node
• Adding Nodes to Cluster
• Verifying Replication
• Comparing Galera wsrep sst methods rsync vs. mariabackup
• Galera cluster unable to sync SST: xtrabackup checkpoints missing, failed innobackupex on donor
• How to Avoid SST When Adding a New Node to MySQL Galera Cluster
• Change from rsync to xtrabackup - avoid read-only Donor during SST