Mariadb galera cluster 로 구성하는 MySQL 호환 Multimaster DBMS, on Ubuntu
Technical/DBMS 2015. 7. 13. 12:15MySQL이 Oracle 에 인수될 즈음부터 MySQL을 기반으로 하면서 보다 향상된 개념으로 각자가 이름을 떨치며 꾸준히 진행되어 온 프로젝트가 바로 Percona와 MariaDB이다. 참고로 두 프로젝트의 연관성을 비교하는 내용은 이 곳의 포스팅을 보시면 되겠고, 이번 포스팅에서는 Codership이 만든 Synchronous Multimaster 방식의 Galera cluster 를 설치해 보고, 운영에 관련해서 고려할 점들을 정리해 두려 한다.
Multimaster, Synchronous 한 특징을 가지는 이러한 MM 솔루션이 나오기 전에는(물론 완성도가 떨어지고 운영상 불편했던 MMM 같은 것도 있기는 했다), Master-Slave 구조의 비동기 Replication 방식이 많이 쓰였다. 한 편으로는 Semi-sync(Master는 변경 사항을 Slave 로 전달하는 것 까지만 책임을 진다)라는 장점을 가지기는 했지만 태생적으로 비동기식에서 벗어날 수 없기에, 만약의 상황에서 데이터 손실을 감수해야 하는 한계를 지녔었다고 볼 수 있겠다.
다뤄 나가고자 하는 내용을 간단히 요약하면 다음과 같다
* MariaDB Galera Cluster 설치 및 설정 과정
* 노드의 추가(확장)과 Maintenance를 위한 제거 등 운영 방법
1. MariaDB Galera Cluster 설치 및 설정 과정
설치 방법은 소스 빌드, 바이너리 다운로드&설치, rpm 설치 등 여러 가지가 있지만, 여기서는 mariadb.org 에서 권고하는 distro별 링크를 통해 단계를 밟아 나가는 내용을 그대로 따르면서 진행해 보자.
본 글에서 선택한 설치, 운영 환경: Ubuntu 14.04 Trusty, MariaDB 10, Kaist archive
* 설치 & 테스트를 진행할 3개의 Ubuntu 14.4 머신을 준비한다
- ubuntu14-pv1, 10.0.10.1
- ubuntu14-pv2, 10.0.10.2
- ubuntu14-pv3, 10.0.10.3
* Local network이 아닌 외부 망을 통하여 노드간 원격 접속이 필요한 경우(AWS AZ 도 포함) 또는 서버 자체 방화벽(ufw 등) 이 설정되어 있을 때는, 방화벽 설정에서 TCP 3306/4568/4444 port와 TCP, UDP 4567 을 개방해야 한다(☞참조)
첫 번째 Cluster, Doner 노드의 설치와 기동
* 대다수 작업이 root 권한을 필요로 하므로 super user 로 로그인하여 진행한다
* 설치 과정에서 mysql 관리자 계정인 root 암호를 2번 입력(여기서는 편의상 maria 로 정한다)
* 첫 번째로 설정되어 기동되는 MariaDB 머신 도너(Doner) 노드라고 부르며, 다음과 같이 설정
* 여러 머신간의 데이터 동기화가 중요한 환경에서는, DB 데몬이 머신 부팅 후 자동 실행되는 방식을 피하는 것이 바람직
ubuntu@ubuntu14-pv1:~$ su -
root@ubuntu14-pv1:~# apt-get install software-properties-common
root@ubuntu14-pv1:~# apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xcbcb082a1bb943db
root@ubuntu14-pv1:~# add-apt-repository 'deb http://ftp.kaist.ac.kr/mariadb/repo/10.0/ubuntu trusty main'
root@ubuntu14-pv1:~# apt-get update
root@ubuntu14-pv1:~# apt-get install mariadb-galera-server
root@ubuntu14-pv1:~# mysql_secure_installation
root@ubuntu14-pv1:~# mysql -uroot -pmaria
MariaDB [(none)]> grant all on *.* to 'root'@'%' identified by 'maria';
MariaDB [(none)]> grant usage on *.* to sst_user@'%' identified by 'maria';
MariaDB [(none)]> grant all privileges on *.* to sst_user@'%';
MariaDB [(none)]> flush privileges;
MariaDB [(none)]> quit
root@ubuntu14-pv1:~# service mysql stop
root@ubuntu14-pv1:~# apt-get install sysv-rc-conf <== mysqld 의 자동 실행을 중지하기 위함
root@ubuntu14-pv1:~# sysv-rc-conf <== runlevel 2~5 에 대해 space 를 눌러서 해제
* 복제 방법으로 Percona 의 xtrabackup 을 사용하기 위함(rsync 를 선택할 경우 설치하지 않아도 됨)
* 이 경우 데이터스트림 전송을 위한 다용도 relay 솔루션인 socat은 꼭 설치해야 함
root@ubuntu14-pv1:~# apt-get install xtrabackup socat
* 중요 설정, 고유 입력 항목은 붉은 글씨로 표시
* wsrep_node_address 에는 머신 자체 ip 를 등록
* 초기 설정시에는 wsrep_cluster_address에 머신 자체 ip 만 등록
* wsrep_sst_receive_address 에는 자체 ip:4569 를 등록
root@ubuntu14-pv1:~# vi /etc/mysql/conf.d/mariadb.cnf
# MariaDB-specific config file.
# Read by /etc/mysql/my.cnf
[client]
default-character-set = utf8
[mysqld]
character-set-server = utf8
collation-server = utf8_general_ci
character_set_server = utf8
collation_server = utf8_general_ci
autocommit = 0
# Load Galera Cluster
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name='galera_cluster'
wsrep_retry_autocommit = 0
wsrep_sst_auth=sst_user:maria
#wsrep_sst_method = rsync
wsrep_sst_method = xtrabackup
wsrep_provider_options = "evs.keepalive_period = PT3S; evs.suspect_timeout = PT30S; evs.inactive_timeout = PT1M; evs.install_timeout = PT1M"
# Galera Node Option
wsrep_node_name='galera1'
wsrep_node_address='10.0.10.1'
wsrep_cluster_address = 'gcomm://10.0.10.1'
wsrep_sst_receive_address=10.0.10.1:4569
# Other mysqld options
default-storage-engine=innodb
binlog_format = ROW
innodb_autoinc_lock_mode = 2
innodb_flush_log_at_trx_commit = 2
innodb_locks_unsafe_for_binlog = 1
innodb_log_file_size=100M
innodb_file_per_table
query_cache_size=0
query_cache_type=0
bind-address=0.0.0.0
datadir=/var/lib/mysql
tmpdir=/tmp
user=mysql
log-error=/var/log/mysql/mysql.err
* Cluster 내에서 최초로 기동되는 MariaDB doner 노드이기에 --wsrep-new-cluster 옵션으로 시작
* [주의] Checking for corrupt, not cleanly closed... 메시지는 DB가 정상 기동 되었음을 의미함
root@ubuntu14-pv1:~# service mysql start --wsrep-new_cluster
* Starting MariaDB database server mysqld [ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing tables.
여기까지가 Doner 노드 설정 과정이다.
* 데이터베이스가 정상 작동하는지 간단히 테스트해 보고, 다음 Cluster 확장 단계로 넘어가자
root@ubuntu14-pv1:~# mysql -uroot -pmaria
MariaDB [(none)]> create database cluster_test;
MariaDB [(none)]> use cluster_test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
MariaDB [cluster_test]> create table tbl1 (id varchar(20));
Query OK, 0 rows affected (0.25 sec)
MariaDB [cluster_test]> insert into tbl1 values ('abcdefg');
Query OK, 1 row affected (0.00 sec)
MariaDB [cluster_test]> commit;
Query OK, 0 rows affected (0.00 sec)
2. 운영 요령: 노드의 추가(확장)과 머신 점검을 위한 제거 등
앞의 단계는 Cluster 에 1개의 머신만 등록한 상태이다. 이번에는 Cluster 내에 2개의 머신을 더 추가하여, Galera Cluster 에서 권장하는 최소 홀수 개인 3개를 완성하는 과정과 Failover 및 자동 복구, Cluster 내에서 노드의 제거(머신 점검 등의 상황일 때)와 재투입 과정에 대해서 정리해 보자.
Cluster 의 두 번째 노드, 첫 Joiner 노드의 추가
* 앞의 Doner 노드 설정 과정과 거의 동일하며, config(maria.cnf) 의 일부 내용과 기동 방법이 다르다
* wsrep_node_address 에는 머신 자체의 ip 를 등록
* wsrep_cluster_address 에 기존의 Doner 노드와 Joiner 노드 ip 를 등록
* wsrep_sst_receive_address 에는 자체 ip:4569 를 등록
root@ubuntu14-pv2:~# scp root@10.0.10.1:/etc/mysql/conf.d/mariadb.cnf /etc/mysql/conf.d/
root@ubuntu14-pv2:~# vi /etc/mysql/conf.d/mariadb.cnf
# MariaDB-specific config file.
...
# Galera Node Option
wsrep_node_name='galera2'
wsrep_node_address='10.0.10.2'
wsrep_cluster_address = 'gcomm://10.0.10.1,10.0.10.2'
wsrep_sst_receive_address=10.0.10.2:4569
...
* Debian, Ubuntu 계열의 경우 특별히 신경 써서 작업해 주어야 하는 부분(debian-sys-maint 계정을 동일하게)
* Doner 노드의 /etc/mysql/debian.cnf 를 복사(password 만 Doner 노드의 것을 가져와도 됨)
root@ubuntu14-pv2:~# scp root@10.0.10.1:/etc/mysql/debian.cnf /etc/mysql/
* Cluster 내에 추가 되는 Joiner 노드는 별도 옵션 없이 시작
root@ubuntu14-pv1:~# service mysql start
* Starting MariaDB database server mysqld [ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing tables.
* Doner 노드의 config 를 새로이 추가된 Joiner 를 반영하여 수정해 둔다.
root@ubuntu14-pv1:~# vi /etc/mysql/conf.d/mariadb.cnf
# MariaDB-specific config file.
...
# Galera Node Option
wsrep_node_name='galera1'
wsrep_node_address='10.0.10.1'
wsrep_cluster_address = 'gcomm://10.0.10.1,10.0.10.2'
wsrep_sst_receive_address=10.0.10.1:4569
...
* Doner 노드의 Mariadb 를 재시작할 필요는 없다(일단 맞추어 놓기만 하고, 다음에 재시작할 때 읽어 들이면 될 것이다). Joiner 가 추가되면서 이미 내부적으로 서로의 존재가 인식되었기 때문인데, Doner 노드에서 아래의 방법으로 확인할 수 있다. 즉, wsrep_cluster_address 변수는 config 에서 읽어들인 값을 가지고 있지만, Cluster 의 현재 상태 값을 가진 wsrep_incoming_addresses 는 2개 노드 접속 주소를 모두 가지고 있다.
root@ubuntu14-pv1:~# mysql -uroot -pmaria
MariaDB [(none)]> show variables like 'wsrep_cluster_address';
+-----------------------+-------------------+
| Variable_name | Value |
+-----------------------+-------------------+
| wsrep_cluster_address | gcomm://10.0.10.1 |
+-----------------------+-------------------+
1 row in set (0.00 sec)
MariaDB [(none)]> show status like 'wsrep_incoming_addresses';
+--------------------------+-------------------------------+
| Variable_name | Value |
+--------------------------+-------------------------------+
| wsrep_incoming_addresses | 10.0.10.2:3306,10.0.10.1:3306 |
+--------------------------+-------------------------------+
1 row in set (0.00 sec)
Cluster 의 세 번째 노드, 새로운 Joiner 노드의 추가
* wsrep_node_address 에는 머신 자체의 ip 를 등록
* wsrep_cluster_address 에 기존의 노드에 추가하여 새로운 Joiner 노드 ip 를 등록
* wsrep_sst_receive_address 에는 자체 ip:4569 를 등록
root@ubuntu14-pv3:~# scp root@10.0.10.2:/etc/mysql/conf.d/mariadb.cnf /etc/mysql/conf.d/
root@ubuntu14-pv3:~# vi /etc/mysql/conf.d/mariadb.cnf
# MariaDB-specific config file.
...
# Galera Node Option
wsrep_node_name='galera3'
wsrep_node_address='10.0.10.3'
wsrep_cluster_address = 'gcomm://10.0.10.1,10.0.10.2,10.0.10.3'
wsrep_sst_receive_address=10.0.10.3:4569
...
* Doner 노드의 /etc/mysql/debian.cnf 를 복사
root@ubuntu14-pv3:~# scp root@10.0.10.1:/etc/mysql/debian.cnf /etc/mysql/
* Cluster 내에 추가 되는 Joiner 노드이므로 별도 옵션 없이 시작
root@ubuntu14-pv3:~# service mysql start
* Starting MariaDB database server mysqld [ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing tables.
* 기존의 Doner 노드와 Joiner 노드의 config 를 새로이 추가된 Joiner 를 반영하여 수정해 둔다. 앞 선 과정과 같은 요령
* 위와 마찬가지로 기존 MaraiDB들을 재시작할 필요는 없다
root@ubuntu14-pv1:~# vi /etc/mysql/conf.d/mariadb.cnf
# MariaDB-specific config file.
...
# Galera Node Option
wsrep_node_name='galera1'
wsrep_node_address='10.0.10.1'
wsrep_cluster_address = 'gcomm://10.0.10.1,10.0.10.2,10.0.10.3'
wsrep_sst_receive_address=10.0.10.1:4569
...
root@ubuntu14-pv2:~# vi /etc/mysql/conf.d/mariadb.cnf
# MariaDB-specific config file.
...
# Galera Node Option
wsrep_node_name='galera2'
wsrep_node_address='10.0.10.2'
wsrep_cluster_address = 'gcomm://10.0.10.1,10.0.10.2,10.0.10.3'
wsrep_sst_receive_address=10.0.10.2:4569
...
여기까지가 두 번째 Joiner 노드 추가 과정이며, 목표로 했던 3대로 이루어진 Galera cluster 가 완성되었다.
* 3대로 구성된 Galera Cluster 가 정상 작동하는지 간단한 테스트를 해 보자
root@ubuntu14-pv1:~# mysql -uroot -pmaria
MariaDB [(none)]> show variables like 'wsrep_cluster_address';
+--------------------------+----------------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------------+
| wsrep_incoming_addresses | 10.0.10.3:3306,10.0.10.2:3306,10.0.10.1:3306 |
+--------------------------+----------------------------------------------+
1 row in set (0.01 sec)
MariaDB [(none)]> insert into cluster_test.tbl1 values ('xyz123');
1 row in set (0.01 sec)
MariaDB [(none)]> commit;
0 row in set (0.00 sec)
* 최초에 Doner 에서 insert 했던 데이터와 직전에 insert 했던 데이터가 모두 조회된다
root@ubuntu14-pv3:~# mysql -uroot -pmaria -e "select * from cluster_test.tbl1;"
+--------+
| id |
+--------+
| abcdefg |
| xyz123 |
+--------+
Cluster 내의 노드를 제거/복원(재투입)하려면?
서버 머신 점검을 위해 Doner 노드(ubuntu14-pv1)를 Cluster 에서 제거해야 하는 상황이다. 아래의 과정으로 밟도록 하자.
* config 에서 wsrep_cluster_address 설정을 gcomm:// 로 클리어하고 DB를 재시작하면 Cluster 에서 제거됨
root@ubuntu14-pv1:~# vi /etc/mysql/conf.d/mariadb.cnf
...
# Galera Node Option
wsrep_node_name='galera1'
wsrep_node_address='10.0.10.1'
#wsrep_cluster_address = 'gcomm://10.0.10.1,10.0.10.2,10.0.10.3' <== Comment out
wsrep_cluster_address = 'gcomm://' <== 추가
wsrep_sst_receive_address=10.0.10.1:4569
...
root@ubuntu14-pv1:~# service mysql restart
* Stopping MariaDB database server mysqld [ OK ]
* Starting MariaDB database server mysqld [ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing tables.
root@ubuntu14-pv2:~# mysql -uroot -pmaria -e "show status like 'wsrep_incoming_addresses';"
+--------------------------+-------------------------------+
| Variable_name | Value |
+--------------------------+-------------------------------+
| wsrep_incoming_addresses | 10.0.10.3:3306,10.0.10.2:3306 |
+--------------------------+-------------------------------+
root@ubuntu14-pv3:~# mysql -uroot -pmaria -e "show status like 'wsrep_incoming_addresses';"
+--------------------------+-------------------------------+
| Variable_name | Value |
+--------------------------+-------------------------------+
| wsrep_incoming_addresses | 10.0.10.3:3306,10.0.10.2:3306 |
+--------------------------+-------------------------------+
ubuntu14-pv1 머신의 점검/수리가 끝났다. 원래 대로 재투입하려면 다음 과정을 밟으면 된다.
* config 를 이전 상태로 되돌리고 단순히 restart 하면 끝(이미 Galera Cluster 내에 노드가 1개 이상 작동중일 때에는 --wsrep-new-cluster 옵션을 쓰지 않음)
root@ubuntu14-pv1:~# vi /etc/mysql/conf.d/mariadb.cnf
...
# Galera Node Option
wsrep_node_name='galera1'
wsrep_node_address='10.0.10.1'
wsrep_cluster_address = 'gcomm://10.0.10.1,10.0.10.2,10.0.10.3' <== Uncomment
# wsrep_cluster_address = 'gcomm://' <== Comment out
wsrep_sst_receive_address=10.0.10.1:4569
...
root@ubuntu14-pv1:~# service mysql restart
* Stopping MariaDB database server mysqld [ OK ]
* Starting MariaDB database server mysqld [ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing tables.
root@ubuntu14-pv2:~# mysql -uroot -pmaria -e "show status like 'wsrep_incoming_addresses';"
+--------------------------+----------------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------------+
| wsrep_incoming_addresses | 10.0.10.3:3306,10.0.10.2:3306,10.0.10.1:3306 |
+--------------------------+----------------------------------------------+
root@ubuntu14-pv3:~# mysql -uroot -pmaria -e "show status like 'wsrep_incoming_addresses';"
+--------------------------+----------------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------------+
| wsrep_incoming_addresses | 10.0.10.3:3306,10.0.10.2:3306,10.0.10.1:3306 |
+--------------------------+----------------------------------------------+
3. 노드간 데이터 복제가 잘 되지 않는 것 같다. 확인/조치 방법은?
Cluster 내의 모든 노드들은 자신이 Primary 노드라고 인식한다(☞참고). 그러나 특정한 상황, 즉 네트워크 일시적 단절(network glitch), 과반수 이상의 노드가 장애를 겪거나 또는 split-brain 상태에 빠질 수도 있다. 이렇게 되면 데이터의 동기화에 문제가 발생할 가능성이 커지게 된다.
[여기서 잠깐] split-brain 에 대해 정리해 둘 필요가 있다. 일반적인 split-brain 이란 Master-Slave 상황에서 각자가 Master(또는 primary) 라고 인식하게 되는 상황을 말한다. Galera Cluster 와 같은 Multimaster 의 경우에도 Doner와 Joiner 관계가 있는 것과 같이 Master라 하더라도 '급' 이 다른 구분이 필요하다(즉, "데이터의 오리지널 소스가 누구지?"에 대한 답이 필요하다). 잠시 후 2-node 구성일 때의 네트워크 단절 상황에 대해 테스트 해보기로 하자.
첫 번째 장애: 3-node 구성일 때 1대의 머신에 네트워크 장애 발생
* node2의 네트워크 단절(머신 자체는 동작하지만 node1, node3 과 네트워킹이 안되도록 iptables 로 장애를 흉내 냄)
* 일정 시간이 지나면 node2 는 '쓰기 불가' 상태에 빠지며 wsrep_local_index가 0으로 떨어짐
root@ubuntu14-pv2:~# iptables -A INPUT -d 10.0.10.2 -s 10.0.10.1 -j REJECT
root@ubuntu14-pv2:~# iptables -A INPUT -d 10.0.10.2 -s 10.0.10.3 -j REJECT
root@ubuntu14-pv2:~# mysql -uroot -pmaria
MariaDB [(none)]> show status like 'wsrep_local_index';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| wsrep_local_index | 1 |
+-------------------+-------+
MariaDB [(none)]> show status like 'wsrep_local_index';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| wsrep_local_index | 0 | <== 값이 0인 노드는 Doner 또는 Standalone 노드
+-------------------+-------+
MariaDB [(none)]> show status like 'wsrep_incoming_addresses';
+--------------------------+----------------+
| Variable_name | Value |
+--------------------------+----------------+
| wsrep_incoming_addresses | 10.0.10.2:3306 |
+--------------------------+----------------+
MariaDB [(none)]> show status like 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 1 |
+--------------------+-------+
MariaDB [(none)]> show status like 'wsrep_cluster_status';
+----------------------+-------------+
| Variable_name | Value |
+----------------------+-------------+
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+
MariaDB [(none)]> insert into cluster_test.tbl1 values ('data1234');
ERROR 1047 (08S01): WSREP has not yet prepared node for application use
* [주의사항] Cluster에서 제외된 노드(여기서는 node2)에서는 정상적인 쿼리가 수행되지 않는다
* 이 때 wsrep_provider_options 변수에 pc.bootstrap=1(YES) 값을 설정하면 자체가 Standalone 모드로 작동하게 할 수 있다. 단, 네트워크를 정상화한 이후에 다시 Cluster 내에 투입하려면 반드시 MySQL을 재시작해야 한다
* Cluster 내에서 하나의 노드에서만 수행해야 한다(galera Cluster 에서는 Automatic Bootstrap 이라고 함)
root@ubuntu14-pv2:~# mysql -uroot -pmaria
MariaDB [(none)]> SET GLOBAL wsrep_provider_options='pc.bootstrap=1';
* [주의사항] 또 다른 장애 발생 가능성: 이 상황에서 node2의 특정 테이블에 insert 후 PK 변경 DDL 수행시, Cluster에 재투입하면 node1, node3 에서는 Deadlock 발생 가능성이 있음
* 따라서, Cluster 에서 제외된 노드에서는 더 이상의 DDL이나 insert/update 쿼리가 돌지 않도록 특별히 유의해야 함
root@ubuntu14-pv1:~#
MariaDB [cluster_test]> select * from tbl1;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
root@ubuntu14-pv3:~#
MariaDB [cluster_test]> select * from tbl1;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
* [원상복귀] node1, node3 은 정상 작동 중인 상황, node2를 되살린다
* node2 의 네트워크를 되살리면 일정 시간이 지나 node1, node2가 있는 Cluster 로 자동 복귀
root@ubuntu14-pv2:~# iptables -F <== 네트워크 장애가 해결되었음을 시뮬레이션
[특정 노드의 전체 데이터 수동 동기화]
* node2 가 Cluster에서 분리된 이후에 Update되어 데이터가 node1, node3 에 비해 지나치게 상이한 경우의 조치(초기화)
* 아래 과정대로 하면 node1, node3로부터 전체 데이터에 대해 동기화(mysqldump, xtrabackup, rsync 등 방법도 있음)
root@ubuntu14-pv2:~# rm -rf /var/lib/mysql/*
root@ubuntu14-pv2:~# rm -rf /var/log/mysql/*
root@ubuntu14-pv2:~# mysql_install_db
root@ubuntu14-pv2:~# service mysql start --wsrep_cluster_address='gcomm://'
root@ubuntu14-pv2:~# mysql_secure_installation
root@ubuntu14-pv2:~# mysql -uroot -pmaria
MariaDB [(none)]> grant all on *.* to 'root'@'%' identified by 'maria';
MariaDB [(none)]> grant usage on *.* to sst_user@'%' identified by 'maria';
MariaDB [(none)]> grant all privileges on *.* to sst_user@'%';
MariaDB [(none)]> flush privileges;
MariaDB [(none)]> quit
root@ubuntu14-pv2:~# service mysql stop
root@ubuntu14-pv2:~# vi /etc/mysql/conf.d/mariadb.cnf
...
# Galera Node Option
wsrep_node_name='galera2'
wsrep_node_address='10.0.10.2'
wsrep_cluster_address = 'gcomm://10.0.10.1,10.0.10.2,10.0.10.3' <== Uncomment
# wsrep_cluster_address = 'gcomm://' <== Comment out
wsrep_sst_receive_address=10.0.10.2:4569
...
root@ubuntu14-pv1:~# service mysql start
* Stopping MariaDB database server mysqld [ OK ]
* Starting MariaDB database server mysqld [ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing tables.
두 번째 장애: 2-node 구성일 때 1대의 머신에 네트워크 장애 발생(split-brain 발생 위험성 존재)
* Cluster내에 2개의 노드(node1, node2) 만 남아 있는 상황
* node1-2 사이에 네트워크 장애 발생, 2개의 노드에서 동일하게 데이터베이스가 정상작동하지 않음(접속은 되나 use, select 등 기본 동작 불가)
* Cluster 내의 Master 노드 정족수가 부족(과반수를 초과해야 하나, quorom=1/2)하게 되기 때문(이러한 한계를 무시하는 설정도 있고, 노드를 흉내내 주는 대안적 방법으로 garbd(Galera Arbiter로 2개 노드일 때 quorom 값을 +1 증가시켜 줌, ☞참고) 를 쓰는 방법도 있으나, 썩 바람직하지 않으므로 Skip)
root@ubuntu14-pv2:~# iptables -A INPUT -d 10.0.10.2 -s 10.0.10.1 -j REJECT
root@ubuntu14-pv1:~# mysql -uroot -pmaria
MariaDB [(none)]> select * from cluster_test.tbl1;
ERROR 1047 (08S01): WSREP has not yet prepared node for application use
root@ubuntu14-pv2:~# mysql -uroot -pmaria
MariaDB [(none)]> use cluster_test;
ERROR 1047 (08S01): WSREP has not yet prepared node for application use
* [원상복귀] node2 의 네트워크를 되살리면 일정 시간이 지나 node1이 있는 Cluster 로 자동 복귀
root@ubuntu14-pv2:~# iptables -F
root@ubuntu14-pv2:~# mysql -uroot -pmaria
MariaDB [(none)]> show status like 'wsrep_local_index';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| wsrep_local_index | 1 |
+-------------------+-------+
- Barracuda -
'Technical > DBMS' 카테고리의 다른 글
| Mariadb galera cluster 로 구성하는 MySQL 호환 Multimaster DBMS, on Ubuntu (7) | 2015.07.13 |
|---|---|
| mongodb ttl collection 사용에 관하여(pymongo 추가) (0) | 2012.11.10 |
| Silent mode Oracle 11gr2 설치 - CentOS 5.5 x64, cloudn VM에서 (0) | 2012.09.25 |
| MongoDB 백업(dump)와 복구(restore) (0) | 2012.09.18 |
| HammerOra로 DBMS 성능 측정하기(TPC-C) -2 (2) | 2012.09.14 |
| HammerOra로 DBMS 성능 측정하기(TPC-C) -1 (0) | 2012.09.05 |
Barracuda
Bryan의 MemoLog. 쉽게 익혀 보는 IT 실습과 개념원리, 코딩 세계의 얕은 맛보기들, 평범한 삶 주변의 현상 그리고 進上, 眞想, 진상들
댓글을 달아 주세요
굳!! 차근차근 따라 하니 잘 되네요. 감사합니다!!!
도움 되셨다니 다행입니다. 고맙습니다 ^^
galera cluster 구성하는데 정말 많이 도움이 됐습니다. ^^
여건상 서버 3대구성은 힘들고 2대로 db 이중화를 하는데...어찌어찌 구성은 됐으나, 장애테스트시 spilt brain 발생을 어찌할수가 없네요 ㅜㅡ
galera cluster 2대 구성은 정말 비추일까요?
mysql replication으로 새로 구성할려고 하는데...galera에 미련이 남아서 댓글 달아 봅니다.
안녕하세요 ^^
스플릿브레인이란 녀석때문에 참 거시기한 상황이실 듯 합니다. 부하에 부담을 주지 않는 선에서 아비터를 따로 하나 두는 건 어떠실까요? 단, DB머신 2대 중 1대는
반드시 살아 있어야 한다는 전제하에서요.
문득, 본 포스팅 내용이 생각나서 다시 들춰보니, 위의 Split-brain 에 대해 설명이 다소 부족한 듯하여, 조만간 이러한 현상의 실제 예를 들어서 상세하게 보이고, Split-brain 가능성이 얼마나 위험한 상황에 직면하게 하는지를 보이도록 하겠습니다.
내용 잘봤습니다.
한가지 질문이 있습니다.
donor 노드가 종료 되었다가 다시 참여하면 그 노드가 다시 donor 노드가 된다고 하였는데
종료된 노드 실행할 때 service mysql start로 실행하셨던 것 맞으신지요?
제가 테스트 해 봤을 땐 도너노드로 변경되지 않고, 도너 노드 다음으로 실행했던 노드가
도너노드가 되어가지구요~
안녕하세요, 제 블로그인데 방문이 너무 뜸해서 죄송합니다.
Doner가 내려간 상황이면 다른 Joiner 가 doner 가 되었을테고, 내려갔던 이전 doner는 Joiner 로 올리는게 더 자연스러울 것 같습니다만, 제가 글을 쓸 때와 비교해서 시간이 너무 지나서요, 말씀하신 내용이 어디에 어떻게 언급되어 있는지 잘 기억 안나네요. 어느 부분인지요?