MariaDB 이중화 구성

• 출처 : https://www.slideshare.net/NHNFORWARD/mysql-nhn-forward-2018

[2018] MySQL 이중화 진화기

본 글은 nhn에서 발표한 레퍼런스를 참고하여 작성하였습니다.

MariaDB에서는 최근에 MaxScale을 많이 사용하는 것 같던데, 해당 게시물을 추가적으로 업데이트 하겠습니다.

1. MariaDB Replication

MariaDB에서 기본적으로 제공하는 Replication 기능이다.

Master-Slave 구조로 되어있다.
Master 서버의 Binary로그를 Slave서버가 Relay로그에 저장해서 복제하는 방식이다.

1.1 구조

1.2 장점

• 가장 간단하게 Replication을 구성할 수 있다.
• 읽기 부하 분산 및 백업을 담당할 수 있다.

1.3 단점

• Master서버와 Slave서버간 순간적인 데이터 불일치가 발생할 수 있다.
• Auto Failover가 되지 않는다.

1.4 특징

• asynchronous(비동기) 방식의 Replication은 Relay 로그 적용 상태에 따라 일관성이 깨질 수 있지만 MySQL 8.0 버전부터 제공되는 semisynchronous(반동기) Replication은 일관성을 보장할 수 있는 장치를 가지고 있다.Binary Log를 받는 서버에서 Ack를 보내야만 Master서버에서 최종적인 Commit을 함으로써 Master서버와 Slave서버간의 데이터 일관성을 보장한다.

• semi-sync 설정 방법 :
  https://hoing.io/archives/3633
• 참고 : https://dev.mysql.com/doc/refman/8.0/en/replication.html

1. MMM(Multi-Master Replication Manager)

• Perl 기반의 Auto Failover Open Source
• MMM Monitor에서 Db서버 heath check 및 Failover 수행
• Monitor <-> Agent 통신방식
• NHN에서 운영중인 이중화 방안

1.1 구조

Master(Active)와 Master(Standby- 읽기모드) 양방향 복제

1.2 Failover 과정

1. Mater 를 읽기모드로 변경
2. Master Session Kill
3. Master VIP 회수
4. Master(Standby) 복제 지연확인
5. Master(Standby)를 신규 Master로 복제 재구성
6. Master(Standby)의 읽기모드 해제
7. 신규 마스터에 VIP할당
8. Failover 완료

1.3 Failover 대상

Master(Active)와 Master(Standby)간의 양방향 복제
Master와 Slave간의 단방향 복제

1.4 Failover 후속 처리

1.5 Failover 예시

1. Master의 변경 사항을 Slave에 보내고 응답을 대기
2. Multi Slave중에 하나의 서버에서 응답을 받으면 OK 반환

1.6 Failover시 발생할 수 있는 문제

• 신규 Master DB는 정해져 있기 때문에, 신규 Master DB가 Relay Log를 전달받지 못한 상태에서 Master DB가 될 수 있다.즉 Multi Slave환경에서 복제 Crash가 발생할 수 있다.

 

1.7 MMM 단점

• MMM Manager 이중화가 불가능
• Multi Master로 사용이 가능하나 Multi Master 사용시 데이터 불일치 가능성 있음
• Active Master 장애시 데이터 유실 가능성 있음

2. MHA( Master High Availability)

• Perl 기반의 Auto Failover open source
• MySQL의 GTID 등 신 버전의 기능들을 지원
• MHA Monitor에서 Master DB 서버의 Health 체크와 Failover 관리
• Agentless 방식

2.1 MHA 구조

• Master + Slave 구조 / 모두 단 방향 복제

2.2 Failover 후속 처리

2.3 MHA Failover 대상

• 가장 최신의 동기화 상태의 Slave 선택

2.4 Failover시 복제 일관성 해결

• 1. Binary Log와 Relay Log를 비교해서 차이나는 이벤트 추출
• 1. DB간 차이나는 이벤트를 DB에 반영

 

NHN의 이중화 평가

2.5 MHA 단점

Failover 시에 relay-log를 분석해서 master로 승급할 slave를 선정해야 하고,
bin-log와 relay-log 중에서 차이나는 부분을 각 slave에 반영하여 복제 일관성을 유지시키는 작업을 수행하기 때문에 MMM에 비해서 failover에 걸리는 시간이 많다.

2.6 MHA vs MMM

MHA는 데이터 정합성이 필요한 서비스에 사용이 적합하고
MMM은 빠른 응답을 요구하는 서비스에 적합하다.

3. Galera cluster

Galera cluster는 http://galeracluster.com/ 에서 제공되는 오픈소스로, 동기방식의 복제 구조를 사용하고 있다. 그리고 InnoDB 스토리지 엔진만을 대상으로 한다.

• 내용 참고 : https://myinfrabox.tistory.com/214
• 참고 : https://mariadb.org/fest2020/galera-intro/

3.1 Galera Cluster 구조

• 각각의 노드가 있을때, 아무 노드에나 쓰기나 업데이트가 발생하면,
• 모든 노드에 데이타를 복사를 완료하고 나서, 업데이트 내용이 파일에 저장된다.

3.2 Galera Cluster 기능

• 다중 마스터 아키텍처 : 다중 읽기-쓰기 클러스터 구성
• 동기식 복제 : 클러스터의 다른 노드 간의 데이터 동기화에 있어서 지연이 없고, 데이터베이스 중단 후 데이터 손실이 없다.
• Fail-Over : 다중 마스터 아키텍처이므로, Fail-over 전환이 쉽다.
• 자동 노드 복제 : 새로운 노드를 추가할 때, 데이터를 백업/복구할 필요가 없다. 자동으로 온라인 노드 데이터를 가지고 복제를 진행한다.
• Conflict Write에 대해서 어떻게 조치하는지 확인 필요 -> 중복된 데이터에 대한 Write작업은 자동 rollback을 통해

3.2 Galera Cluster 단점

• Group Communication 을 통해 동기화 되므로 클러스터 성능은 클러스터에서 가장 낮은 성능 노드에 의해 결정된다.
• Group Communication 과정에서 하나의 노드의 장애가 전체 노드에서의 지연으로 이어질 수 있다.
• InnoDB 스토리지 엔진만 지원된다.
• 신규 노드 추가 시 모든 데이터를 복사해야 하므로 부하가 발생한다.
• 모든 노드가 동일 데이터를 보유하므로 데이터 분산이 되지 않는다.
• 서버 간 Group Communication시 트래픽 발생하므로 효과적인 쓰기 확장 솔루션에는 한계가 있다.

3.3 특징

1. 1 버전부터 MariaDB 메인 버전에 포함됨
   한국에서 참고 reference가 많지 않음

4. MaxScale

MaxScale은 MariaDB Enterprise 버전을 사용해야 하므로 조사에서 제외