MySQL Replication과 Galera Cluster에 대하여

Galera에 대해 말하기 전에, 우선 MySQL의 복제 방식에 대해 알아보자.

일반적으로 Master/Slave 방식으로 구성한다. 2개 노드 중 한 노드는 Read, 한 노드는 Write를 담당하게끔 한다. DB마다 차이는 있지만 보통 Read 작업의 비중이 더 크다. 따라서 Read/Write의 분리만으로도 의미는 있다.

좀 더 자세히 알아보자.

Master 노드에서 Write 작업이 수행되면, 이 노드는 데이터를 저장하고 트랜잭션 로그를 Bin Log라는 파일에 저장한다.
그러면 Slave 노드는 Master 노드의 Bin Log를 가져온다. 이 가져오는 작업(뽁사 작업)은 IO Thread라는 스레드가 담당한다. 그리고 가져온 내용은 Replay Log라는 파일에 기록한다. 그러면 SQL Thread라는 스레드가 차례대로 읽고 수행하여 MySQL 데이터 파일에 기록한다.

• 예를 들어 Master 노드에서 하나의 Update 쿼리가 실행되면
• 그 쿼리는 Master 노드의 Bin Log에 저장되고
• 이 Bin Log 내용은 다시 Slave 노드에 저장되고
• Slave 노드에서 Master 노드에서 실행되었던 Update 쿼리가 수행되는 것이다.

이 방식의 장점은 단순하다는 것, 반면 단점들은 다음과 같다.

• Read/Write 노드를 분리해야 한다.
• 데이터 복제가 비동기 방식으로 저장된다. 즉, 일정 시간 사이에는 데이터 불일치가 발생할 수 있다.

그럼 이제부터 Galera 클러스터에 대해 알아보자.

• 오픈 소스이다.
• 동기 방식의 복제를 지원한다. 따라서 동시에, 데이터 유실없는 복제를 보장한다.
• 노드 간 통신을 위해 wsrep API를 사용한다.
• Active-Active 방식의 다중 Master 구성 및 모든 노드에서 Read/Write가 가능하다.
• 노드 컨트롤, 특정 노드 장애 시에 자동으로 장애 노드가 제거된다.
• 자동으로 신규 노드를 추가한다. (단, 신규 노드 추가 시 모든 데이터를 복사하기 때문에 부하가 발생한다!)

wsrep란?

MySQL의 InnoDB 스토리지 엔진 내부에서 Write Set을 추출하고 구현한다. Write Set은 트랜잭션을 기록하는 모든 논리적인 데이터 집합이라고 보면 된다. 노드 간 Write Set을 전송하거나 통신하기 위해서는 별도의 복제 플러그인을 사용하며, 복제 엔진은 wsrep에 정의된 call/callback 함수에 의해 동작한다.

다만, Galera도 단점을 가지고 있다.

• Galera는 동기 방식이라는 장점이 있다. 한 노드에서 데이터를 디스크에 저장하기 전에 다른 노드에 데이터 복제 요청을 해야 한다. 따라서 비동기 방식에 비해 Write 성능이 떨어진다.
• 장애 전파이다. 다른 노드로 복제 요청을 했는데, 그 노드(To-Server)가 문제가 있어서 응답을 하지 못하면, 요청한 노드(From-Server)는 대기를 타게 된다. 이것은 유사한 매커니즘을 사용하는 다른 S/W도 동일하게 안고 있는 문제이다.
• 확장의 한계이다. 노드 수가 많아지면 복제에 걸리는 시간, 비용이 노드 수에 비례하여 늘어나기 때문에 어느 정도 한계성을 가지고 있다.

이외에 뜬금없는 이야기지만 서로 다른 MySQL 간에도 Galera 구성을 할 수 있다.

설치에 대하여..
yum 방식으로 설치하거나, rpm 파일을 이용하여 직접 설치할 수 있다.

설정 파일 내용 중에는..

• server-id : 각 노드간 고유해야 한다.
• wsrep_custer_address : 바라보는 대상 노드의 IP이다.
• wsrep_node_address : 내 IP이다.