What? 무엇을 진행하나요?
[2018] MySQL 이중화 진화기 영상을 시청 후, 내용을 정리합니다.
Why? DB를 이중화하나요?
DB가 Single일 경우, DB에 장애가 발생하면 대체할 장비가 없습니다.
DB 서버 복구 시간 = 장애 시간
이를 해결하기 위해 DB를 이중화 합니다.
How? 어떻게 DB를 이중화하나요?
- 별도의 물리 IP를 가진 Slave DB를 만듭니다.
하지만 여전히 배포 시간이 많이 소요된다는 문제가 남아있습니다.- Master DB 앞에 가상의 IP인 VIP를 추가합니다.
DB에 접근 시, 물리 IP가 아닌, VIP를 통해 접근하게 합니다.
HW 이중화란?
- Shared Disk
- 하나의 디스크를 공유하는 방식입니다.
- Master Stand by는 Master Active에 장애 발생 시,
failover 용도로만 사용합니다.
Shared Disk의 문제점- RHCS 솔루션 구매가 필요합니다.
- 고비용의 Shared Disk가 필요합니다.
- DISK 복제 방식
- 실제 하드웨어에서 많이 사용하는 방식입니다.
- 별도의 라이센스와 고성능의 디스크 없이도 구성이 가능합니다.
- 오픈소스로 구성이 가능합니다.
DISK 복제 방식의 문제점- Network Latency에 영향을 받습니다.
HW 이중화의 문제점
- Stand By 서버의 경우 failover시에만 사용이 가능합니다.
- 백업을 위한 추가 서버가 필요합니다.
- 유지 보수 및 장애 대응이 어렵습니다.(OS와 하드웨어에 대한 지식이 필요합니다.)
-> 이러한 이유들 때문에 MySQL Replication을 주로 이용합니다.
MySQL Replication이란?
다음의 일련의 과정을 거치는 것을 MySQL Replication이라 칭합니다.
- 클라이언트에서 쿼리 실행 시, 데이터가 변경되는 명령어의 경우,
binary log라는 파일 로그에 기록되고 Master DB에서 실행이 됩니다.- Slave DB에서 binary log를 감시하다가 새로운 명령어가 생기면 relay log로 가져옵니다.
- Master인 binary log와 Slave의 relay log를 통해 복제를 실시합니다.
MySQL Replication 일관성 보장
다음의 일련의 과정을 거쳐서 MySQL Replication 일관성을 보장합니다.
- Slave에서는 binary log를 감시하다가 새로운 명령어가 생기면 relay log로 가져옵니다.
- Master의 binary log와 Slave의 relay log를 통해 복제를 실시합니다.
- Master의 변경사항이 Slave의 relay log에 작성됨을 보장합니다.
Multi-Slave 환경에서도 일관성을 보장해야 합니다.- 하나의 Slave에서라도 응답을 받게 되면, 클라이언트에게 완료를 리턴합니다.
MySQL Replication 이중화
1. MMM 구조
Master Standby는 쓰기가 불가능한 읽기 모드 상태입니다.
Failover
Master Active
- 현재 Master의 역할을 뺏고, 읽기 모드로 변환시킵니다.
- Master에 연결된 모든 세션들을 kill합니다.
- VIP를 회수합니다.
Master Standby
- 복제 지연을 확인합니다.
- Master Standby를 신규 Master로 승격시킵니다.
- 읽기 모드를 해제합니다.
- VIP를 할당합니다.
2. MHA 구조
- MMM과 달리, 가장 최신 동기화 상태의 Slave를 선택하여 신규 Master로 승격시킵니다.
-> DB의 복제 일관성을 보장해 줍니다.
VIP vs DNS
- VIP 이중화 제약을 해결하기 위해 DNS를 사용합니다.
- DNS의 도메인 IP를 변경함으로써 다른 네트워크 간에 이중화가 가능합니다.
- 하지만 다음과 같은 단점도 존재합니다.
