728x90

SMALL

DB 이중화

1. DB 이중화의 필요성

1) 1대의 DB 서버만을 사용하는 경우

장애 시간 = db 서버 복구 시간.

2) 2대의 DB 서버를 사용하는 경우 (이중화 X)

이중화하지 않은 상태로 각각 db 서버를 아래와 같이 2대를 동작시킨다.
master ip: 192.168.0.100
slave ip: 192.168.0.200
이때, master가 문제가 생기면 slave를 바라보도록 관련자들이 작업을 하면 된다.
장애 시간 = 접근 db 서버 ip만 변경하는데 걸리는 시간.

3) 2대의 DB 서버를 사용하는 경우 (이중화 X)

이제 virtual ip (가상 아이피, 이하 vip)를 사용하여 db 서버 2대를 지정하여 본다.
master vip: 192.168.0.300
slave vip: 192.168.0.300
master에 붙어있던 connection들은 서버의 reconnect 로직에 의해 동일한 vip를 가지는 slave에 connection이 붙게된다.
장애 시간 = 장애 발생 후 서버의 reconnect 완료에 걸리는 시간.

위와 같은 3가지 케이스는 장애시간을 점점 줄이는 방안으로 설계되었지만, 최종적으로 DB 복제 구성 & VIP & 자동화를 함으로써 장애 시간을 더욱 더 줄일 수 있다.
여기서의 자동화의 예시로, 장애가 발생한 경우 failover(커넥션 관리 및 VIP 변경)등을 예로들 수 있다.

2. 이중화 방안

1) HW(Hardware)의 이중화

Master(Standby)는 평상시에는 사용하지 않다가, Master(Active)를 failover 하는 용도로만 사용하게 된다.

단점
RHCS 솔루션 구매 필요 ex) OS Cluster.
고비용의 shared disk 필요

2) Disk 복제

DRBD + Corosync + Pacemaker로 구성

별도의 license나 고성능 disk 없이 사용이 가능하다. 평상시에 Master(Active)쪽의 데이터를 네트워크를 통해 Master(Standby)에 복제한다.

단점
네트워크 latency(지연 시간)에 영향을 받는다.

위 2가지 방식은 모두 Master(standby) 서버의 경우 failover 시에만 사용이 가능하다는 것과 백업을 위한 추가 서버가 필요하다는 단점이 있다.

3) MySQL Replication

기본적으로 동기(모두합의,다수합의),비동기,반동기(1곳이라도 합의) 복제 방식이 내부적으로 있다는것을 인지하자

기본 방식들

Single Master & Single Slave

① master에서 client가 query를 실행하면
② 데이터가 변경되는 insert, upda te, delete의 경우 binary log라는 파일에 기록이 되고
③ mysql에서 query가 실행된다.
④ slave에서는 binary log를 감시하다가, 새로운 query가 들어오게 되면 해당 정보를 slave의 relay log로 가져오기 위해, master에게 새로운 query를 요청한다.
⑤ master는 slave의 요청을 받아 binary log에 적힌 쿼리를 slave로 전달하면서 전달 되었다는 것을 보장받기 위해 응답을 기다린다.
⑥ slave는 master로부터 새로운 query를 잘 받았다는 응답(ACK)을 보내고
⑦ master는 slave로부터 ACK를 받으면 client에게 OK 시그널을 보낸다.
이렇게 master의 변경사항이 slave의 relay log에 작성됨을 보장한다.
⑧ 그리고 slave의 mysql에서 query를 실행함으로써 master에 적용된 데이터가 slave에도 적용되게 된다.

Single Master & Multi Slave
1:1 복제구성과 마찬가지로 slave의 relay log에서는 master의 binary log를 감시하고 query를 요청한다. 그 후 master는 응답(ACK)를 기다리는데, 이때 master는 하나의 slave에서라도 응답(ACK)를 받게 되면 client에게 OK 시그널을 보낸다.

구체적인 이중화 방법들

MMM(Multi - Master Replication Manager)

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

기본 개념

MySQL에서 여러 master/slave 노드를 두고 가상 IP(VIP) + 에이전트를 이용해 자동 failover/리커버리를 지원하는
실제로는 Active Master (write) + Passive Master (대기용) 구조가 많음

복제 방식

MySQL의 비동기 복제(asynchronous replication) 기반
일반적으로 Master ↔ Master 간 이중 복제 설정 (circular replication)
추가적으로 Master → Slave 복제도 함께 운영 가능

장애 처리

Active Master 장애 → Passive Master를 VIP로 승격 (자동/수동)
슬레이브들은 새 Master를 바라보도록 자동 재설정
네트워크 split-brain(두 master가 동시에 write) 위험 존재

장점

간단한 HA 구성 가능 (VIP 전환)
Active-Passive 구조에서 빠른 장애 전환 가능
Slave를 붙여 read scale-out 가능

단점

개발/유지보수 중단(프로젝트 사실상 deprecated)
Split-brain 가능성 → 데이터 충돌 위험
Circular replication 구조의 복잡성 → 데이터 정합성 깨질 수 있음
요즘은 MHA나 Group Replication, ProxySQL 기반 HA로 대체되는 추세

MMM의 구조

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

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

MMM의 구조 - Slave 추가

Slave가 추가된다면 단방향 복제의 Slave가 하나씩 추가되는 구조, 이역시 Master(Active) 를 제외하고는 모두 읽기모드로 제어된다.

MMM FAILOVER 과정

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

읽기모드로 변경
세션 킬
VIP 회수

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

복제를 재구성하기 이전에 복제지연이 있는지 확인한다.

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

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

VIP를 할당한다.

FAILOVER 완료!

MMM FAILOVER의 후속처리

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

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가 등장, MHA는 처음부터 Single Master 구조를 전제로 설계되어 안전하게 운영 가능