[MYSQL] 이중화 구성 (MMM, MHA, Replication, Gerea cluster)

MySQL Replication

① master에서 client가 query를 실행하면
② 데이터가 변경되는 insert, upda te, delete의 경우 binary log라는 파일에 기록이 되고
③ mysql에서 query가 실행된다.
④ slave에서는 binary log를 감시하다가, 새로운 query가 들어오게 되면 해당 정보를 slave의 relay log로 가져오기 위해, master에게 새로운 query를 요청한다.
⑤ master는 slave의 요청을 받아 binary log에 적힌 쿼리를 slave로 전달하면서 전달 되었다는 것을 보장받기 위해 응답을 기다린다.
⑥ slave는 master로부터 새로운 query를 잘 받았다는 응답(ACK)을 보내고
⑦ master는 slave로부터 ACK를 받으면 client에게 OK 시그널을 보낸다.
이렇게 master의 변경사항이 slave의 relay log에 작성됨을 보장한다.
⑧ 그리고 slave의 mysql에서 query를 실행함으로써 master에 적용된 데이터가 slave에도 적용되게 된다.

 

# 구성 예시

[MYSQL] Replication (Master-Slave 동기화)

 

MMM(Multi-Master Replication Manager)

• Multi-Master의 단점을 보완하기 위해서 Manager 장비를 두어 가용성을 보장한다.
• Master(Active)와 Master(standby) 양방향으로 복제가 가능하지만 MMM에 의해 Master(Standby)는 읽기모드로 제어된다.
• Perl (Practical Extraction and Report Language)기반의 Auto Filover Open Source
  
  

-. Perl은 문자열을 변환하고 추출하는 텍스트 처리(정규표현에 의한 검색, 치환)기능이 있어
복잡한 텍스트 처리가 가능하며 C, C++, JAVA와 같이 컴파일(기계어로 변화하는 작업)이 필요 없는 인터프리터 방식이다.
-. 프로그램을 기술한 후 바로 실행 가능.컴파일이 필요없는 프로그래밍 언어를 Script라 하는데, Perl로 만들어진 프로그램을 [Perl Script]이라 한다

 

• 이 구조에서 slave가 추가 되면 Master(Active)에서 slave로 단방향으로 복제를 하는 구조가 만들어진다.

MMM의 동작

1. Active Master에서 장애 발생 시 MMM Manager라는 장애를 감지한다.

2. Active Master의 접속을 차단하고 VIP를 Standby Master로 넘긴다.

 

# 동작에 대한 자세한 설명 

MySQL 이중화 진화기

 

MMM의 장단점

장점	단점
MySQL Replication이 지원하지 않는 auto FailOver를 지원한다. MMM Manager Server의 관리가 쉽고, MMM Manager는 Virtual IP 관리도 가능하다. MMM Manager에서 Active Master와 Passive Master 관리가 가능하다. MySQL의 성능에 영향을 주지 않는다.	MMM Manager 이중화가 불가능하다. Multi Master로 사용이 가능하나 Multi Master 사용 시 데이터 불일치 가능성이 있다. Active Master 장애 시 데이터 유실 가능성이 있다.

 

# 구성 예시

MySQL MMM 구성 (Centos7 + MySQL 8.0)

하지만 MMM의 Multi Slave 환경에서도 데이터가 유실될 수 있는 상황이 존재한다.
① Master(Active)에서 Master(Standby)와 Slave로 쿼리를 전달.
② Master(Standby)에서는 예상치 못한 오류로 쿼리 실행 X, Slave에서는 쿼리 실행 O.
③ Slave에서 쿼리가 실행되었으므로, ACK 전달
④ ACK를 받은 Master(Active)는 client에게 ACK 시그널 전달.
⑤ 갑작스레 Master(Active) 서버 종료.
⑥ Master(Standby)가 신규 마스터로 승격.
⑦ 데이터 유실 발생!!

 

그 대안으로 MHA가 제안 되었다.

 

MHA (Master High Availablility)

-. Master DB가 장애로 서비스가 불가능한 상태가 될 시, 자동으로 FailOver를 수행하여 slave DB를 master DB로 승격시켜 서비스 다운 타임을 최소화 하는 auto FailOver 솔루션이다.

-> 일반적으로 생각하는 Active-Standby 구조의 HA구성인듯 하다.

 

MHA 서버 구성

• MHA Manager, Master, Slave 서버로 총 3개로 구성되어 있으며, 상황에 따라서는 1개의 Master와 N개의 Slave로 최소 2대까지 사용할 수 있다.
• Master와 Slave는 하나의 VIP를 공유하며 DB 접속은 해당 VIP를 이용하며 장애 발생 시 VIP를 이용하여 절제를 진행한다.
• 또한, Failover의 후속처리로 다시 살아난 Master A에 대해 현재 운영중인 Master B, Slave C와의 관계를 자동으로 만들어주지 않기 때문에, 복제를 재구성해주는 작업을 별도로 해주어야 한다.

 

MHA의 장점

• 최소한의 다운 타임으로 Master의 장애 처리 및 Slave의 새로운 Master로 변경 수행이 가능하다.
• Master의 장애로 각 노드(Master 및 Slave)의 데이터 불일치가 발생하지 않는다.
• 현재 MySQL 서버의 설정을 변경할 필요가 없다.(MySQL 5.0 이상)
• 서버를 많이 늘릴 필요가 없다. (MySQL Cluster 대비)
• 스토리지 엔진에 제약을 받지 않고, MySQL 성능에 전혀 제약사항이 없다.

 

MHA의 장애 체크

• MHA Manager가 3초마다 마스터 DB를 CONNECT / SELECT / INSERT 체크하며 3회 실패 시 장애로 인식하여 FailOver를 수행한다.

 

MHA의 FailOver

• MasterDB에 장애가 발생하면 MHA Manager는 Master 장비의 VIP를 down시킨다.
• 이 후 Replication을 진행 후 down 시킨 VIP를 Slave장비에 올려 FailOver를 진행한다.

 

MHA의 Replication

1. MySQL에서는 Lossless Replication은 지원한다. 이는 Master에서 데이터 변화가 진행되면 Slave 어딘가에 반드시 변경이력이 남아있다는 것을 보장한다.
2. MHA에서는 장애 발생 시 가장 최근에 변경된 Slave를 Master DB로 승격 시킨 후 Lossless Replication을 통한 relay log로 데이터 복구를 수행한다.
3. 장애 발생부터 Master DB 승격, 데이터 복구까지 걸리는 시간은 10~30초 이다.

# 구성 예시

[MariaDB] MHA + Replication 구성하기

 

Galera cluster (Active - Active)

Galera cluster는 http://galeracluster.com/ 에서 제공되는 오픈소스로, 동기방식의 복제 구조를 사용하고 있다.

 

1. 동작 방식

1.1 아무 노드에 쓰기나 업데이트 발생 1.2 모든노드에 데이터를 복사를 완료 1.3 업데이트 내용이 파일에 저장된다

 

2. 노드간 구체적인 흐름

 

-. 노드에 트랜젝션이 발생하고 commit이 실행되면

-. 디스크에 내용을 쓰기전에 다른 노드로 복제 요청

-. 다른 노드에 복제 요청이 접수되었을때, 해당 노드의 디스크에 실제로 데이터를 쓴다.

 

단점 

다른 Oracle RAC, Tibero TAC와 달리, 데이터를 디스크에 저장하기 전에, 다른 모든 노드에 데이타 복제 요청을 해야 하기 떄문에, 비동기 방식의 MySQL Replication에 비해서, 쓰기 성능이 떨어진다.