윤은경 joanney1@daum.net, mysqldba.tistory.com, blog.daum.net/joanney｜다음커뮤니케이션 DB기술팀 MySQL Cell 소속. 대학 졸업 후 5년 동안 자바 개발자로 살다가, 갑자기 맘이 바뀌어 그 후 5년간 DBA로 살고 있는, 10년 차 직장인이 됐다는 게 여전히 믿겨지지 않는 IT 종사자이다.
MySQL HA 구성
HeartBeat를 이용한 HA 구성에는 다음과 같은 모듈이 필요하다.
● HeartBeat - 두 서버 사이에 Fail-Over를 가능하게 하는 모듈
● Mon - MySQL Instance의 서비스 가능 여부를 체크하는 체크 모듈
● MySQL Dual Replication - 원활한 Fail-Over 및 Fail-Back을 위한 Replication 구성
HeartBeat
HeartBeat는 Linux-HA 프로젝트 그룹에서 만든 모듈로서 리눅스 운영체제에서 고가용성을 제공한다. HeartBeat는 위에서 간단히 설명한 대로 두 서버 사이에 Fail-Over를 가능하게 하는 모듈로서 서버 사이의 Fail-Over 기능을 제공하고자 할 때 사용한다.
HeartBeat의 구성
HeartBeat를 설치하면 두 서버 사이에 즉, Primary로 설정된 서버와 Standby로 설정된 서버 사이에 주기적으로 메시지를 교환해 서버의 상태를 확인한다. 이때 주고받는 메시지를 ‘heartbeat’ 즉 한글로 ‘심장박동’이라고 한다.
.jpg)
HeartBeat는 Active로 사용 중인 Primary 서버와 Passive 상태인 Standby 서버 사이에 IP 관리 기능의 일환으로, VIP를 사용해 Active 상태인 Primary 서버에 장애가 일어나더라도 Passive 상태인 Standby 서버를 이용해 서비스가 진행될 수 있도록 한다.
애플리케이션에서는 VIP를 사용해 서버에 접근한다. 이때 VIP로 접근하는 애플리케이션은 HeartBeat 구성에서 Active로 설정된 Primary 서버에 자동으로 접근하게 된다. 만약 서버가 reboot되거나 문제가 발생해 사용하지 못하는 상태가 되는 경우 HeartBeat이 감지해 현재 문제가 발생한 Primary 서버가 아닌 Standby 서버를 Active로 전환해 서비스가 계속 이어지게 한다.
.jpg)
HeartBeat의 특성 및 제약 사항
HeartBeat는 다음과 같은 특성 및 제약 사항을 가진다.
- 리눅스 서버상의 Fail-Over 기능을 제공하고 리눅스 운영체제에서만 사용할 수 있다. HeartBeat 모듈은 리눅스-HA 프로젝트 그룹에서 만든 모듈이기 때문에 리눅스 운영체제에서만 동작하는 모듈이다. 그렇기 때문에 다른 운영체제를 사용하는 시스템에서는 사용이 불가능하다.
- 간단한 설치로 사용이 용이하다.
- 시스템 레벨(System Level)이 아닌 애플리케이션 레벨(Application Level)에서의 Fail-Over는 할 수 없다. HeartBeat는 VIP를 이용해 두 개의 서버 사이의 특정 서버만 접근 가능하게 하는 모듈이기 때문에 시스템 레벨만 가능할 뿐 HeartBeat 자체적으로는 애플리케이션 레벨의 Fail-Over가 불가능하다. 즉, 애플리케이션 레벨의 Fail-Over를 위해서는 추가적인 모듈이 필요하다.
- HeartBeat 구성을 위한 추가적인 장비가 필요하지 않다. HeartBeat은 Active와 Passive를 사용하는 두 서버 사이의 설정으로 사용하는 모듈이기 때문에 추가적인 장비가 필요하지 않다.
Mon
Mon은 이벤트를 이용해 서비스에 대한 사용을 모니터링하는 모듈이다. Mon은 시스템을 ping 프로그램을 이용해 모니터링하는 것과 같은 간단한 경우에서부터 DB 서버에 대한 모니터링까지 가능한 모니터링 모듈로서 HeartBeat과 같이 쓰여서 리눅스 상에서 Fail-Over를 구현할 수 있는 모듈이다.
.jpg)
Mon의 구성 및 동작 프로세스
MySQL 프로세스의 감지를 위해 Mon을 사용하는 경우 <그림 3>과 같은 프로세스로 모니터링이 진행된다.
먼저 Mon 실행 스크립트를 작성해 MON 프로세스를 띄운다. MON은 설정 파일(mon.cf)에 저장된 값을 이용해 주기적으로 mysql.monitor를 실행한다(mysql.monitor는 MySQL과 MSQL을 모니터링하기 위해 제공되는 스크립트인 msql-mysql.monitor의 이름을 수정한 것이다). mysql.monitor는 주기적으로 호출될 때마다 MySQL 프로세스를 체크하고, mysql.monitor가 체크시 MySQL 프로세스의 문제점을 확인하게 되면 bring-ha-down.alert를 호출하게 된다. bring-ha-down.alert는 MySQL 프로세스 문제 시 동작하는 스크립트 파일로서 이 파일에서 Fail-Over를 위해 HeartBeat 모듈을 호출하게 된다. 즉, bring-ha-down.alert은 HeartBeat를 호출하는 스크립트로서 이 스크립트를 통해 HeartBeat와 연결되어 동작한다. 이 스크립트는 Mon 모듈에 속한 게 아니라 사용자가 직접 생성해야 한다.
Mon의 특성 및 제약 사항
Mon은 다음과 같은 특성 및 제약 사항을 가진다.
- 여러 가지 애플리케이션 및 하드웨어의 장애를 감지하는 모니터링 툴이다. Mon은 다방면에서 사용할 수 있는 모니터링 모듈로서 MySQL 프로세스뿐 아니라 MSQL 프로세스 모니터링, 그리고 각종 하드웨어 모니터링까지 가능한 모듈이다. 여기에서 우리는 MySQL에 대한 모니터링 기능 부분만 사용한다.
- 간단한 스크립트 작성으로 사용하기가 간편하다. 위에서 설명한 것과 같이 간단한 스크립트 작성으로 모니터링 시 문제 해결을 위한 여러 기능을 구현할 수 있고, 원하는 대로 사용할 수 있다.
- 실질적인 Fail-Over를 발생시키는 모듈이 필요하다. 앞서 설명한 대로 Mon은 모니터링 모듈이기 때문에 Fail-Over를 위해서는 Mon뿐 아니라 추가적인 모듈이 필요하고, 그래서 여기서는 Fail-Over를 위한 모듈, 즉 HeartBeat과 같이 사용한다.
MySQL Replication
MySQL Replication은 MySQL Server 4.0에서부터 사용 가능한 HA 솔루션으로 가장 쉽게 구성할 수 있고, 가장 많이 사용하고 있는 솔루션이다. MySQL Replication은 다른 특별한 설치 과정이 필요 없이 MySQL 서버의 설치만으로 사용할 수 있고 구성하기 쉽기 때문에 누구나 쉽게 설치해 사용할 수 있다. 또한 제약사항이 적고 구성하는 프로세스가 간단하기 때문에 여러 구성으로 사용하는 것이 가능하다.
Replication의 구성
MySQL은 <표 1>과 같은 Thread를 통해 Replication을 운영한다.
.jpg)
MySQL은 <표 1>의 세 가지 프로세스를 비동기적으로 실행해 Replication이 진행되도록 한다. Replication은 이 세 개의 Thread만으로 동작하며 다른 임의의 프로세스가 존재하지 않는다. MySQL Replication의 동작은 <그림 4>와 같이 설명할 수 있다.
.jpg)
Slave에서 start slave 명령어가 실행되면 Master와 Slave에는 각각 Binlog Dump Thread와 I/O Thread, SQL Thread가 생성된다. 그리고 Binary log가 생성될 때마다 Binlog Dump Thread는 Binary Log를 Slave로 보낸다. 이때 Slave의 I/O Thread는 받은 Binary Log를 Relay Log로 기록하게 되고, SQL Thread는 이렇게 새롭게 기록된 내용을 읽어서 Slave에서 실행하게 된다. HeartBeat를 이용한 MySQL Replication은 일반적인 Replication이 아닌 Dual-Master 구성을 사용한다.
Dual-Master Replication
두 대의 서버가 동시에 Master/Slave의 역할을 수행하는 구성을 의미한다.
.jpg)
이 구성은 두 대의 서버가 인스턴스로 Replicate되는 구성으로 동시에 두 대의 서버가 Master/Slave로서의 역할을 수행하는 구성이다.
● 특징
- 두 서버가 서로 Replication으로 연결된 구조로서 어느 서버에서든지 DML을 발생시켜도 다른 서버에 Replicate되어 전달된다. 두 서버가 동시에 Master이자 Slave이기 때문에 각 서버에서 발생된 DML은 다른 서버로 이동하게 되고, 결국 같은 DML이 두 서버에서 다 발생하게 된다.
- 두 대의 서버가 같은 스키마와 데이터를 가진 구조이다. 앞에서 설명한 대로 두 서버의 DML이 Replicate되어 양 서버에서 다 발생하기 때문에 같은 스키마와 데이터를 가진 구조가 된다.● 장점
- HeartBeat/Mon을 이용한 HA 구성으로 사용할 경우 Fail-Over, Fail-Back에 유연한 대처가 가능하다. 이론적으로 두 서버가 동시에 Master와 Slave로 연결된 구조이기 때문에 단 방향으로 연결된 Replication 구조에 비해 Fail-Over, Fail-Back에 유연하게 대처할 수 있다. 물론, 안전한 Fail-Over, Fail-Back을 위해서는 Fail-Over, Fail-Back에 대한 프로세스는 간단하지 않다. 하지만, 단 방향 구조에 비해 그 프로세스는 간단하게 된다. 또한, HeartBeat에 의해 두 서버 중 하나의 서버만 실질적으로 서비스에 사용되기 때문에 뒤에서 설명할 Dual-Master 구조의 치명적인 단점에서 자유롭다.
- 어느 서버에 DML이 발생해도 다른 서버로 Replicate가 가능하다. 앞서 설명한 대로 양 방향으로 연결된 구조이기 때문에 두 서버 중 어느 서버에 DML이 발생해도 다른 서버에 Replicate되어 DML이 전달된다.● 단점
- 두 서버에서 동시에 같은 데이터에 DML이 발생하는 경우 데이터의 불일치 발생 가능성이 높다. Dual-Master 구조의 특징으로 두 서버가 같은 스키마와 데이터를 가진다고 설명했다. 하지만 Dual-Master 구조는 그 구성에 치명적인 문제를 가지고 있다. 바로 DML 발생에 따라 데이터 불일치가 발생할 수 있다는 것이다.
- DML 분산이 되는 것처럼 착각할 수 있으나, DML 분산은 실질적으로 발생하지 않는다. Replication 동작 프로세스를 통해 알 수 있는 것처럼 Master에서 실행된 Query를 Slave에서도 똑같이 동작하게 해 데이터를 일치화시키는 솔루션이므로, 실질적으로 두 서버의 DML이 분산되는 것은 아니다.
Configuration
이제 앞에서 설명한 모듈들을 사용한 전체 구성에 대해 알아보도록 하자. 여기서는 Replication을 이용해 HA 구성을 하게 되는데, Replication 중 앞에서 설명한 Dual-Master Replication 구성을 사용한다.
|
Dual Master 구조에서의 데이터 불일치 케이스 Dual Master 구조에서 컬럼의 값에 동시에 DML 쿼리가 실행된다고 가정해 보자.
먼저 각각 서버에서 update 문이 실행되기 때문에 처음에 server1은 1, server2는 2로서 값이 변경된다. Commit이 진행된 후 Binary log에 작성되고 각각 서버에서 실행된 Query는 BinlogDump Thread에 의해 server2, server1으로 이동하게 된다.
그 후에 Replication으로 넘어온 SQL 문이 실행되는 경우 값은 다시 server1은 2로 server2는 1로 바뀌게 된다. 결국 server1의 값은 2로, server2의 값은 1로 남게 된다. |
.jpg)
.jpg)
HeartBeat + Mon
HeartBeat와 Mon은 모두 무료로 사용할 수 있는 모듈이다. HeartBeat은 서버의 Fail-Over 기능을 제공하고 Mon은 MySQL 프로세스를 모니터링하는 기능을 제공하기 때문에 두 개의 모듈을 함께 사용해야만 완전한 Fail-Over 기능을 구현할 수 있다.
● 특징
- 다른 특별한 기기 없이 모듈 설치만으로 Fail-Over가 가능하다.
- 안전한 구성을 위해 추가적인 스크립트 생성이 필요하다.
- 리눅스 운영체제에서만 사용이 가능하다.
Dual Master Replication + HeartBeat + Mon
MySQL은 Dual Master 구조로 데이터를 실시간으로 복제한다. Mon은 실시간으로 MySQL의 상태를 체크해 모니터링하고 만약 MySQL 서버에 문제가 발생하면 그것을 감지하고 HeartBeat를 호출해 Fail-Over가 이뤄지게 한다. Fail-Over가 일어난다 할지라도 애플리케이션에서는 VIP를 통해 접근하기 때문에 문제없이 서비스를 지속할 수 있다.
이 구조에서 두 서버의 MySQL은 Dual Master 구조로 되어 있지만, HeartBeat 설정을 통해 애플리케이션은 VIP를 이용해 두 서버 중 하나의 서버에만 접근할 수 있으므로 구조적으로 가지는 Dual-Master의 문제점을 피할 수 있다. 여기서 설명한 HA 구성에서 문제 발생시 동작하는 프로세스를 정리하면 <그림 9>와 같다.
여기서 살펴본 HA 구성의 특징을 정리하면 다음과 같다.
● 특징
- Fail-Over를 하기 위한 별도의 장비가 필요하지 않다.
- Replication이 가능한 어떤 스토리지 엔진을 사용하든 구성할 수 있다.
- MySQL Community 버전 설치만으로 사용할 수 있다.
- 구성할 수 있는 두 대 중 한 대는 VIP를 사용해 서비스용으로 사용할 수 없다.
- Passive 상태의 Standby 서버를 물리적인 IP로 접근해 사용할 수는 있지만, 앞서 설명했던 Dual-Master의 데이터 불일치 가능성으로 인해 권장하지는 않는다.
- Fail-Over된 원인에 따라 Active로 사용하던 서버의 변경내역이 Replicate 되지 않을 수 있기 때문에, Replication에 대한 분석 프로세스가 추가되어야 한다.
- 리눅스 운영체제에서만 구성할 수 있다.
- HeartBeat 구성의 제약으로 인해 Fail-Over가 발생하면 꼭 Fail-Back 진행을 해줘야 한다.
- DB 레벨의 Fail-Over는 Heart-Beat/Mon 조합으로 가능하게 되었지만, 세션 레벨의 Fail-Over는 구현되지 않았기 때문에, Fail-Over 발생 시 애플리케이션의 DB Connection을 refresh하는 작업을 해야 한다.
맺음말
여기서 설명한 내용은 MySQL에서 구현할 수 있는 HA 구성 방법 중 하나로서 현재 필자는 이와 같은 구성으로 구현해 서비스에 투입한 후 사용하고 있다. 여기에서는 자세한 설치법보다는 각각 모듈의 개념 및 프로세스 설명에 주안점을 두어 설명했다. 이와 같은 내용을 먼저 알아두고 실제 설치 작업을 진행한다면 훨씬 더 쉽게 구현할 수 있다.
출처 : http://imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=33696
