DBMS의 Replica, Replication

굉장히 단어가 비슷해서 착각할 수 있지만 엄연히 다른 용어라고 보는 게 맞을 것이다.

 

구글에서 비교해 봤을때 replica는 [레플리카]로 번역되고, replication은 [복제]로 번역되게 된다.

굳이 '레플리카'라는 단어로 번역되는건 한국에서 대체할 만한 단어가 없기 때문이 아닐까 싶은데, 어쨌든 레플리카는 DBMS를 얘기할 때 일반적인 replication과는 다른 개념으로 사용되는 경우가 많다.

 

요런 놈이 replication. 사실 클러스터라고 해서 무작정 A-A로 사용하는게 좋은 것만은 아님.

replication은 완전한 복제는 아니며 Active-Standby 환경에서 주로 사용된다. CDC를 아시는지? 보통은 타겟의 로그파일을 읽어서 데이터를 긁어오는 형식인데, CDC가 꽤나 대표적인 replication에 해당한다.

상대방이 commit을 수행하고 그 내용을 Log(redo log)에 심으면 그 내용을 상대방 어플리케이션이든 유틸리티든 DBMS 엔진이든 어떤 한 놈이 읽어서 복제 대상에다 데이터를 그대로 써주는 것이다.

 

로직을 보면 알겠지만 replication은 완전한 데이터 복제는 아니다. 데이터 반영에 딜레이가 존재할 수 밖에 없기 때문에(Log 파일을 긁고 해당 DB에 반영해야 되기 때문에 반영하는 동안에 발생한 트랜잭션은 적용이 불가함) 메인 서버에 문제가 발생했을 경우 Slave 서버에 모든 데이터가 반영되었다는 보장이 불가능하다.

 

클러스터 개념이 제대로 자리잡힌 현대에 와서는 DR(재해방지)용으로 사용하는 경우가 많다. 서울에 메인서버가 존재하고 서울에 있는 건물이 무너질 경우(!)를 대비해서 수원에다 만드는 그런 용도인 것. 극한 상황이기 때문에 데이터 반영의 차이는 어쩔 수 없다는 논리인 셈이다.

 

 

replica는 '완전한 복제'를 표방한다. 소위 Clustering 시스템 구성이 이 부분에 해당하는 것이다.

 

Commit된 순간부터 두 개의 인스턴스(혹은 여러 개의 인스턴스)는 동일한 데이터를 가져야 한다는 논리인 거고, 애초에 데이터가 틀어진다면 그건 Clustering이라 말할 수 없는 것이다.(사실 split-brain과 같이 현실적으로 어쩔 수 없는 부분은 있어서 100%라고 보장은 못하지만)

 

클러스터링 시스템을 구성할 경우 어제 말했던 2pc 등을 이용해 데이터를 동기화하기 때문에 데이터가 반영이 안 되면 안 됐을지언정 누구는 커밋되고 누구는 안 커밋되고 이런 상황은 없는 것이다.

 

소위 HA(High Availability가 맞나? 철자가 헷갈림)라 불리는 고가용성 이슈 등도 기본적으로 replica가 적용되지 않으면 성립할 수 없는 셈이다. 한 쪽이 죽으면 바로 다른 한쪽으로 사용할 수 있다는 것은 완전한 복제본이 하나 더 있다는 가정 하에 진행되는 것이고.

 

 

replica는 완전한 복제기 때문에 Active-Active로 구성할 수 있다는 크나큰 장점이 있다. replication은 조건부 가능은 하지만 굉장히 위험하기 때문에 실제로 사용하는 경우는 매우매우 드물다. 데이터가 겁나 잘 틀어지는데다 개발공수가 훨씬 더 들어갈 수밖에 없기 때문.

 

겉보기엔 Cluster가 훨씬 좋은 거 아니냐 할 수 있겠지만 꼭 그런 것만은 아니다. CDC와 같은 놈은 Master의 트랜잭션에 영향을 끼치지 않게 구현할 수 있기 때문에 부하 분산 측면에서 유리한 점도 있다.