[데이터베이스] MySQL Replication

Database Replication

하나의 DB만 사용하지 않고 주 Database를 다른 Database에 복제하는 방법입니다.

물론 DB 를 구성할 때 하나의 DB 로도 구성할 수 있지만, 안정성을 위해 여러개의 DB 를 두어 운용을 하는 경우가 많습니다.
이 때 역할에 따라 주 Database 를 Master DB(source), 복제해가는 Database를 Slave DB(replica)라고 부릅니다.
역할에 따라서 진행되는 replication 이라는 작업을 통해 DB 가 장애와 같은 상황에서 더 안정적으로 동작하도록 해줍니다.

Master 와 Slave 의 역할

Master

다른 노드(Slave)에 데이터를 복제해주는 쪽으로,
일반적으로 읽기 외에 insert, update 와 같이 데이터가 변경되는 것은 Master 에서 진행됩니다.

 

Slave

다른 노드에서 데이터를 복제해오는 쪽입니다.
Slave 는 일반적으로 읽기만 허용되며, Master 에서 변경된 사항을 주기적으로 업데이트합니다.
(다만, 새로운 노드가 추가되면 초기 데이터 sync 를 위해 slave 가 신규 노드에게 데이터를 복제해줄 수 있음)

 

replication이란?

master 의 데이터를 slave 쪽에 복사하여 두 곳이 같은 데이터를 가질 수 있도록 동기화를 하는 것입니다.
 MySQL 과 같은 RDBMS 뿐만 아니라 NoSQL, Redis 같은 스토리지까지도 Replication 을 지원합니다.
replication 을 하게되면 하나의 DB 가 문제가 생겨 DOWN이 되거나 요청을 수행할 수 없더라도, 같은 데이터를 가진 다른 DB 가 있어 그 DB 가 대신 수행할 수 있습니다.
*다만 multi master 등 모든 노드가 master 가 되어 서로가 sync 를 맞추는 방식도 있음

 

그러면 replication 을 하면 항상 데이터가 같을까요?

그렇지는 않습니다.
데이터의 sync 를 시도하고, 다른 곳에서 동기화가 완료되기까지 기다리는 것은 오래 걸릴 수 있기에 기본적으로는 async 하게 동작하게 됩니다.

즉, 데이터를 받은 쪽에서 반영 되기 전에 장애가 생긴다던지의 이슈가 발생하면 데이터가 누락될 수 있습니다.
또한 장애가 아니더라도, 데이터를 전달하고 복제하는 데에 걸리는 시간이 있기 때문에 데이터의 시간차가 발생하는 replication lag 이 생길 수 있습니다.
따라서 금융이나 보안 같이 오차가 생기면 안되는 경우라면 master 에서 read/write 를 모두 담당하고, slave 는 추후 장애시 백업을 위한 standby 용도로만 남겨두는 것이 좋습니다.

 

Master-Slave 구조를 통한 Failover

Master 역할을 하던 노드가 죽으면 요청에 대한 수행이 불가능해지므로,
Slave 를 승격시켜 Master 의 역할을 이어받도록 하는 Failover 을 통해 서비스가 정상적으로 계속 유지되도록 합니다.
그 후, 죽었던 Master 의 노드를 다시 살리거나 새로운 노드를 추가하여 기존의 구조를 유지할 수 있도록 합니다.

이 때 주의할 점은 데이터의 초기 복제입니다.
새로운 노드가 추가되면 다시 데이터의 sync 를 맞추기 위해 다른 곳으로부터 데이터를 한번에 받아오게 되는데,
이 때 데이터의 양이 많으면 데이터를 복제해주는 곳의 리소스 부하가 올라가는 문제가 생깁니다.
따라서 서로 초기 Sync 를 맞추고 있어 부하가 높더라도 다른 하나의 노드가 요청을 처리할 수 있도록 최소한 1 Master - 2 Slave 이상의 구조로 가져가는 걸 이상적으로 보고 있습니다.

 

사용목적

1. Scale-out을 통한 퍼포먼스 향상

모든 CRUD 쿼리를 하나의 DB에서 하게 되면 처리해야 할 쿼리가 몰리기 때문에 부하로 인해 퍼포먼스가 떨어지게 됩니다.
따라서 create와 같이 데이터가 삽입되거나 변경되는 쿼리는 master DB에서, 조회 쿼리는 slave DB에서 함으로써 부하를 분산시킬 수 있습니다.

 

2. 라이브 환경 성능에 영향 없이 Analyze 가능

라이브 데이터는 master DB에 쌓이는 반면, slave에서는 master로부터 데이터 싱크만 맞춘 별개의 DB이기때문에
slave DB에서 Analyze해도 라이브 데이터가 있는 master에는 영향을 주지 않습니다.

 

3. 데이터 백업 가능

Master의 데이터를 Slave에 실시간으로 백업해둔다면 후에 Master에 장애가 생겼을 때 Slave 서버로 변경하여 사용 가능합니다.

 

Replication 방법

MySQL에는 이진 로그를 통한 복제, GTID(글로벌 트랜잭션 식별자) 등 여러 방법을 통해 Replication을 할 수 있도록 지원하고 있습니다.
그 중 가장 전통적인 방법은 이진로그에서 이벤트를 복제하는 방법입니다.

 

바이너리 로그 이벤트 기록을 이용한 Replication

Master DB가 이벤트가 발생하면 이진 로그로 이를 기록합니다.
Slave DB는 Master DB와 로그 파일 및 로그 파일 위치를 공유함으로써 Master DB의 이벤트(데이터)를 복제하여 자신의 DB에 반영합니다.
바이너리 로그 기록을 이용해 Replication 하는 방법에는 1. 명령문 기반 복제(SBR), 2. 행 기반 복제(RBR) 두가지가 있습니다.

 

- 명령문 기반 복제 (Statement Based Replication)

SQL문을 이진 로그에 기록하면 복제본이 로그에 기록된 SQL 문을 실행하여 작동합니다.

- 행 기반 복제 (Row Based Replication)

개별 테이블 행이 변경되는 방식을 나타내는 이벤트를 바이너리 로그에 기록하고 복제본이 변경 사항이 반영된 이벤트를 복사하여 반영합니다. MySQL의 Default 설정입니다.

 

 

Replication 사용시 주의점

 

Master/Slave간의 버전 호환성

Master와 Slave의 MySQL 버전이 맞지 않으면 호환성 문제가 생길 수 있습니다.

 

명령문 기반 복제 사용시 데이터 정합성 문제

Master와 Slave의 환경이 달라 같은 쿼리를 수행해도 다른 결과가 나올 수 있으므로 유의해야합니다.
ex) SYSDATE 사용시 Master와 Slave의 쿼리 수행 시각이 다르므로 가져오는 sysdate 시간이 다를 수 있음

 

Replication 가동 순서

Replication 구동시 Master, Slave 순으로 가동해야합니다.