갈레라(Galera) 클러스터링의 주의사항 ( feat. 2개의 node )

지난 금요일... 휴가중에 전화를 받았다...

 

'형, MariaDB가 뻑났어요!'

 

긴급조치사항으로 DB서버를 재구동하는 수밖에없어 재시작을 하면서 이제껏 알아보기를 미뤄두었던 것에대해 알아보려고 한다.

 

1. 갈레라 클러스터링의 노드 수

 

공식문서상에서는 3개의 노드를 추천한다. 여기서 노드란 일종의 MariaDB가 설치되어 있는 서버를 의미한다.

 

하지만 나는 기어코 2개의 노드를 사용해서 구축한것이 원인이 된 것 같다.

 

왜 2개로 했는지는 공식문서와 같다. 서버도 2대밖에 여유분이 없었기 때문이라는 변명아닌 변명이다.

 

그러면 왜? 짝수개의 노드를 추천하지 않을까?

 

3개 노드 추천 설명과 2개 노드 구성시 단점 설명글

 1) 스플릿 브레인 (split-brain)

 

공식 문서상의 내용은 다음과 같이 적혀있다.

 

2 노드 구성시 문제사항

 글의 내용을 정리하면,

 

 만약 동일한 테이블, 동일한 row를 해결하기 위해 각 노드가 쿼리문 실행이 진행된다. 하지만, 여기서 각 노드는 자신이 

 

 우선순위를 갖는다고 하고 진행(투표)를 하는데 여기서 실질적인 실행 결정(결정 투표)를 하는 것이 3번째 노드이다.

 

 그런데 여기서 3번째 노드가 없다면 서로 자신이 우선순위라고 우기는 현상을 '스플릿 브레인' 이라고 하는 것이다.

 

 한마디로 둘이 서로가 우세하다고 싸우는 현상인 것이다. 

 

 2) 1 노드 다운 시 2번째 노드 작동 못하는 현상

 

 1번째의 스플릿 브레인은 그럴수 있다고 생각하지만 2번째 사항은 버그라고 생각하는데 갈레라는 그렇게 생각하지 않는 것 같다.

 

 만약 갈레라를 통해 A,B 서버간의 동기화 진행 중에 연결이 유실 되었다고 가정해보자. 

 

 그러면 A와 B서버의 MariaDB는? '죽지 않는다'

 

 단순히 갈레라 클러스터링은 오라클의 RAC처럼 실시간 동기화를 진행하기 위한 오픈 소스이지 MariaDB의 자체적인

 

 기능은 아니라서 오픈소스가 끊어진 것이고 MariaDB는 살아 있다는 것이다.

 

 그러면 A,B서버 모두 우선순위를 가지려는 현상이 발생되며 정상적으로 구동이 되지 않는 다는 것이다.

 

 이런 에러에도 왜 굳이 갈레라를 써야할까...

 

 1. 실시간 동기화

 2. A-A의 구조의 장점

 3. 번거로운 DB Read/Write설정의 불필요

 

 더 많은 장점이 있지만 MariaDB자체에서 제공하는 Replication이 있다. 하지만 이 기능은 위의 기능을 만족하지 않는다.

 

 실시간 동기화가 불가능하고, 데이터에 대한 유실도 있을 수 있으며, A-A구조를 갖지 못하고 Read를 하는 DB, Write하는 DB 따로 존재해야 한다.

 

 그러면 정말 2개의 노드로는 클러스터링이 불가능 한 것인가...

 

 친절하게 권장하는 2가지 대처 방안이 존재한다.

 

 1. 투표권을 없앤다.

 

  Galera Arbitrator를 사용하여 클러스터의 한 축이 되지만 실제 데이터 복제하지 않게 하겠다는 것이다.

  

  위의 예시와 같이 제 3의 서버에 설정을 통해 실질적으로 순위 결정 투표권만 가지게 하여 노드가 죽은 상태에서도 

 

  실행 시키는 방법이다.

 

2. 자신이 우선순위 노드라는 것을 인식시킨다.

  어찌보면 가장 단순한 방법일 수 있겠다. 단순 로그인 후 쿼리를 통해 설정값만 바꾸면 되니 말이다.

 

  해당 내용은 살아있는 노드를 부트스트랩을 통해 우선순위의 노드로 강제로 인식히는 방법이다. 

 

  이렇게 되면 실제로 다시 다른 노드와의 연결이 가능한 경우 동기화 데이터를 전송한다는 것이다.

 

이로써 왜 장애가 났고, 어떻게 대처해야 하는지에 대해 알아봤다.

 

아마 운영중인 상황이라 바로 적용은 안되겠지만 한번 건의를 해봐야겠다.

 

다음 글에서는 에러같지만 에러가 아니라고 우기는 Galera 사용시 auto_increment에 대해 알아보겠다...