Database Replication

Replication

 데이터 저장, 백업하는 방법과 관련이 있는 데이터를 호스트 컴퓨터에서 다른 컴퓨터로 복사하는 것인데 이때 다른 컴퓨터가 반드시 떨어진 지역에 있어야 하는 것은 아니다. 컴퓨터 네트워크 상태에서는 데이터 저장을 할 수 있게 하는데 로컬 데이터 물리적 기억 장치와는 완전하게 구분된다. 레플리케이션은 유명한 데이터베이스 관리 시스템에서 추가적으로 제공하거나 여러 대의 데이터베이스 서버의 부하를 맞추어 줄 용도로 제공한다. 레플리 케이션은 남아 있는 리소스와 관련이 있는데 소프트웨어 요소나 하드웨어 부품이 말해 주며, 이는 신뢰성, 허용 오차, 그리고 성능을 개선한다. 전형적으로 replication in space 와 관련이 있는데 이것은 동일한 데이터를 다수의 저장 장치에 저장하거나 동일한 계산 업무를 다수 장치에서 수행하는 것이다. 또한 replication in time는 컴퓨터 계산 수행이 반복적으로 한 개의 장치에서 일어나는 것이다.

물리적으로 다른 서버의 저장 공간안에 동일한 데이터를 복사

데이터베이스 레플리케이션

데이터베이스 레플리케이션 사용되는 것은 대부분 데이터베이스 관리 영역인데 보통 마스터/슬레이브 관계를 갖는 원본과 복사본 사이를 다룬다. 마스터는 변경 사항을 기록하고 그 결과는 슬레이브에게 전달된다. 슬레이브가 제공하는 메시지는 변경이 성공할 때 받는 것으로 일련의 변경 사항을 보내도록 한다. 코다(Coda)와 레이드의 갱신의 정보는 데이터베이스 노드에 제공되고 이어서 다른 서버에게 전달된다. 그러나 상당한 비용 증가와 복잡도 때문에 어떤 상황에서는 실용적이지 않다.

가장 직면한 문제는 다수 마스터 레플리케이션(multi-master replication)에서 충돌 방지 해결 방안이다. 예를 들어 기록의 변경이 두 개 시스템에 동시에 일어나면, 해결 방안은 많은 방법이 존재한다. 한 가지 간단한 방법은 타이밍인데 처음 얻은 데이터 반대로 나중에 얻은 데이터를 저장함으로써 해결하는 것이다. 다른 방법은 계층적 규칙을 따르는 것인데 계층이 낮은데서 변화보다 높은 곳의 변화를 우선시하는 것이다. 마지막으로 로직 설정에 따른 방법인데 설정 변경이 가능하지만 복잡하게 된다.

[출처] 위키피디아 Replication

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

1.1. Master-slave replication

하나의 Master와 여러 개의 slave로 구성된다. 트랜잭션은 오직 master 에서만 발생하고, slave는 읽기전용(read-only)로 구성한다.

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

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

1.2. Multi-master replication (Master-master replication)

분산된 모든 데이터베이스에서 읽기/쓰기 트랜잭션을 수행하며, 이들 트랜잭션을 동기화 한다. 같은 컬럼에 다른 값을 update하는 sql 구문이 2개의 master에 동시에 전달될 경우 데이터 동기화에 문제가 생길 수 있다.

[출처] http://www.joinc.co.kr/w/man/12/replication

MySQL Replication

데이터 변경을 마스터 장비에서만 수행하기 때문에 마스터 장애 시에는 전체 노드에 데이터 쓰기 작업이 불가능한 한계가 있습니다. MySQL에서는 쓰기 부하 분산은 불가능하지만, 읽기 부하 분산은 가능합니다. 그리고 특정 노드 디스크 장애가 전체 데이터 유실로 이어지지 않습니다. 데이터는 “복제”되니까요.

MySQL Replication은 로그 기반으로 비동기적으로 데이터를 복제합니다. 마스터에서는 데이터 변경 작업이 수행되면 Binary Log라는 곳에 이력을 기록을 하는데, Statement, Row 그리고 Mixed 등 세 가지 방식이 있습니다.

Statement-based Type

Row-based Type

Mixed Type (Statement + Row)

Replication 단계

1. Master에서 데이터 변경이 일어나면 자신의 데이터베이스에 반영합니다.
2. Master에서 변경된 이력을 Binary Log에 기록 후 관련 이벤트를 날립니다.
3. Slave IO_THREAD에서 Master 이벤트를 감지하고,
   Master Binary Log 자신의 Relay Log라는 곳에 기록을 합니다.
4. Slave SQL_THREAD는 Relay Log를 읽고 자신의 데이터베이스에 기록을 합니다. (4,5단계)

기억해야할 사항은 마스터에서는 여러 세션에서 데이터 변경 처리가 가능하지만, 슬레이브에서는 오직 하나 SQL Thread에서만 데이터 변경 처리가 가능한 점입니다. 그렇기 때문에 마스터에 데이터 변경 트래픽이 과도하게 몰리게 되면 마스터/슬레이브 간 데이터 동기화 시간이 크게 벌어질 수도 있습니다.

[출처] http://gywn.net/2011/12/mysql-replication-1/

DB 서버를 여러대 두고 웹서버로 부터의 접속(query, select)를 분산시켜 DB 서버의 부하를 줄이는 방법.

slave 서버에서 master 서버의 binary log file 을 참조하여 업데이트 하므로 slave 서버에 로그인하여 DB를 update 하면 동기화가 되지 않으니 slave 서버는 select 용도로만 사용

[replication 이유]

http://blog.seulgi.kim/2015/05/why-use-mysql-replication.html

[SQL Server Replication]

https://msdn.microsoft.com/ko-kr/library/ms151198.aspx

---

Multi-az

Amazon RDS의 multi zone replication (multi-az)

AWS의 Zone은 같은 지역에 있는 물리적으로 다른 데이타 센터의 개념을 이야기 함.

RDS의 Multi Zone replication은 한 데이타 센터가 고장 나더라도 다른 데이타 센터에서 서비스가 가능한 구조.

기본적으로  Active-Stand by 형태로 복제하다가, 장애가 나면 stand by 서버로 fail over하는 구성

중요한 것중 하나는 MySQL RDS의 경우 자동 Back 시, 시스템이 일시적으로 멈추는 현상이 보이는데, Multi AZ deploy의 경우, back up시에, 자동 fail over하여, 멈추는 현상 없이 서비스가 가능함

http://bcho.tistory.com/678

Amazon RDS에서 High Availablity를 구현하는 대표적인 방법입니다.

가용 Zone에 두 개의 인스턴스(기본 인스턴스/예비 인스턴스)를 띄우고, 기본 인스턴스DB에서 데이터 변경 즉시 동기화합니다. Replication이 비동기적인 방식으로 동작하지만, Multi-AZ은 동기화 방식이라는 점에서 큰 차이가 있습니다.

MySQL Replication의 고질적인 문제인 실시간 데이터 동기화 지연 문제와, 장애 시 빠른 복구가 어려운 문제를 단번에 해결할 수 있는 방안이죠.

http://gywn.net/tag/amazon-rds/

---

Replication VS Cluster