장애 시간 = db 서버 복구 시간.
이중화하지 않은 상태로 각각 db 서버를 아래와 같이 2대를 동작시킨다.
master
ip: 192.168.0.100
slave
ip: 192.168.0.200
이때, master
가 문제가 생기면 slave
를 바라보도록 관련자들이 작업을 하면 된다.
장애 시간 = 접근 db 서버 ip만 변경하는데 걸리는 시간.
이제 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 변경)등을 예로들 수 있다.
Master(Standby)
는 평상시에는 사용하지 않다가, Master(Active)
를 failover 하는 용도로만 사용하게 된다.
DRBD + Corosync + Pacemaker
별도의 license나 고성능 disk 없이 사용이 가능하다. 평상시에 Master(Active)
쪽의 데이터를 네트워크를 통해 Master(Standby)
에 복제한다.
위 2가지 방식은 모두 Master(standby)
서버의 경우 failover 시에만 사용이 가능하다는 것과 백업을 위한 추가 서버가 필요하다는 단점이 있다.
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
와의 관계를 자동으로 만들어주지 않기 때문에, 복제를 재구성해주는 작업을 별도로 해주어야 한다.
DB 서버의 문제가 아니었음에도, MMM Monitor
는 Master(Active)
가 장애가 난 것으로 판단하고 Failover 절차를 밟음.
과정: Master(Active)
읽기모드 ▶ Session kill ▶ Master(Acive)
VIP 제거 ▶ Slave
를 New Master
로 복제 재구성 시작 ▶ New Master
의 읽기모드 해제 ▶ New Master
에 VIP 할당.
최종적으로 New Master
에 접속이 되지 않아서 VIP가 유실되는 상황.
사용하고 있는 DB서버와는 다른 네트워크에 서버를 지정하고 그 서버를 Secondary Host
라 지정. Secondary Host
는 네트워크 문제인지, DB 문제인지 한번 더 체크하는 용도로 쓰임.
이중화와 관련된 자료는 더욱 많겠지만, 개발자로써 참고할 수 있는 정도의 내용만 정리하였습니다.