(─━┘_└━─)/ 머리만1톤(Head1Ton)

MHA는 MySQL Replication의 Master 서버가 Failover가 되었을 때, 짧은 Downtime(약 10~30초) 이내에 Slave를 Master로 승격시켜 Failover를 자동화하는 Tool이다. 이를 통해 복잡한 설치과정 없이 복제 일관성을 유지하고, 많은 비용을 들이지 않고 성능문제를 해결하며 구조를 변경할 필요가 없게 된다.

• 자동화된 Master 모니티렁 및 Failover
  • MySQL Replication의 Master 서버를 모니터링하고, Master 서버의 동작을 감시하여 자동으로 Failover를 수행한다
  • 비록 몇몇 Slave 서버가 최근의 Relay Log 이벤트를 받지 못하더라도, MHA는 가장 최근의 Slave서버와 비교해 Relay Log 차이점을 감지하고, 뒤쳐진 Relay Log를 가진 Slave에 이를 적용함으로써 데이터 일관성을 유지할 수 있다.
  • 설정 파일에 우선순위를 설정하여 특정 Slave를 Master 후보로 지정할 수 있다. MHA는 Slave간의 일관성 문제를 해결하기 때문에 특정 Slave를 Master로 승격시킨다 하더라도 일관성 문제에서 자유로울 수 있다
  • Master Failure 감지 시간 : 9~12초
    Split Brain을 피하기 위한 Master 장비 Power Off 시간(옵션) : 7~10초
    새로운 Master에 최신 Relay Log를 적용하는데 걸리는 시간 : 몇 초…
    총 Downtime 시간 : 10~30초
• 대화형(수동) Master Failover
  • MHA를 모니터링 기능 없이 대화형 Failover용으로만 사용할 수 있다.
• 비대화형 Master Failover
  • 모니터링은 사용하지 않고, 자동화된 Master Failover를 지원한다. MySQL Master 서버를 모니터링하는 SW를 이미 사용하고 있을 경우 유용하다.
• 온라인 Master 서버 변경
  • Master 서버의 Failover용이 아닌 하드웨어 교체등으로 인해 Master 서버를 다른 Host로 변경하려 할 때 유용하다.
  • MHA는 0.5~2초 이내의 Writer Block 시간만으로 Master 서버를 변경할 수 있다. 0.5~2초 이내의 Downtime 시간이 허용된다면 이 툴을 이용해 좀 더 쉽게 높은 버전의 MySQL로 업그레이드 하거나 장비를 교체할 수 있다.

       

• Master Failover에 따른 Slave의 승격이 매우 빠르게 이루어진다
  • DeNA의 경우 150대 이상의 Master/Slave 환경에서 MHA를 사용하고 있다. Master에 장애가 났을 경우, 약 4초만에 Failover가 가능했다. 이는 전통적인 Active/Passive 클러스터링 솔루션에서는 불가능했다
• Master의 Failover가 데이터 일관성에 영향을 미치지 않는다
  • Master 서버가 다운되어도 MHA는 자동으로 Slave 간의 Relay Log 이벤트의 차이를 감지하여 동기화한다.
  • Semi-Synchronous Replication을 함께 사용하면 데이터 손실이 일어나지 않게 할 수 있다
• 구축되어 있는 MySQL 서버 세팅의 변경이 필요 없다
  • MHA는 이전의 MySQL 5.0 이상의 Replication 환경에서 MySQL 설정 변경 없이 동작 가능하다.
  • MHA 버전을 업그레이드 할 경우에도 MySQL 서버를 중단시킬 필요가 없다
  • MHA는 MySQL 5.0 이상(5.0 / 5.1 / 5.5 / 5.6)에서 동작하기 때문에 Migration 할 필요가 없다
• 많은 서버를 증설할 필요가 없다
  • MHA는 MHA Manager와 MHA Node로 구성되어 있다
  • MHA Node는 MySQL 서버에서 동작하고, 관리를 위해 하나 이상(HA를 위해)의 MHA Manager 서버가 필요하다. 하나의 MHA Manager 서버는 많은 MySQL 서버를 모니터링 할 수 있기 때문에 추가적으로 많은 서버가 필요하지 않다
• 성능에 대한 불이익이 없다
  • MHA는 Master 서버로 N초마다 Ping 패킷만을 전송하기 때문에 성능에 큰 무리가 없다
• 모든 스토리지 엔진에서 동작한다

• MHA Toolkit
• 
• 
  
  • Manager
    • Master_monitor : Master 서버 장애 감지
    • Master_switch : Failover 수행(Masterha_manager를 불러와 자동/수동으로 Failover 수행)
  • Node : 모든 MySQL 서버에 배치한다
    • Save_binary_logs : 접근이 가능하다면, Master 서버의 바이너리 로그를 복사
    • Apply_diff_relay_logs : 가장 최근 정보를 가진 Slave 서버로 부터 Relay Log의 차이를 생성하고, 모든 binlog 이벤트와 다른점을 적용한다
    • Filter_mysqlbinlog : 불필요한 ROLLBACK 이벤트를 잘라낸다
    • Purge_relay_logs : SQL Thread 중단 없이 Relay Log를 삭제
• 데이터 센터의 경우
• 
• 
  
  • 각 Manager는 같은 데이터센터 내의 많은 Master 서버를 모니터링 한다
  • DC1의 Manager가 DC2, DC3의 Master와 연결되어 있을 경우, 만약 한 Master 서버가 어떠한 Manager로 연결할 수 없을 때, Master Failover 프로시저가 시작한다.
    (Split Brain을 방지하기 위함)
  • 만약 데이터센터가 붕괴되는 등의 큰 장애가 발생하면, 수동으로 Failover를 수행해야 한다
• 복구 프로시저
• 
• 
  
• 복구 단계
• 
• 
  
  • Slave(i)에서 먼저 SQL Thread가 이벤트를 실행할 때까지 기다린 후, (i1) -> (i2) -> (x) 순으로 적용한다. (단, 가장 최근 정보를 가진 Slave의 경우 (i2)과정 생략)

     

• 부분적 트랜잭션
• 
• 
  
  • 동작중인 Slave 서버의 IO Thread는 유효한 Relay Log 이벤트를 기록한다. 그래서 유효하지 않은(읽을 수 없는) 이벤트는 Relay Log로부터 읽을 수 없다.
  • 그러나 바이너리 로그를 전송하는 도중에 Master 서버에 장애가 발생할 경우, 일부 이벤트만 보내진 후, Slave에서 읽어질 수도 있다
  • 이러한 경우 Slave는 잘려진 마지막 트랜잭션을 실행하지 않는다
  • "Master_Log_File, Read_Master_Log_Pos"는 Relay Log의 마지막 부분을 가리키지만 "Relay_Master_Log_File, Exec_Master_Log_Pos"는 마지막으로 Commit된 트랜잭션을 가리키기 때문이다
• 누락된 트랜잭션
• 
• 
  
  • 때때로(예를 들어 매우 긴 트랜잭션이 실행되었을 때) Relay Log는 트랜잭션이 Commit이 되지 않은 상태로 끝나버릴 때가 있다
  • "Read_Master_Log_Pos"는 항상 Relay Log의 맨 마지막 "end_log_pos"를 가리킨다
  • "Exec_Master_Log_Pos"는 트랜잭션의 "end_log_pos"의 맨 마지막(COMMIT 된 부분)을 가리킨다
  • 위의 예제에선 Exec_Master_Log_Pos != Read_Master_Log_Pos 이다. 따라서 Slave1의 SQL Thread는 "BEGIN 과 UPDATE문"을 실행하지 않을 것이다.
  • 적용되지 않은 이벤트는 "mysqlbinlog --start-position=91835" 명령어를 통해 적용할 수 있다.
• 누락된 트랜잭션 복구
• 
• 
  
  • Slave1에서 "update 2….." 이벤트는 누락되었다. 또한 Slave1의 SQL Thread는 "update 1….." 이벤트를 실행하지 않는다
  • 동일한 트랜잭션 내에서 (A) + (B)가 Slave 1에서 적용되어야 한다

       

• 가장 최신의 Slave 서버 구분
• 
• 
  
  • 가장 최신의 Slave를 구분하는데 있어 Relay Log 이름/위치는 각 Slave 서버마다 독립적이기 때문에 그다지 도움이 되지 않는다.
  • "Master_Log_File, Read_Master_Log_Pos"를 비교함으로써 가장 최신의 Slave 서버를 찾을 수 있다. (여기선 Slave2가 가장 최신 정보를 갖고 있다)
  • 모든 Slave 서버의 Master Position을 알고 있으며 비교할 수 있기 때문에 Relay Log 이벤트의 차이점을 생성하는 것은 가능하다.
• Relay Log 보는 방법
• 
• 
  
• Slave 서버간 Relay Log 이벤트 차이점 파악        
• 
• 
  
  • 현재 Slave2는 Slave3보다 더 많은 binlog 이벤트를 받았다
  • Binlog 이벤트 수신에 뒤쳐진 Slave 서버의 "end_log_pos"를 체크한다
    (위의 Slave3의 end_log_pos는 '101719'이다)
  • 가장 최근의 Slave 서버(Slave2)의 Relay Log에서 "end_log_pos=101719'를 찾는다
  • 이를 통해 Slave3에서 누락된 Relay Log Position이 '101835'부터 임을 알 수 있다
  • Slave3에서 "mysqlbinlog --start-position=101835"를 수행하여 데이터를 동기화한다

       

• 장애가 발생한 Master 서버에서 Binlog 이벤트 저장
• 
• 
  
  • 장애가 발생한 Master에 SSH 등을 통해 접속할 수 있고, 바이너리 로그에 접근할 수 있다면, binlog 이벤트를 저장할 수 있다
  • 잃어버린 이벤트는 가장 최신의 Slave 서버에서의 "show slave status" 명령어와 mysqlbinlog를 체크하여 알 수 있다. (Master_Log_File, Read_Master_Log_Pos)
  • 
  • 
    
  • Semi-Synchronous 복제를 사용하면 이벤트 손실에 대한 위험을 줄일 수 있다

       

• MySQL 5.6에 포함된 GTID를 지원한다. GTID와 Auto Position이 활성화되면 MHA는 이전의 Relay Log 기반 Failover가 아닌 GTID SQL Syntax를 이용해 Failover를 자동적으로 수행한다. GTID 기반 Failover를 사용함으로써 더 이상 설정 충돌이 일어나지 않을 것이다.
• MySQL 5.6 멀티 쓰레드 Slave 지원
• MySQL 5.6 바이너리 로그 체크섬 지원
• [binlogN] 이란 새로운 섹션이 생겨 "mysqlbinlog streaming servers"를 지정할 수 있다. 
  MHA가 GTID 기반 Failover를 수행할 경우, MHA는 binlog 서버를 체크하고, 만약 binlog 서버가 다른 Slave 서버보다 앞선다면, MHA는 복구하기 전에 새로운 Master 서버에게 binlog 서버로부터 가져온 binlog 이벤트를 적용한다.
  MHA가 Relay Log 기반 Failover를 수행할 경우엔 binlog 서버를 무시한다. 자세한 사항은 공식 Documetation을 확인하라.
• Custom mysql과 mysqlbinlog Location 지원
• Master의 연결을 체크하기 위해 "ping_type=INSERT"가 추가되었다. 만약 디스크 에러 등으로 인해 Master 서버에서 쓰기를 수행할 수 없을 경우 유용하다.
• Master_ip_online_change_script를 위해 "--orig_master_is_new_slave, --orig_master_ssh_user, --new_master_ssh_user"가 추가되었다
• "--skip_change_master,  --skip_disable_read_only, --wait_until_gtid_in_sync on masterha_manager and masterha_master_switch (failover mode)" 가 추가되었다

• 3-Tier 이상의 Replication은 지원하지 않는다. ( ex> Master -> Master2 -> Slave)
• SBR기반 "LOAD DATA [LOCAL] INFILE"은 지원하지 않는다
• 모든 MySQL 서버에서 복제 필터링 룰(binlog-do-db, replicate-ignore-db 등)은 동일해야 한다
• MySQL 5.0.45 이하 버전에선 동작하지 않는다

• 설정 파일
  • "Application Configuration File"과 "Global Configuration File"이 필요하다
  • Command 실행시 "--conf" 옵션과 "--global_conf" 옵션을 이용해 설정파일을 지정할 수 있다
  • https://code.google.com/p/mysql-master-ha/wiki/Configuration
• 주요 Command
  • Masterha_manager : Master 서버를 모니터링 하고, 다운되었을 경우 자동으로 Failover 수행
  • Masterha_master_switch :
  • Masterha_check_status : Manager가 MySQL Master 서버를 제대로 모니터링 하는지 검사
  • Masterha_check_repl : 설정 파일에 정의된 MySQL 서버들의 복제 상태를 체크
  • Masterha_stop : MHA Manager를 중지
  • Masterha_conf_host : 설정 파일에 Host 추가/삭제를 도와주는 Script
  • Masterha_ssh_check : SSH 설정을 체크
  • Purge_relay_logs : Replication Delay를 발생시키지 않으면서 오래된 Relay Log를 삭제

• 기존 Master 서버에 장애가 났을 때, Slave 서버의 상태
• 
• 
  
• 장애가 발생하기 전에 Masterha_manager를 실행시켰고, 다음과 같이 Failover가 진행된다
• 
• 
  
• 로그 파일 내 Failover Report ==> Master(192.168.0.20)가 Failover 되어 새로운 Master(192.168.0.30)로 Master 서버를 변경한 것을 알 수 있다
• 
• 
  
• MHA에 의해 Failover가 된 후의 Slave 서버 ==> Master_Host가 192.168.0.20에서 192.168.0.30으로 변경되었다
• 
• 
  

     

• ㅁ

• MHA4-MySQL-Manager-0.56.tar.gz

  <<mha4mysql-manager-0.56.tar.gz>>

• MHA4-MySQL-Node-0.56.tar.gz

  <<mha4mysql-node-0.56.tar.gz>>