구조
위 이미지와 같이 구조를 DB를 설정했을 때 아래와 같은 흐름이 이어진다.
이 처럼되면 master/slave라는 개념에 관계 없이 각각의 DB를 연결하고 어디서든지 CUD를 하게되면 순차적으로 DB들이 전파되어 데이터 동기화가 이루어질수 있다.
장점
원형 복제 뿐만 아니라 다른 DB 복제 방식들도 마찬가지로 부하를 분산시키고 가용성을 높이는 것이다.
- 데이터 읽고 쓰기 요청이 동등하게 분산된다
- 데이터 일관성을 유지할수 있다
- 데이터 손실을 최소화 할수 있다.
- 설정만 해두면 추가로 연결이 쉬워 유연하다.
단점
- 많은 DB가 추가된다면 업데이트 전파시간이 오래걸릴 수 있다.
- 예를 들어 10개의 DB가 원형복제로 연결되어 있을때 1에서 업데이트 하는경우 2~9까지
순차적으로 업데이트 되기 때문이다.
- 데이터 충돌이 일어날수 있다.
- 복제 업데이트를 수신하고 처리하는 데 걸리는 시간으로 인해 전체 이벤트 순서로 볼 때 다른 서버에서 복제를 트리거한 초기 이벤트가 먼저 발생했음에도 불구하고 클라이언트의 직접 요청이 동일한 행을 업데이트할 수 있다. 예를 들어 MySQL이 복제 업데이트와 클라이언트의 직접 SQL 문을 처리하는 방식은 병렬로 이루어진다. MySQL은 체인의 모든 데이터베이스에서 일관성을 보장하지 않는다. 이는 복제 요청이 클라이언트의 직접 요청과 동시에 열에 작용할 수 있기 때문이다.
2번 사항을 고려하여 한 서버나 서비스에서는 하나의 DB만 연결해서 update할 수 있도록 설정하는 방식을 고려 해볼수 있다. (결제에서는 DB1, 상품 정보관리 DB2 ….)
원형 복제 시스템의 복제 방지
그렇다면 여기서 궁금해지는건
순환되어 동기화가 이루어지는건데 DB1에서 update한 것을 DB5까지 전파되고나서 DB5에서 DB1으로 다시 전파가 될까?전파가 된다면 어떤 방법으로 이를 막고있을까?
우선 첫번째 정답은 yes이다.
원형 복제 시스템에서는 무조건 데이터 전파가 일어나도록 설계되어있다. 생각 해보면 데이터 전파전에
이건 이미 너한테 한번 일어난 정보야! 를 알려주기 쉽지 않을것 같다.그렇다면 어떻게 막고 있을까?
원형 복제 시스템은 내부적으로 각 변경 사항에 대한 고유한 식별자나 타임스탬프를 사용하여 중복을 방지하거나 이미 복제된 변경 사항을 구분하는 메커니즘을 가지고 있다.
다음은 몇 가지 원형 복제 시스템에서 사용되는 일반적인 메커니즘이다.
- 커밋 로그와 위치 추적 많은 데이터베이스 시스템은 복제된 변경 사항을 커밋 로그와 위치 정보를 사용하여 추적한다. 변경 사항이 복제되면 로그에 기록되며, 각 서버는 마지막으로 복제된 위치를 추적한다. 이를 통해 중복을 방지하고 이미 복제된 변경 사항을 확인한다.
- 논리적 로그 및 트랜잭션 ID 일부 원형 복제 시스템은 논리적 로그를 사용하여 데이터 변경 사항을 기록하고 각 트랜잭션에 고유한 식별자(예: 트랜잭션 ID)를 할당한다. 이로써 중복을 방지하고 복제된 변경 사항을 구분한다.
- 캐시와 체크포인트 일부 시스템은 변경 사항을 캐시하고 체크포인트를 설정하여 중복을 방지한다. 변경 사항이 복제되면 캐시에 저장되고, 이미 복제된 위치를 체크포인트로 기록하여 중복을 방지하고 이후 변경 사항을 구분한다.
- 벡터 시계 벡터 시계(Vector Clocks)와 같은 논리적 시간 태그를 사용하여 각 변경 사항의 상대적인 순서를 추적한다. 이를 통해 중복과 순서 문제를 처리한다.
많은 데이터베이스 복제 시스템은 이러한 메커니즘을 내부적으로 구현하고 있으며, 중복 변경 사항을 식별하고 구분하여 데이터 일관성을 유지한다.