MariaDB 5.5 Galera Cluster Startup and Shutdown v1.0
|
13.09.05 |
1.0 |
|
|
|
|
|
|
|
|
|
1. Galera Cluste
이 문서에서는 Galera Cluster 의 Startup 과 Shutdown 절차에 대해 다루었다.
2. Environments
n 3 node
n wsrep_cluster_address
a. 1번노드 (172.18.174.161) : gcomm://172.18.174.162
b. 2번노드 (172.18.174.162) : gcomm://172.18.174.161
c. 3번노드 (172.18.174.160) : gcomm://172.18.174.162
3. Checking Cluster’s health
Cluster 이상 유무의 확인은 다음의 두 status 값을 확인하여 체크할 수 있다.
n wsrep_cluster_status = Primary
n wsrep_ready = on
위 status 에 이상이 있는 경우 위 status 값은 다음과 같이 조회된다.
n wsrep_cluster_status = non-Primary
n wsrep_ready = off
클러스터에 이상이 있는 경우 DB 의 사용이 제한된다.
l USE <DATABASE> 사용불가
l SELECT, DML 사용불가
아래 TEST 항목에서 말하는 Cluster 상태가 정상이다 함은 위에 언급한 두 status 의 값이 정상값임을 의미한다.
4. TEST (OUTLINE)
비정상 종료는 (ABORT) 를 가정한다.
OS 상에서 mysql 을 kill 하는 것으로 진행하였다.
a. NODE #1 의 비정상 종료
b. NODE #2 의 비정상 종료
c. NODE #3 의 비정상 종료
d. NODE #1, #2 의 비정상 종료
e. NODE #1, #3 의 비정상 종료
f. NODE #2, #3 의 비정상 종료
5. TEST
a. NODE #1 의 비정상 종료
b. NODE #2 의 비정상 종료
c. NODE #3 의 비정상 종료
a, b, c 의 경우에 대해 Cluster 에 이상이 없음을 확인하였다.
비정상 종료 된 노드에는 다음과 같이 alert log 가 기록되었다.
130905 14:25:54 mysqld_safe Number of processes running now: 0
130905 14:25:54 mysqld_safe WSREP: not restarting wsrep node automatically
130905 14:25:54 mysqld_safe mysqld from pid file /data/galera/data/xdevmari2.pid ended
특이한 것은 mysql_safe 가 mysqld 를 재기동하지 않고 shutdown 된다는 것이다.
살아있는 다른 노드의 alert log 에는 nonlive peers: tcp://172.18.174.162:4567 라는 메시지가 확인되었다.
위의 D 클래스는 죽어있는 노드의 IP 값이 나온다.
이후 죽어있는 노드를 다시 Startup 하면 클러스터에 정상적으로 복귀한다.
d. NODE #1, #2 의 비정상 종료
e. NODE #1, #3 의 비정상 종료
f. NODE #2, #3 의 비정상 종료
3개 구성의 클러스터에서 2개의 노드가 비정상 종료가 되면 살아있는 한 노드는 서비스가 불가한 비정상 상태가 된다.
이 경우에 이르면 Restart 과정을 밟아야 한다.
비정상 상황의 살아있는 유일한 노드의 alert log 에는 wsrep_cluster_address 에 명기된 주소에 계속 접속시도를 한다.
130904 16:09:31 [Note] WSREP: (92009f50-1529-11e3-0800-1fb9c9bb7be0, 'tcp://0.0.0.0:4567') reconnecting to b61b2ba6-152b-11e3-0800-4eafdc6f57f5 (tcp://172.18.174.162:4567), attempt 900
위 상황에서 일정 시간이 지나면 비정상 상태가 된다.
그 이후에도 reconnecting 을 계속 시도를 하는데 타겟팅이 되는 addr 의 노드를 startup 해도 클러스터 구성에 들어가지 못 한다.
|
130905 16:06:22 [ERROR] WSREP: gcs/src/gcs_core.c:gcs_core_open():195: Failed to open backend connection: -110 (Connection timed out) 130905 16:06:22 [ERROR] WSREP: gcs/src/gcs.c:gcs_open():1290: Failed to open channel 'gallera_test' at 'gcomm://172.18.174.161': -110 (Connection timed out) 130905 16:06:22 [ERROR] WSREP: gcs connect failed: Connection timed out 130905 16:06:22 [ERROR] WSREP: wsrep::connect() failed: 6 130905 16:06:22 [ERROR] Aborting |
결론은 앞서 이야기 한 것 같이 Restart 를 해 줘야 한다.
wsrep_ready = off 인 상황에서는 달리 방법이 없다.
6. Restarting Cluster
MariaDB 의 정상적인 종료 방법은 순서에 상관없이 Shutdown 하면 된다.
정상적인 종료라면 클러스터 상태에 영향을 끼치지 않는다.
STARTUP 의 경우에는 wsrep_cluster_address = ‘gcomm://’ 으로 초기화 기동해야 한다.
STARTUP 이후 두 번째 노드는 wsrep_cluster_address 값이 첫 번째 노드를 가리키고 있는 대상을 startup 해야 한다.
그렇지 않으면 인스턴스가 기동되지 않는다.
세번째 까지 기동한 이후에는 첫 번째 wsrep_cluster_address 값을 초기화 값이 아닌 값으로 원복한다.
만약 초기화 값 상황에서 해당 노드를 restart 하게 되면 기존의 클러스터에 참여하는 것이 아니라 새로운 클러스터 구성으로 기동하게 된다.
Startup 의 최대 과제는 Donor 문제이다.
Cluster 의 최초 노드 기동을 제외하고 기동을 위해서는 이미 살아있는 노드에 대해 wsrep_cluster_node 에 지정이 되어야 한다.
그리고 이 노드는 Donor 가 된다.
Donor node 의 최대 문제는 DML 이 불가능하다는 것이다.
3개 노드 구성의 경우 한 노드에 문제가 있어 구성에서 빠졌다가 다시 넣는 경우 살아있는 두 노드 중에 한 노드는 가용 불가능한 상황이 된다.
나머지 한 노드가 정상적으로 서비스를 할 수 있다는 것인데 여기서 문제가 있다.
노드를 L4 로 묶어 하나의 IP 로 서비스를 한다고 가정하면 스위치 입장에서는 두 개 노드가 다 가용 가능한 상황으로 판단할 것이다.
하지만 실제로는 Donor 역할을 수행하는 노드는 일시적으로 가용 가능하지 않다는 것이다.
7. Future Challenges
A. wsrep_cluster_address 구성방법에 대한 고민
B. Donor node 로 인한 서비스 장애상황 회피 방안
C. mysqld 비정상 종료에 대해 자동으로 startup 이 가능한지