[TWIL] MariaDB - MHA 이중화를 알아보자
이번에 MHA 이중화 환경에서 사용하는 기능을 개발했는데, 이 참에 MHA에 대해 알아보고자 합니다.
MHA는 MySQL의 대표적인 HA(High Availability) 솔루션 중 하나로, 일본의 MySQL 엔지니어 Yoshinori Matsunobu가 개발한 오픈소스 프로젝트입니다. 현재는 업데이트가 중단되었지만, 여전히 많은 기업에서 안정적인 HA 구축을 위해 사용하고 있습니다.
#1. MHA 이중화 왜 사용할까?
만약 서비스 운영중에 DB로 인해 서비스 장애가 발생한다면 어떻게 될까요?
1. DB가 Single인 경우 :
서비스 장애 시간 = DB 서버를 복구하는데 걸리는 시간
2. 복제해둔 DB가 있는 경우 :
서비스 장애 시간 = 수동으로 복제해둔 DB를 Master로 승격하고, 커넥션 변경 후 재배포하는 시간
3. MHA를 사용하는 경우 :
서비스 장애 시간 = 사용자의 개입 없이 자동으로 Failover되며, Master로 승격하기 까지 걸리는 시간
( 약 10~30초. 실제로는 더 빠르다 )
이렇게 Master DB의 장애가 발생했을 때 자동으로 Failover를 수행해서 DB 다운타임을 최소화 할 수 있기 때문에
HA(High Availability, 고가용성)도구들이 사용됩니다.
MariaDB HA도구로는 MHA 이외에도 MMM, Galera, MaxScale 등이 있는데요.
그 중 특히 MHA를 사용하면 기존 구조의 변형 없이(운영 환경 상의 설정 변경 없이) 각 노드에 MHA 툴만 설치하면 최소한의 비용으로 자동 Failover를 할 수 있다는 장점이 있습니다.
#2. MHA 구성
MySQL Replication 환경에서 MHA Manager, Master, Slave 서버 총 3개가 기본 구성이고, 상황에 따라 Active, StanBy로 사용한다고 해요. (이 경우 1Master, 2Slave)
즉 MHA는 이미 구성된 Replication을 관리하고 Failover를 자동화하는 역할인거죠.
MHA 설치전에 Master-Slave 설정이 먼저 되어있어야 합니다.
1️⃣ MHA Manager (관리자 노드)
- 역할: Master 장애 감지 및 자동 Failover 수행
- 설치 위치: 일반적으로 별도의 독립적인 서버이지만, Slave 노드에 설치해도 무방함
MHA Manager의 주요 기능
- Master 장애 감지 및 Slave 중 하나를 새로운 Master로 승격
- Slave들을 새로운 Master에 맞게 자동으로 Replication 재구성
- 기존 Master의 binlog를 수집하여 데이터 유실 최소화
2️⃣ MHA Node (각 DB 서버에 설치되는 에이전트)
- 역할: 개별 MySQL 서버에서 장애 복구 작업 수행
- 설치 위치: 모든 MySQL 서버 (Master 및 Slave)
MHA Node의 주요 기능
1. Master 장애 발생 시 binlog 수집 및 반영
2, Slave 재구성 :
Master의 장애로 새로운 Master 가 승격되면, 기존 Slave 들은 새로운 Master를 따라가도록 다시 Replication을 구성해야 합니다. 이 과정을 MHA Node가 자동으로 수행합니다.
(MHA Node가 각 Slave 서버에서 CHANGE MASTER TO 명령을 실행하여 새로운 Master를 따르도록 설정)
STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='new_master_ip', MASTER_USER='replication_user', MASTER_PASSWORD='password';
START SLAVE;
3. Failover 과정에서 비정상적인 노드를 감지하고 보고 :
MHA Node는 Master 장애 감지와 Failover 시 문제가 있는 Slave들을 식별하고 보고하는 역할을 수행합니다
#3. Master 장애 판단 기준
MHA Manager가 3초마다 마스터 DB를 CONNECT / SELECET / INSERT 체크하며 정해진 실패 횟수 초과시 장애로 인식하고 Failover를 수행합니다
#4. Failover 과정
장애 감지 → 최신 로그 확보 → 새로운 Master 승격 → Replication 재구성
1. MHA Manager가 Master DB의 장애를 감지하여 Slave 서버들의 상태를 확인하고 Failover를 시작
2. 장애가 발생한 Master의 binlog를 복구할 수 있으면 확보함. Master 서버가 완전히 죽은 경우 이 단계는 skip
3. Slave DB 중 가장 최신의 Slave DB를 선택하여 Master DB로 승격( GTID 또는 Slave의 relayLog 확인)
4. Master(이전에 Slave였던 것)를 relay log로 데이터 복구를 수행
5. 살아있는 기존의 다른 Slave들은 새로운 Master를 따르도록 Replication 재구성
6. 로그 및 상태 점검 후 정상 운영 상태로 복귀합니다.
#참고. MariaDB Replication
MariaDB Replication은 비동기 방식으로 Master의 데이터를 Slave로 복사합니다. 이렇게 데이터를 복사해두면 장애 발생 시 Slave 서버를 활용할 수 있겠죠. 이는 서버 부하 분산시에도 활용이 가능합니다.
다만, Master와 Slave가 항상 동일한 데이터를 실시간으로 가지고 있다고 볼 수 없습니다.
또한 Master -> Slave 이렇게 한 방향으로만 복제가 이루어지기 때문에, Slave 서버의 데이터만 변경하면 Master에는 반영되지 않습니다. 따라서 주로 Master 는 READ/WRITE, Slave는 READ-ONLY로 운영합니다.
실제 동작은 바이너리 로그와 릴레이 로그를 통해 이루어지게 됩니다.
1. Master에 Session 스레드(클라이언트와 DB간 연결)를 통해 데이터 변경 요청을 받으면, 자신의 DB와 바이너리 로그에 저장
2. Slave가 복제하고자 하는 내용을 요청하면, Dump 스레드가 Binary Log 내용을 READ
3.Dump스레드는 읽은 내용을 Slave의 I/O 스레드에게 전달
4.Slave의 I/O 스레드는 전달받은 내용을 Relay Log에 저장
5.Slave의 SQL 스레드는 Relay Log를 읽어서 자신의 DB에 저장
*Binary Log : Master에서 데이터 변경(INSERT,UPDATE,DELETE 등)이 발생할 때 기록되는 로그
*Relay Log : Master의 Binlog를 읽어서 Slave가 중간 저장하는 공간. Failover 시 가장 최신 Relay Log를 가진 Slave가 새로운 Master로 채택됨.
*Dump thread : Master가 Slave로 Binlog를 전달하는 역할