[MYSQL] MySQL 이중화 - DNS MMM

1. DB 이중화의 필요성

- DB single 구성일 경우, DB에서 장애가 발생할 경우 이를 대체할 장비가 존재하지 않는다.

- DB 복구 시간 = DB 장애 시간

- 이를 해결하기 위해 이중화를 진행한다.

 

2. DB 이중화 방법

2-1. HW 이중화

2-1-1. Shared Disk

- 하나의 디스크를 공유하는 방식

- Master(standby)는 Master(active) 장애 발생 시, failover 용도로만 사용한다.

- VIP를 standby에 할당해주는 방식

- RHCS 솔루션 라이센스 비용 등의 추가로 인한 고비용 단점 존재

 

2-1-2. DISK 복제 방식

- 오픈소스로 구성

- Active와 Standby는 하나의 디스크를 공유하지않고 각각의 디스크를 바라보고 있으며, 평상시엔 Active에 서버를 띄워 서비를 하게된다. 네트워크 통신을 통해 동기화하여 Standby가 같은 DB를 갖는다.

- 네트워크 통신 기반이므로 Network Latency에 영향을 받는다.

2-1-3.  HW 이중화의 단점

- Stand by 서버의 경우 FAILOVER시에만 사용 가능

- 백업을 위한 추가 서버가 필수

- 유지보수 및 장애 대응 어려움( OS 및 하드웨어에 대한 지식이 필요)

 

2-2. MySQL Replication

- HW 이중화의 단점으로 인해 MySQL Replication 방식을 많이 사용

- 2대 이상의 DBMS를 나눠서 데이터를 저장하는 비동기 방식의 복제 방법

- 복제 방식 

1. 클라이언트가 SQL 명령어 실행시, 먼저 Master 서버에 존재하는 Binary log에 변경사항 기록

2. Master Thread는 비동기적으로 Binary log를 읽어 Slave 서버로 전송

3. Slave의 I/O Thread는 Master로 부터 받은 변경 데이터들을 Relay log에 기록

4. Slave의 SQL Thread 는 Replay log의 기록들을 읽어 자신의 스토리지 엔진에 데이터 저장

2-2-1. MMM(Multi-Master Replicaction Manager)

- MMM monitor에서 DB 서버의 Health Check와 failover 수행

- Monitor <-> Agent 통신 방식

- failover 방식

1. 장애가 발생한 DB에 데이터 변경이 되지 않도록 읽기 모드 활성화

2. 장애가 발생한 DB에 접속 세션을 Kill

3. 장애가 발생한 DB에 접속이 되지 않도록 VIP 회수

4. 복제 지연 여부 확인 및 대기

5. Mater(standby)를 신규 마스터로 복제 재구성

6. 신규 마스터로 승격시키기 위해 Master(Standby) 읽기 모드 해제

7. 신규 마스터에 VIP 할당

8. Failover 완성

- failover 대상이 Master(Standby)로 고정

- Multi Slave 환경에서 복제 crash 가능성 존재 -> MHA을 사용하기도 함

3. VIP vs DNS

- Broad Cast 도메인 내에서만(L2영역) 구성 가능

- DNS의 도메인을 IP로 변경함으로써 다른 네트워크 간에 이중화 가능

- DNS는 UPDATE 방식으로 중복할당 / 유실가능성 없음

- DNS API 변경 호출, DNS caching으로 인해 지연 가능성 있음

 

 

 

# 참고자료

https://www.youtube.com/watch?v=dCVKAJ7tb70