마리아db 마리아디비 / 클러스터링 / 클러스터 방법
MariaDB Galera cluster 설정
절차
- MariaDB Galera 설치
- MariaDB Galera Cluster 설정
MariaDB Galera Cluster 설정
1번째 node 는 --wsrep-new-cluster 으로 실행해야 한다. 그
이후 cluster 에 attach 하는 node 는 --wsrep-new-cluster
옵션을 빼야 한다. --wsrep-new-cluster 을 붙이면 cluster 가
사용할 cluster UUID 를 만들기 때문에 기존의 cluster로 접속이
안된다.(다른 참고: Starting
the Cluster — Galera Cluster Documentation)
만약 전체가 다 내려간 후 다시 clustering 을 시작할때도 1번째 node가 cluster 를 만들고, 그 cluster에 node를 붙이는 방식으로 해야 한다.
mysqld --wsrep-new-cluster기존의 cluster 에 node 를 추가할 때
option file 에 아래처럼 추가하면 된다.
[mariadb]
...
wsrep_cluster_address=gcomm://192.168.0.1 # DNS names work as well, IP is preferred for performance가장 최신 node 를 찾는데 도움이 되는 option
경우에 따라 Galera가 클러스터에서 가장 최신의 node(most advanced node)가 아닐 수 있다는 것을 감지하면 노드 bootstrap을 거부할 수 있다. Galera는 노드가 클러스터에서 마지막으로 종료된 노드가 아닌지 또는 노드가 충돌했는지 여부를 확인한다. 이러한 경우에는 수동 개입이 필요하다.
어떤 노드가 가장 높은 level인지 확실히 알고 있다면 datadir에서 grastate.dat 파일을 편집할 수 있다. 가장 최신의 node(most advanced node)에서 safe_to_bootstrap=1을 설정할 수 있다.
각 노드에서 grastate.dat을 확인하고 seqno가 가장 높은 노드를 찾아
어떤 노드가 가장 높은 level인지 확인할 수 있다. 노드가 충돌하고
seqno=-1인 경우, wsrep_recover 옵션을 사용하여 각 노드에서
seqno를 복구하여 가장 최신의 node(most advanced node)를 찾을 수
있다.
mysqld --wsrep_recover모든 node 가 죽은 경우, 다시 bootstrap 을 할 node 를 선택할 때 어떤 노드로 시작하느냐.
The Safe-To-Bootstrap Feature — Galera Cluster Documentation → Selecting the Right Node 내용 정리
- 순서대로 shutdown 된 경우
- 각 노드의
grastate.dat를 확인해서,safe_to_bootstrap: 1인 node 를 택해서 bootstrap 을 진행한다.
- 각 노드의
- hard crash
- 모든 노드가
safe_to_bootstrap: 0가 된다. - 클러스터에서 마지막 트랜잭션을 commit한 노드를 찾아야 한다. 이것은
mysqld --wsrep-recover를 통해서 찾을 수 있다. 아래처럼 log 가 만들어진다. 여기서 ‘Recovered position’ 에<UUID>:<seq_no>가 적혀있는데, 이 때 seq_no 가 가장 큰 node 를 찾는다. - 그리고 그 node 의
grstate.dat의safe_to_bootstrap을1로 변경해서 bootstrap 을 진행한다.
2016-11-18 01:42:15 36311 [Note] InnoDB: Database was not shutdown normally! 2016-11-18 01:42:15 36311 [Note] InnoDB: Starting crash recovery. ... 2016-11-18 01:42:16 36311 [Note] WSREP: Recovered position: 37bb872a-ad73-11e6-819f-f3b71d9c5ada:345628 - 모든 노드가
모니터링(monitoring)
SHOW GLOBAL STATUS LIKE 'wsrep_%';Clustering 사용전 알아두면 좋은 사항
swap size 요구사항
정상 작동 중에 MariaDB Galera 노드는 일반 MariaDB 서버보다 훨씬 많은 메모리를 사용하지 않는다. certification index 및 uncommitted writesets에는 추가 메모리가 사용되지만 일반적으로 일반적인 응용 프로그램에서는 이러한 메모리가 눈에 띄지 않습니다. 그러나 한 가지 예외가 있습니다.
- 상태 전송 중 Writeset caching : 노드가 state transfer 을 수신하는 경우 아직 적용할 state가 없기 때문에 수신한 writesets을 처리하고 적용할 수 없습니다. state transfer 메커니즘(예: mysqldump)에 따라 state transfer을 전송하는 노드도 writesets를 적용하지 못할 수 있습니다. 따라서 이러한 writesets를 caching하여 후속 단계를 수행해야 한다. 현재 writesets는 메모리에 캐시되며, 만약 시스템이 메모리를 다 쓰면 2가지 경우로 처리된다. state transfer이 실패하거나, 클러스터가 state transfer이 끝나기를 기다리는 것을 block한다.
writeset cache에 대한 메모리 사용량을 제어하려면 Galera parameters(gcs.recv_q_hard_limit, gcs.recv_q_soft_limit 및 gcs.max_throttle)를 확인하자.
댓글 없음:
댓글 쓰기