MySQL 이중화 진화기

망7H·2021년 3월 31일
1
post-custom-banner

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가 들어오게 되면 해당 정보를 slaverelay log로 가져오기 위해, master에게 새로운 query를 요청한다.
    masterslave의 요청을 받아 binary log에 적힌 쿼리를 slave로 전달하면서 전달 되었다는 것을 보장받기 위해 응답을 기다린다.
    slavemaster로부터 새로운 query를 잘 받았다는 응답(ACK)을 보내고
    masterslave로부터 ACK를 받으면 client에게 OK 시그널을 보낸다.
    이렇게 master의 변경사항이 slaverelay log에 작성됨을 보장한다.
    ⑧ 그리고 slave의 mysql에서 query를 실행함으로써 master에 적용된 데이터가 slave에도 적용되게 된다.

  • Single Master & Multi Slave
    1:1 복제구성과 마찬가지로 slaverelay log에서는 masterbinary 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) BMaster(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)
    MHAMMM의 차이는 아래와 같다.
    MHAMMM과 다르게 Master에서 Slave로의 단방향 복제만 허용한다.
    ② Failover시, 신규 MasterMaster(Standby)로 고정 선택하는 것이 아닌 가장 최신의 데이터가 동기화된 상태의 Master(Standby)또는 Slave를 선택한다.
    ③ 그리고, MHA MonitorMasterBinary LogSlave들의 Relay Log를 확인하여 DB 간의 차이나는 쿼리를 DB에 반영해준다. 이 작업을 통해 DB 간의 일관성을 보장해줄 수 있다.
    ④ 또한, Failover의 후속처리로 다시 살아난 Master A에 대해 현재 운영중인 Master B, Slave C와의 관계를 자동으로 만들어주지 않기 때문에, 복제를 재구성해주는 작업을 별도로 해주어야 한다.

3. 이중화 운영 장애와 대안

장애 1) 네트워크 문제로 MMM Monitor에서 Master 서버 접속 불가

DB 서버의 문제가 아니었음에도, MMM MonitorMaster(Active)가 장애가 난 것으로 판단하고 Failover 절차를 밟음.
과정: Master(Active) 읽기모드 ▶ Session kill ▶ Master(Acive) VIP 제거 ▶ SlaveNew Master로 복제 재구성 시작 ▶ New Master의 읽기모드 해제 ▶ New Master에 VIP 할당.
최종적으로 New Master에 접속이 되지 않아서 VIP가 유실되는 상황.

대안 1) MHA - Secondary check

사용하고 있는 DB서버와는 다른 네트워크에 서버를 지정하고 그 서버를 Secondary Host라 지정. Secondary Host는 네트워크 문제인지, DB 문제인지 한번 더 체크하는 용도로 쓰임.




이중화와 관련된 자료는 더욱 많겠지만, 개발자로써 참고할 수 있는 정도의 내용만 정리하였습니다.

해당 글 작성에 참고한 링크

https://www.youtube.com/watch?v=dCVKAJ7tb70&list=RDCMUC982FhzZx87lIWCimFiry_w&start_radio=1&rv=dCVKAJ7tb70&t=41

profile
망한 개발자의 개발 기록입니다. 저를 타산지석으로 삼으시고 공부하세요.
post-custom-banner

0개의 댓글