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
-
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 시그널을 보낸다. -
Multi Master Replication Manager (MMM)
- feature
① Perl 기반의 Auto Failover Open Source.
② MMM Monitor에서 DB서버 health check와 failover를 수행.
③ Monitor <-> Agent 통신방식.
Master(Active)와Master(Standby)는 양방향으로 서로 복제가 가능하지만MMM Monitor에 의해Master(Standby)는 읽기모드로 제어된다. 이 구조에서slave가 추가되면 아래와 같이Master(Active)에서slave로 단방향으로 복제를 하는 구조가 만들어진다.
이런 상황에서 MMM Failover 과정은 아래의 3가지로 나눌 수 있다.
①Master(Active)에서 master의 역할을 뺏음.
과정: 읽기모드로 변경 ▶ 접속되어 있던 Session kill ▶ 신규 세션이 들어오지 않도록 VIP 회수
②Master(Standby)로 복제 재구성.
과정: 복제지연 확인 ▶Master(Standby)기준으로 복제 재구성. ▶Master(Standby)를 신규 master로 승격시키기 위해 읽기모드 해제 ▶ 신규 세션이 들어 올 수 있도록 VIP 할당.
③ Failover 완료.
후속처리로 만약Master(Active) A가 서버가 종료되는 등의 문제가 생기면Master(Standby) B가Master(Active) B로 승격되고, A 서버가 다시 시작되면Master(Standby) A로 지정될 수 있다.
이런 과정에 의해 문제가 생기더라도 지속 & 보완적으로 failover가 발생할 수 있다.
(처리하는데 오래 걸리는 query에 의해 서버가 종료되거나, 하이퍼바이저에 의해 mysql이 내렸다가 올라올 수도 있음.)
하지만MMM의 Multi Slave 환경에서도 데이터가 유실될 수 있는 상황이 존재한다.
①Master(Active)에서Master(Standby)와Slave로 쿼리를 전달.
②Master(Standby)에서는 예상치 못한 오류로 쿼리 실행 X,Slave에서는 쿼리 실행 O.
③Slave에서 쿼리가 실행되었으므로, ACK 전달
④ ACK를 받은Master(Active)는 client에게 ACK 시그널 전달.
⑤ 갑작스레Master(Active)서버 종료.
⑥Master(Standby)가 신규 마스터로 승격.
⑦ 데이터 유실 발생!!
그 대안으로MHA가 제안되었다. -
MHA(Master High Availability)
MHA와MMM의 차이는 아래와 같다.
①MHA는MMM과 다르게Master에서Slave로의 단방향 복제만 허용한다.
② Failover시, 신규Master를Master(Standby)로 고정 선택하는 것이 아닌 가장 최신의 데이터가 동기화된 상태의Master(Standby)또는Slave를 선택한다.
③ 그리고,MHA Monitor가Master의Binary Log와Slave들의Relay Log를 확인하여 DB 간의 차이나는 쿼리를 DB에 반영해준다. 이 작업을 통해 DB 간의 일관성을 보장해줄 수 있다.
④ 또한, Failover의 후속처리로 다시 살아난Master A에 대해 현재 운영중인Master B,Slave C와의 관계를 자동으로 만들어주지 않기 때문에, 복제를 재구성해주는 작업을 별도로 해주어야 한다.
3. 이중화 운영 장애와 대안
장애 1) 네트워크 문제로 MMM Monitor에서 Master 서버 접속 불가
DB 서버의 문제가 아니었음에도, MMM Monitor는 Master(Active)가 장애가 난 것으로 판단하고 Failover 절차를 밟음.
과정: Master(Active) 읽기모드 ▶ Session kill ▶ Master(Acive) VIP 제거 ▶ Slave를 New Master로 복제 재구성 시작 ▶ New Master의 읽기모드 해제 ▶ New Master에 VIP 할당.
최종적으로 New Master에 접속이 되지 않아서 VIP가 유실되는 상황.
대안 1) MHA - Secondary check
사용하고 있는 DB서버와는 다른 네트워크에 서버를 지정하고 그 서버를 Secondary Host라 지정. Secondary Host는 네트워크 문제인지, DB 문제인지 한번 더 체크하는 용도로 쓰임.
이중화와 관련된 자료는 더욱 많겠지만, 개발자로써 참고할 수 있는 정도의 내용만 정리하였습니다.
해당 글 작성에 참고한 링크
