[토스 SLASH 21] MYSQL HA & DR Topology

✅ 발표 영상

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

 

✔️ 발표 내용

MMM

HA 오픈소스 솔루션 이름

토스의 Live MySQL 데이터베이스 HA 솔루션으로 사용되고 있음

Google에서 개발된 솔루션

버전 업데이트는 중지되어서, 필요 시 자체 업데이트를 하면서 사용 중

 

 

기본 구성도

MASTER-MASTER 01, 02노드만 MMM이 관리하도록 구성

03번 SLAVE도 MMM이 관리하도록 포함시킬 수 있지만, 신규 MASTER로 failover 하는 과정에서 대응되지 않는 케이스가 있어서

이 구성은 사용하지 않음

 

 

1. 데몬 2개 : Monitoring, Agent 

 

 

2. 애플리케이션 서버 failover를 위해 각 데이터베이스 서버에 올라가는 서비스 IP

 

• Monitoring 데몬
  • 별도의 호스트에서 모든 모니터링 및 의사 결정과 명령 수행

 

• Agent 데몬
  • 각 데이터베이스 서버에서 실행됨
  • Monitoring 데몬에서 내려온 명령 수행 

 

 

Service IP

MMM이 데이터베이스 Role 변경에 따라 이동시켜 애플리케이션 서버의 failover가 이루어지게 함

 

 

mond가 하는 주요 모니터링 항목

• ping - 호스트 자체가 살아있는지
• mysql - MySQL 인스턴스가 살아있는지
• rep_threads - 복제 스레드가 정상 작동 중인지
• rep_backlog - 복제 스레드의 지연이 정해진 threshold를 넘어섰는지 확인

이 모니터링 항목에서 이상이 있을 시, MMM이 standby MASTER로 failover 진행

 

 

 

DR 처음 구성했을 때 모습

active : DATA-CENTER1

standby  : DATA-CENTER2

단방향 복제 구성 : DATA-CENTER 간, standby DATA-CENTER 내의 local MASTER 간

-> IDC failover 시 Role 전환 작업 필요..

 

 

BEFORE

신규 active DATA-CENTER의 MySQL 서버를 MASTER-MASTER 구성으로 전환해야 함

DATA-CENTER 간 MySQL 서버의 MASTER-SLAVE 관계도 전환해주어야 함

신규 standby DATA-CENTER의 MySQL 서버는 MASTER-SLAVE 단방향으로 전환해야 함

-> 어려운 작업은 아니지만 번거롭고 부담스러운 작업들 -> 개선 필요!

 

 

전환하게 된 배경

DR센터의 본 목적

재난 시 비즈니스 연속성 보장이므로

데이터 센터 failover를 할 경우가 거의 발생하지 않을 거라고 생각했지만

토스의 간편결제 파트너사 증가 -> 무중단 운영의 필요성 증가

 

이런 상황에서 대규모 네트워크 작업..

-> 무중단 데이터 센터 롤링 작업으로 계획이 됨

-> 데이터베이스 서버도 데이터 센터 failover가 필요해짐

-> 진행하다 보니 데이터베이스 Role 전환 작업에 대한 부담 증가 + 실수로 복제가 깨지는 경우도 발생 + 다운타임 필요 + 위험부담 큰 작업도 발생

-> 데이터 센터 전환 과정을 최대한 간소화시킬 필요가 생김

 

 

 

WISH

1. 양쪽 데이터센터 -> 대칭 구조

2. 데이터센터 failover 시, 애플리케이션 서버 커넥션만 이동하고

3. 데이터베이스 레벨에서는 따로 작업할 것이 없는 구조

 

MASTER-MASTER 양방향으로 바뀔 부분

1. 기존에 단방향으로 있던 DR 복제 채널

2. DR 센터 내에 MASTER-SLAVE 복재 채널

 

but,, 두 가지 이슈 발생

 

1. binlog 중복 전송 이슈

01, 02번 -> log_slave_update 옵션을 켜고 운영

sql_thread가 적용한 트랜잭션도 binlog에 기록하는 옵션

 

 

 

1. actvie 데이터센터 01번에서 발생한 트랜잭션의 binlog 생성

2. DR 채널을 따라 standby 데이터센터 01번으로 전송 및 적용됨

3. 적용 이후, standby 데이터센터 01번 서버 -> 이 트랜잭션에 대한 binlog 생성

 

 

4. 이때 01번의 slave로 있는 02, 03번 -> 이 binlog를 복제하고 적용하게 됨

단방향 구성 시 binlog 복제 흐름과 동일함

 

 

5. 그런데 02번에서 최종 적용한 binlog가 자체 binlog로 생성이 되고,

6. 01번은 02번의 master면서 slave이기 때문에, 이 binlog를 복제해야 하는지 판단함

이 판단 -> 해당 binlog가 처음 생성된 서버의 server-id와 자신의 server-id가 다른지 비교해서 이루어짐

다를 경우 복제 진행

 

이 binlog는 데이터센터1에서 처음 생성되었기 때문에 server-id 101을 계속 유지하고 있는 상황

server-id 1001인 01번으로 다시 복제가 되어버림

 

 

 

여기서 적용이 되면 다시 또 03, 02번으로 복제 되는 상황이 생길 수 있음..

 

실제 값 변경이 없었다면 binlog가 생성되지 않는데,

동일 binlog가 적용된 지 1초도 지나지 않은 상황이기 때문에

4번의 상황까지 나올 확률은 적지만

이론적으로는 무한 루프가 가능해져버림

 

 

2. MMM이 복제 채널을 구분하지 못하는 이슈

각 데이터센터의 01번 서버는 DR 양방향 복제 채널이 추가됨으로 인해서 

DR 복제 채널과 local master-master 복제 채널이 동시에 생성된 멀티소스복제 상태가 됨

 

이 경우 MMM은 자신이 모니터링 해야 할 채널이 어떤 채널인지 알지 못하게 됨

 

 

 

1. binlog 무한 루프

방법 1) Gtid로 중복 적용 막기

but,, 당시 바로 Gtid 전환은 어려운 상황

Gtid로 가더라도 binlog의 전송 루프 (No I0 Thread skip)은 발생하게 되고

다시 binlog position 방식으로 전환 시 이슈가 되기 때문에.. 중복 전송 자체를 막을 방법이 필요

 

방법 2) binlog filter 걸기

 

 

2. 어떤 채널?

MMM이 MM 채널에 대해서만 모니터링을 하도록 소스를 수정

 

 

현재 DR 구성 모습