메뉴

문서정보

목차

데이터베이스 Replication

Replication은 공유하는 데이터들에 접근성과 일관성, 가용성을 확보하기 위한 소프트웨어와 하드웨어적인 구성을 의미한다. 복제는 데이터를 분산된 여러 개의 스토리지에 2벌 이상 복사 하는 방식으로 구현한다.

대부분의 DMS(database management system)들이 리플리케이션을 지원한다. 일반적인(쉬운) 구성은 master/slave 리플리케이션이다. 하나의 master db와 하나 이상의 slave db로 구성되는데, 트랜잭션은 master db에서만 발생한다.

Master-slave replication

하나의 Master와 여러 개의 slave로 구성된다. 트랜잭션은 오직 master 에서만 발생하고, slave는 읽기전용(read-only)로 구성한다. Master는 쿼리 로그에 해당하는 binary log를 남기는데, Slave가 비동기적으로(asynchronous) 읽어가서 자신의 데이터베이스에 반영한다.

구현이 단순하다는 것이 장점이다. 예를 들어 mysql의 경우 단 몇줄의 설정으로 Master-slave replication을 구성할 수 있다. Master-slave replication은 읽기 요청을 분산하기 위한 목적으로 주로 사용한다.

대부분의 인터넷 서비스들은 쓰기 보다는 읽기가 더 많은 구조다. 따라서 읽기전용의 복제를 제공하는 Master-slave 리플리케이션으로도 서비스 확장에 대응할 수 있다.

Multi-master replication

엔지니어들 사이에서는 통칭 Master-Master 리플리케이션이라고 한다. 분산된 모든 데이터베이스에서 읽기/쓰기 트랜잭션을 수행하며, 이들 트랜잭션을 동기화 한다.

읽기와 쓰기가 모두 분산되고 복제된다는 점에서 master-slave replication보다 아름답게 보이긴 한다. 하지만 모든 트랜잭션을 동기화 해야 한다는게 깔끔하게 해결할 수 있는 문제가 아니라서, 특수한 경우가 아니라면 굳이 master-master 구성을 할 필요가 있을지 의문이다. 대부분의 서비스가 "읽기"가 많기도 하고.

같은 컬럼에 다른 값을 update하는 sql 구문이 2개의 master에 동시에 전달될 경우 데이터 동기화에 문제가 생길 수 있다. 이 문제의 해법을 찾을 수 있겠으나 깔끔한 해법을 찾기가 쉽지 않을 것 같다. 서버 장애가 발생했을 때, 장애를 감지하고 처리하는 것도 복잡하다.

Multi-master replication 이라고 해지만, 3개 이상의 master로 구성된 데이터베이스 시스템을 제대로 운영할 수 있을지는 모르겠다.

이 문제들은 전통적인 RDBMS로 구성할 때 발생할 수 있는 문제들이고, NoSQL이라면 상황이 다를 수 있다. 사실 NoSQL이라서 상황이 다른게 아니고, 저장하는 데이터의 특성에 따른 것으로 봐야 하겠지만..

참고