DB

[MySQL] (고가용성3️⃣) MHA 구성 방법과 장애 복구 흐름 정리

인생아 2025. 7. 17. 14:12
반응형

MHA(MySQL Master High Availability)는 오픈소스로 제공되는
MySQL 장애 복구 전용 툴킷이다.
Master 노드에 장애가 발생하면, Slave 중 가장 최신 트랜잭션을 가진 노드를 자동 승격시키고
다른 Slave를 재구성하는 방식으로 무중단에 가까운 고가용성 구성을 실현할 수 있다.
구성은 다소 복잡하지만, 안정성과 실전 운용 경험이 풍부해 여전히 많이 쓰인다.

✅ MHA 구성 요소

  • Manager Node
    • MHA 구성 전체를 제어하는 컨트롤러 (별도 서버 or Slave 중 하나에 설치 가능)
  • Monitor Script
    • Master 서버 상태를 감시 (ping, replication status 등)
  • MySQL Master / Slaves
    • Master: 쓰기 전용 서버
    • Slaves: 복제 대상 서버, 장애 시 새로운 Master 후보
  • SSH 비밀번호 없는 로그인 설정
    • Manager → 각 MySQL 노드 간 SSH 인증 필요 (자동화 스크립트 실행을 위함)
반응형

🧠 MHA 동작 흐름 요약

  1. Manager가 주기적으로 Master 상태를 모니터링
  2. 장애 발생 시
    • 가장 최신 binlog를 가진 Slave를 Master로 승격
    • 다른 Slave들은 새로운 Master로 복제 재설정
  3. 복구 완료 후 전체 복제 구조 정상화

🛠️ 실습 기준 구성 예

  • Manager + Slave1 (동일 서버)
  • Master
  • Slave2

① 사전 준비

  • 각 노드에 동일한 MySQL 버전 설치
  • SSH 비밀번호 없이 접속 설정 (Manager → 각 노드)
ssh-keygen -t rsa
ssh-copy-id root@192.168.0.101

② MHA 패키지 설치

각 노드에 MHA Node 설치

yum install mha4mysql-node

Manager 서버에만 MHA Manager 설치

yum install mha4mysql-manager

③ 설정 파일 구성

/etc/mha/app1.cnf

[server default]
manager_workdir=/var/log/mha/app1
manager_log=/var/log/mha/app1/manager.log
user=mha
password=mhapass
ping_interval=5

[server1]
hostname=192.168.0.10
candidate_master=1

[server2]
hostname=192.168.0.11

[server3]
hostname=192.168.0.12
  • candidate_master=1 설정이 붙은 서버가 장애 시 승격 우선 대상
  • ping_interval: 장애 감지 주기 (초 단위)
반응형

④ 초기 테스트

masterha_check_ssh --conf=/etc/mha/app1.cnf
masterha_check_repl --conf=/etc/mha/app1.cnf

SSH 및 복제 구성에 문제가 없다면 정상 통과됨

⑤ MHA 시작

masterha_manager --conf=/etc/mha/app1.cnf

실시간으로 Master를 모니터링하며 장애 발생 시 자동으로 전환

🔄 장애 발생 시 복구 흐름

  1. 기존 Master와 연결 불가 판단
  2. 최신 트랜잭션 위치를 가진 Slave 탐색
  3. 해당 Slave를 Master로 자동 승격
  4. 나머지 Slave는 새 Master로 복제 설정 변경
  5. 관리자에게 이메일/로그 알림 전송 (메일 설정 가능)

복구는 일반적으로 10초 이내에 완료되며,
데이터 손실은 binlog 전송 지연 정도로 최소화된다.

⚠️ 실무 운영 시 주의사항

  • MHA는 GTID를 지원하지 않음 → POSITION 방식 사용
  • 모든 노드는 같은 시간대 설정 필수 (timezone, ntp)
  • 장애 복구 후에는 반드시 masterha_check_status로 상태 확인
  • binlog 전송 지연이 긴 경우 데이터 누락 가능성 있음 → semi-sync 병행 고려

📘 공식 문서 참고

https://github.com/yoshinorim/mha4mysql-manager

 

반응형