MySQL이 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' 카테고리의 다른 글
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 |