MySQL HA (Replication, Group Replication, Galera Cluster)

MySQL의 HA(High Availabilty)를 위한 Replicaiton 기법은 다음과 같습니다.

• Master-Slave Replication
• Group Replication
• Galera Cluster

이 기법들에 대해서 알아보도록 하겠습니다.

Master-Slave Replication

하나의 Master DB와 다수의 Slave DB들을 통해 Replication을 수행하는 방식인데 Master는 Read/Write Mode로 동작하고 Slave들은 Read Mode로 동작합니다.
이 말 뜻은 DB 변경 Query를 수신 받는 DB는 반드시 Master DB에게 변경 요청을 전달하고 Master DB는 변경 내용을 Slave DB에게 전달하여 복제를 수행한다는 말입니다. 그리고 Read 요청은 로드밸런서를 통해 Master or Slave DB로 요청을 분산시켜 성능을 높입니다.
Replication 방식에는 Asynchronous, Semi-Synchronous 2가지 방식을 지원 하는데 두 방식 모두 동기 방식이 아니기 때문에 Slave DB는 짧은 순간 Master DB와 동기화되지 않는 상태일 수 있습니다.

Master DB 장애 시

Master DB에 장애가 발생 했을경우, Master DB를 Recovery하거나 특정 Slave DB를 Master DB로 승격시키는 방법을 통하여 장애를 해결할 수 있습니다만 이 방법들은 모두 DB 관리자가 수동으로 해야합니다. 첫번째 방법은 데이터의 손실 염려가 없다는 점에서 안전한 방법이지만 Master DB가 복구될때까지 DB에 Write를 요청하지 못한다는 단점을 갖고 있습니다.
Slave DB를 Master DB로 승격시키는 것은 Master DB의 장애를 해결하는 것이 아니기 때문에 빠른 조치를 취할 수 있지만, Master DB에서 Slave DB로 데이터 동기화가 완전히 이루어지지 않은 데이터가 있을 수 있으므로 데이터의 손실이 발생될 수 있습니다.

Slave DB 장애 시

Slave DB는 위에서 언급한 Asynchronous, Semi-Synchronous 방식에 따라 장애 조치가 다릅니다.

Asynchronous Replication

Master DB는 binlog에 DB 변경 이력을 저장하고 이를 Slave DB에 전파합니다.
그리고 Slave는 Master로부터 전파 받은 변경 이력을 수행 후 relay log에 저장합니다.
Slave DB는 장애 발생 후 복구 되었을때, 이러한 relay log와 Master DB의 binlog를 통하여 중단되었던 replication을 진행합니다.

Semi-Synchronous Replication

Master DB가 Slave DB로부터 Relay Log 기록이 완료되었다는 ACK 신호를 받고 Transaction을 진행하는 방식입니다.
만약 Master DB가 Slave DB로부터 Relay Log를 받지 못하면 Transaction은 중단되기 때문에 Asynchronous Replication에 비해 동기화에 대한 신뢰성이 더 높습니다. 하지만 비교적 많은 DB 성능저하가 발생됩니다.
Master DB는 모든 Slave DB에게 DB 변경 요청을 보내고 하나의 Slave DB로부터 Relay Log ACK를 받으면 Transaction을 진행하므로 Transcation 중단이 빈번히 발생되는 것을 막기 위해서는 다수의 Slave DB를 두면 됩니다.

Group Replication

Group Replication은 다수의 DB 노드를 Group으로 구성하여 Replication을 수행하는 방식이며 Client는 Proxy, LB등의 역활을 수행하는 MySQL Router를 통해서 DB로 접근합니다.
Group Replication은 Single-Primary, Multi-Primary 2가지 Mode를 지원합니다.

Single-Primary

Write 요청을 수행 할 수 있는 Primary DB는 한개로 구성되며 Read 요청은 모든 DB들이 수행 할 수 있습니다. Primary-Secondary DB 사이의 Replication은 Master-Slave Replication와 동일하게 Asynchronous, Semi-Synchronous 2가지 방식을 모두 지원합니다.
라우터는 Write와 Read를 수행하는 Port를 각각 가지고 있으므로, 클라이언트는 해당 목적에 맞게 Port를 지정하여 쿼리를 요청해야합니다.
Primary DB가 장애가 발생 했을 시 Master-Slave Replication와 다르게 선거를 통하여 자동으로 Secondary DB가 Primary DB로 승격됩니다.
새로운 Pirmary DB가 선출 되었을시, 이전의 Primary DB로부터 온 모든 트랜잭션을 처리 한 후에만 Write를 수행 함으로써 실행중인 새 트랜잭션 간의 동시성 문제를 피할 수 있습니다. 새로운 Primary DB가 복제 관련 Relay log를 모두 적용 할 때까지 기다린 후 Client로부터의 새로운 요청을 받는 것이 좋습니다.

Multi-Primary

Multi-Primary Mode는 모든 DB가 Primary Node로 동작하므로 모든 DB가 Read/Write 요청을 받을 수 있습니다.
LB 역활을 하는 라우터는 요청을 부하가 적은 DB에게 보내게 되는데 서로 다른 DB에서 같은 Row을 동시에 변경하여 Commit 충돌이 발생하였다면 먼저 Commit한 DB의 변경 내용이 반영되고 나중에 Commit한 내용은 rollback됩니다.
Client로부터 Write 요청을 받은 DB는 변경 내용을 다른 Primary DB로 보내게 되고 수신 받은 DB는 Certify(Commit 충돌 검사 과정)를 진행하고 결과를 첫번째 DB에 전달해줍니다.
첫번째 DB는 Certify 완료 요청을 받으면 그제서야 Client에게 응답을 해주게 되는데 이런 과정은 Overhead를 유발합니다.
Replication 과정은 Paxos 분산 알고리즘을 통하여 이루어지는데 이는 과반수 이상의 DB에서 변경내용이 반영되면 Commit 처리됩니다.
이는 하나의 디비에서 실패를 허용하기 위해서는 그룹에 적어도 3대의 DB가 있어야 함을 의미하며, F개의 실패를 용인하는 데 필요한 서버의 수(N)는 다음과 같습니다.
N = 2 x F + 1

Galera Cluster

Galera Cluster는 동기 방식을 사용하고 있는 오픈소스로, 과반수가 아닌 모든 DB에 Replication을 진행한 뒤에 업데이트 내용을 파일에 저장합니다.
각 DB 노드에는 데이터 복제를 위한 범용 모듈인 WSREP가 존재하는데 여기에 Galera replication module을 연결해주면 데이터 변경이 있을때마다 다른 DB로 데이터를 복제해 줍니다.
자세한 데이터 복제 구조는 다음과 같습니다.

트랜젝션이 발생하고 Commit이 실행 되면 다른 DB들에게 복제를 요청하고 다른 DB들의 복제 완료 요청이 접수되었을때 해당 노드의 디스크에 실제로 데이터가 저장됩니다.
이로인해 데이터가 항상 일관성있게 저장되고 특정 노드가 장애가 나더라도 서비스에 크게 문제가 없습니다.
하지만 Galera Cluster는 다음과 같은 문제를 가지고 있습니다.

1. 다른 DB 노드들에 모두 데이터 복제를 완료한 뒤에 쓰기를 완료하기 때문에 다른 비동기 Replication에 비해 성능이 떨어집니다.
2. Lock 문제가 생기거나 느린 쿼리들이 많이 발생할때 장애를 전파시킬 수 있는 잠재적인 문제가 있습니다.
3. 모든 노드에 데이타를 복제하고 트렌젝션을 끝내기 때문에 전체적인 노드 수가 많아지게 되면 복제를 하는데 그만큼 시간이 많이 걸리게 되어 하나의 클러스터에서 유지할 수 있는 노드의 수가 한계가 생기기 때문에, 횡적 스케일링의 한계가 올 수 있다.

참조

https://bcho.tistory.com/1062