본문 바로가기

CS/DataBase

(MySQL) MMM, MHA

MMM (Multi - Master Replication Manager)

  • Perl 기반의 Auto Failover Open Source
  • DB 서버에서 에이전트 실행 이 후 MMM 모니터와 통신을 하는 방식 (Health chekc, Failover 수행)
  • Monitor <-> Agent 통신방식

MMM의 구조

Master (Activce) 와 Master (Standby) 양방향 복제

Master (Standby) 는 데이터가 변경되지 않도록 MMM 모니터로부터 읽기모드로 제어된다.

 

MMM의 구조 -  Slave 추가

 

Slave가 추가된다면 단방향 복제의 Slave가 하나씩 추가되는 구조

이역시 Master(Active) 를 제외하고는 모두 읽기모드로 제어된다.

MMM FAILOVER 과정

Master(Active)에서 Master의 역할을 뺏는 작업을 진행한다.

1. 읽기모드로 변경

2. 세션 킬

3. VIP 회수

 

 

Master(Standby) 혹은 Slave로 복제를 제구성한다.

 

복제를 재구성하기 이전에

복제지연이 있는지 확인한다.



이때  Master(Standby) 기준으로 복제를 진행한다.

 

Master(Standby) 에 대한 읽기 모드를 해제하고

VIP를 할당한다.

 

FAILOVER 완료!

 

 

MMM FAILOVER의 후속처리

Master(Active)에 장애가 나고 정상적으로 복구가 완료된다면 Master(Standby)로 변경하여 역할만 변경된다.

 

FAILOVER의 원인
쿼리가 무거운것이 들어와서 OS의 메모리 점유율이 높은 경우
하이퍼 바이저 장애로 인한 경우

MMM FAILOVER 과정에서 복제가 깨지는 경우

상황을 예시로 들자면

 

INSERT INTO TABLE

VALUES (101, 'B');

 

위의 쿼리를 Master(Active) 에서 진행한다고 가정해보자. 

이때  Slave가 101 에 대한 복제를 진행하고 완료 후 Master(Active) 에게 ACK 을 보낸다.

(아직 Master(Standby)는 복제를 하지 못한 상태)

 

이 당시에 Master (Active)에서 장애가 발생하였다. 그러면 위에서 언급하였듯이 Master (Standby)가Active로 승격되고 101에 대한작업을 다시 진행하게된다.

 

여기서 문제가 발생한다. Slave는 이미 복제를 통해서 101을 가지고 있으나 Standby에 대한 권한이 올라갔으므로 또 한번의 복제과정이 일어난다. 이때 PK오류가 발생하는 경우가 있다.

 

Multi Slave 환경에서 미약하지만 복제 Crash 가능성이 존재한다.

MHA (Master High Availability)

  • Perl 기반의 Auto Failover Opensouce
  • Agentless 방식

MHA 구조

 

 

하나의 마스터와

Slave 구조로 이루어져

있다.

 

모두 단방향 복제로 이루어져있다.

 

 

 

MHA FAILOVER 후속처리

마스터 DB가 장애가 나는 경우 더이상 마스터 DB는 정상적인 데이터를 갖을 수 없다고 판단하여 마스터와 기존 Slave와의 복제를 끊는다.

나머지 DB들로 복제를 재구성한다.

 

마스터 DB가 정성작동을 한 이후에도 작업을 완전히 끊었기 때문에 복제를 재구성해주는 작업이 필요하다.

 

FAILOVER대상

MHA의 FAILOVER대상은 MMM과 다르게 기본적으로 고정되어있지 않다.

 

  • 기준 : 가장 최신의 데이터를 가지고 있는 DB를 마스터로 승격시킨다.

 

위에 언급하였던 MMM의 복제 Crush 현상을 방지하기 위해서 별도의 절차를 거친다.

 

  • 복제를 구성하는 대상 : 바이너리 로그, 릴레이 로그 파일

해당 파일을 가져와서 차이나는 데이터를 추출 한다.

만약에 Slave1 에 101이라는 데이터가 유실되었다면 바이너리 릴레이 로그 파일과 비교하여 101을 추출하여 Slave1 에 101을 저장하게 된다.


References

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

 

[2018] MySQL 이중화 진화기

24시간 365일 서비스를 위한 MySQL DB 이중화. MySQL 이중화 방안들에 대해 알아보고 운영하면서 겪은 고민들을 이야기해 봅니다. 목차 1. DB 이중화 필요성 2. 이중화 방안 - HW 이중화 - MySQL Replication 이중화 3. 이중화 운영 장애 4. DNS와…

www.slideshare.net

 

'CS > DataBase' 카테고리의 다른 글

(MySQL) MySQL 스토리지 엔진 아키텍처 - InnoDB  (0) 2022.08.31
(MySQL) MySQL 아키텍처  (0) 2022.08.31
(MySQL) Transaction Isolation Levels  (0) 2020.03.29
(MySQL) Replication  (0) 2020.03.29
(MySQL) Direct I/O  (0) 2020.03.08