MySQL은 오픈소스 관계형 DBMS로 정말 많이 사용하는 데이터베이스입니다.
현재 오라클이 소유하고 있고, 오라클 인수 이후 오픈소스 유지에 대한 불안함으로 나온게 MariaDB입니다.
데이터베이스는 그 성격상 고가용성(HA)이 매우 중요한데, 이를 유지하기 위한 다양한 방안 중에 MMM 구성과
이를 구성하기 위한 VIP 방식, DNS 방식을 비교해보겠습니다.
MySQL MMM (Multi - Master Replication Manager for MySQL)
공식 페이지 : https://mysql-mmm.org/start.html
Multi-Master Replication Manager for MySQL [MMM for MySQL Wiki]
Multi-Master Replication Manager for MySQL NOTE: By now there are a some good alternatives to MySQL-MMM. Maybe you want to check out Galera Cluster which is part of MariaDB Galera Cluster. MMM (Multi-Master Replication Manager for MySQL) is a set of flexib
mysql-mmm.org
MMM (Multi-Master Replication Manager for MySQL) is a set of flexible scripts to perform monitoring/failover and management of MySQL master-master replication configurations (with only one node writable at any time).
공식 페이지에서 "MMM은 MySQL의 Master와 Master Replication 구성들에 대한 관리, 성능 모니터링 및 failover를 위한 유연한 스크립트 모음"이라고 정의하고 있습니다. (Perl 기반)
공식 페이지에서는 아래 두 가지의 대표적인 유스케이스를 소개하고 있습니다.
Monitor는 이름 그대로 각 데이터베이스의 상태를 체크하며, Failover로 인한 구조 변경, 제어 등의 역할을 하고, 모니터 수행을 위해 각 노드들은 Agent가 설치되어야 합니다.
정의 그대로 Replication에 대한 구성 관리, 모니터링, Failover를 위한 솔루션이구요. 구성에 대해 깊이 정리하는 것 보다는 VIP 방식 vs DNS 방식에 대한 정리가 목적이므로 MMM에 대한 정리는 간단하게만 하겠습니다.
MMM VIP 구성 방식
In two node master-master setup, MMM uses five IPs: single permanent IP for each node that is never changed, 2 reader IPs (read-only) and 1 writer IP (updates). Last three IPs are migrating between the nodes depending on node availability.
Normally (no replication failures, no replication delay etc) active master has 2 IPs (reader and writer), standby master - 1 IP (reader). In case of a failure, both - writer and reader roles migrate to the working node.
위 구성에서 2.1 Two node setup 이미지에 달린 설명인데, 요약하자면 "각 노드에 불변하는 ip (실제 시스템에 부여된 ip 겠죠)가 있고, 쓰기, 읽기 전용 ip들을 각각 구성해서 통신이 되며 전용 ip들은 failover 시 active-standby 간 마이그레이션이 되는 ip다." 라고 말하고 있습니다.
그래서 실제 쿼리가 전송되는 ip는 읽기, 쓰기를 위한 virtual ip가 사용이 되고, 대략 아래처럼 설정이 됩니다.
<role writer>
hosts db1, db2
ips x.x.x.x
mode exclusive
</role writer>이러면 DB를 바라보고 있는 Client(Application)에서는 VIP로만 요청을 주면 되고, 문제가 생겨도 위 설정대로 MMM 모니터 서버에서 active, standby를 교체하는 방식으로 Failover가 진행됩니다.
여기서 제약 사항은 vip를 Master에 할당해야 되기 때문에, vip와 2개의 Master는 모두 동일 네트워크(L2)에 있어야 합니다. vip로 통신해서 active에 쿼리를 전송하고 결과를 받는 것, Failover 시 Master에서 vip를 회수하고, Standby에 vip를 할당해서 Master와 체인지 후 동일하게 통신하는 것 모두 동일 네트워크 영역에서 이루어질 수 밖에 없습니다.
따라서 스위치가 이중화되어 있다고 하더라도, 동일 네트워크에 있어 분산이 안되고 구축 시에 항상 같은 네트워크, 위치에 구축해야 된다는 제약이 뒤따릅니다.
서버에 직접 부여된 ip를 쓰지 않고 vip를 할당하는 이유
클라이언트에서 하나의 ip만 바라보게끔 하기 위함입니다.
만약 직접 부여된 ip를 쓸 경우 failover 시 클라이언트에서 요청하는 DB ip를 수정해야 하고, 어떠한 이유로 인식이 안 될 경우 장애가 발생하게 됩니다.
MMM DNS 구성 방식
DNS 구성 방식은 말 그대로 vip 대신 도메인으로 설정하는 방식입니다.
아래의 구성도를 보면 DB에 대한 요청을 도메인으로 진행하고, MMM 모니터 서버는 Failover가 발생하면 DNS를 갱신하여 도메인에 Standby Master의 ip를 연결합니다.
DNS를 이용하기 때문에 동일한 네트워크일 필요가 없습니다.
그렇지만 1) 망 내에 자체 네임 서버 구축이 되어야 한다는 점, 2) failover 시 DNS 캐싱으로 인해 추가적인 시간이 더 소요된다는 점으로 적용 시 고려해야 할 부분이 있습니다.
위 두 가지 방식의 장단점을 고려하여, 시스템 구축 시 현재의 상황에 맞게 데이터베이스의 고가용성을 확보하고 운영할 수 있습니다.
출처 및 참고 자료
https://www.mysql-mmm.org/mysql-mmm.html
MMM Manual 2.2.1
log4perl.logger = INFO, FileInfo, FileWarn, FileError, FileFatal, MailFatal log4perl.appender.FileInfo = Log::Log4perl::Appender::File log4perl.appender.FileInfo.Threshold = INFO log4perl.appender.FileInfo.filename = /var/log/mysql-mmm.htmlprogam.info lo
www.mysql-mmm.org
https://www.youtube.com/watch?v=dCVKAJ7tb70