위키원
레플리케이션
레플리케이션(replication)은 서비스를 수행하고 있는 서버의 데이터에 대한 백업 데이터베이스의 최신 데이터 유지와, 서버의 예기치 않은 종료가 발생했을 때 대체 서버를 이용하여 서비스를 재개할 수 있는 무정지 운영 환경을 제공하는 것을 목적으로 한다.
목차
개요
레플리케이션은 데이터 저장과 백업하는 방법과 관련이 있는 데이터를 호스트 컴퓨터에서 다른 컴퓨터로 복사하는 것인데 이때 다른 컴퓨터가 반드시 떨어진 지역에 있어야 하는 것은 아니다. 컴퓨터 네트워크 상태에서는 데이터 저장을 할 수 있게 하는데 로컬 데이터 물리적 기억 장치와는 완전하게 구분된다. 레플리케이션은 유명한 데이터베이스 관리 시스템(RDBMS : Relational DataBase Management Systems)에서 추가적으로 제공하거나 여러 대의 데이터베이스 서버의 부하를 맞추어 줄 용도로 제공한다. 레플리케이션은 남아 있는 리소스와 관련이 있는데 소프트웨어 요소나 하드웨어 부품이 말해 주며, 이는 신뢰성, 허용 오차, 그리고 성능을 개선한다. 전형적으로 '레플리케이션 인 스페이스'(Replication in space)와 관련이 있는데 이것은 동일한 데이터를 다수의 저장 장치에 저장하거나 동일한 계산 업무를 다수 장치에서 수행하는 것이다. 또한 '레플리케이션 인 타임'(Replication in time)은 컴퓨터 계산 수행이 반복적으로 한 개의 장치에서 일어나는 것이다.[1]
종류
- 온라인 데이터 레플리케이션(Online data replication)
- 오프라인 데이터 레플리케이션(Offline data replication)
- 오프라인 데이터 레플리케이션, 데이터 파일을 백업이 원격 지역에서 오프라인 상태에서 일어나는데 예를 들어 하루에 한 번 정도 주기로 실시한다. 이것은 환경에 더 우선시하며 전달량이 많고, 실시간 수행 시 시스템의 성능에 영향이 미치는 경우이다.
- 분산 시스템에서 레플리케이션(Replication in distributed systems)
- 두 가지 분산 시스템에서 레플리케이션이 존재하는데 능동(active)과 수동(passive) 레플리케이션이 있다. 능동 레플리케이션은 또한 상태 머신 레플리케이션(state machine replication)이라고 알려져 있는데 수행하는 것이 동일한 요구를 매 복사 시점에서 처리하는 것이다. 반면 수동 레플리케이션은 주기적으로 요구에 의해서 한 번 복사가 이루어지고 상태가 변하여 다른 복사로 이동한다. 유일한 머신이 요구된다면 그것은 프라이머리 백업(primary-backup) 개념이라고 불리는 것이다. 다른 한편으로 어떤 머신이 요구에 의해 수행하면 이때는 멀티 프라이머리(multi-primary) 개념이라고 한다. 멀티 프라이머리 개념에서 분산 동시 제어(distributed concurrency control)가 반드시 사용된다.
- 데이터베이스 레플리케이션(Database replication)
- 데이터베이스 레플리케이션이 사용되는 것은 대부분 데이터베이스 관리 영역인데 보통 마스터/슬레이브 관계를 갖는 원본과 복사본 사이를 다룬다. 마스터는 변경 사항을 기록하고 그 결과는 슬레이브에게 전달된다. 슬레이브가 제공하는 메시지는 변경이 성공할 때 받는 것으로 일련의 변경 사항을 보내도록 한다. 코다(Coda)와 레이드의 갱신의 정보는 데이터베이스 노드에 제공되고 이어서 다른 서버에게 전달된다. 그러나 상당한 비용 증가와 복잡도 때문에 어떤 상황에서는 실용적이지 않다. 가장 직면한 문제는 다수 마스터 레플리케이션(multi-master replication)에서 충돌 방지 해결 방안이다. 예를 들어 기록의 변경이 두 개 시스템에 동시에 일어나면, 해결 방안은 많은 방법이 존재한다. 한 가지 간단한 방법은 타이밍인데 처음 얻은 데이터 반대로 나중에 얻은 데이터를 저장함으로써 해결하는 것이다. 다른 방법은 계층적 규칙을 따르는 것인데 계층이 낮은 데서 변화보다 높은 곳의 변화를 우선시하는 것이다. 마지막으로 로직 설정에 따른 방법인데 설정 변경이 가능하지만 복잡하게 된다.
- 파일시스템 레플리케이션(Filesystem replication)
- 능동(실시간) 파일 시스템 레플리케이션은 보통 구현이 가상 블록 장치의 업데이트 내용을 물리적 하드 디스크에 분배하는 것이다. 이런 방법으로 파일 시스템의 지원은 운영 체계가 레플리케이션을 할 수 있는데 변경이 필요 없다. 따라서 파일 시스템 코드 작업은 블록 장치 레이어 위에서 이루어진다. 가장 일반적인 방법은 레이드이고 제한적으로 로컬에 연결된 디스크만 가능하다. 대안으로 블록 장치에 업데이트가 컴퓨터 네트워크에서 레플리케이션할 수 있다. 이것의 이점은 레플리케이션 슬레이브가 위치하게 되는 물리적 원격 위치에 있어서 파괴되는 것을 피하고 유용성을 증가하는데 로컬 고장이나 재난 수준의 경우에 있어서이다. 이 같은 레플리케이션의 예는 리눅스를 위한 DRBD 모듈이 있다.
- 분산 공유 메모리 레플리케이션(Distributed shared memory replication)
- 또 다른 예는 분산 공유 메모리에서 사용되는 레플리케이션인데 이것은 시스템의 많은 노드를 같은 메모리 페이지에서 공유하여 각 노드에서는 별도의 복사된 페이지를 가지고 있다.
- 투명한 레플리케이션(Replication transparency)
- 리소스가 몇 개의 위치에 레플리케이션되면 단일 리소스 사용자에게 보인다.[1]
특징
실시간 데이터베이스 응용 시스템 분야나 핵심 업무 영역의 응용 시스템을 다루는 산업 분야에서는 데이터의 성능이나 일관성보다 시스템의 가용성에 보다 무게를 두는 경우가 많다. 시스템의 예기치 못한 오류로 인하여 데이터베이스 서비스가 중단되는 경우 치명적인 경제적 손실이나 시스템 내부 데이터의 불일치성을 유발할 수 있기 때문이다. 따라서 이러한 응용의 경우 시스템의 고가용성(high availability)과 안정성이 필수적인 기능이라 할 수 있겠다. 그 기능에 대하여 크게 아래와 같은 세 가지로 구분할 수 있다.
- 고가용성 확보
- 일반적으로 가용성이란 시스템의 정지 없이 서비스가 가동될 수 있는 확률을 의미하는 것이며, 고가용성이란 긴 시간 동안 지속적으로 서비스를 운영이 가능한 시스템이나 컴포넌트를 의미한다. 레플리케이션을 사용하면 하나 이상의 데이터베이스의 데이터가 네트워크를 통해서 복제되어 항상 같은 데이터를 가지고 있기 때문에 서비스를 제공하던 데이터베이스에 장애가 발생할 경우, 동일한 데이터를 가지고 있는 백업 데이터베이스로 페일오버를 해서 계속적인 서비스를 제공할 수 있다. 애플리케이션에서 데이터베이스의 장애를 감지하게 되면 데이터베이스에서 자동으로 레플리케이션이 구성되어 있는 다른 데이터베이스로 해당 애플리케이션을 페일오버하여 계속적인 서비스를 할 수 있도록 해준다.
- 부하 분산을 통한 성능 개선
- 레플리케이션으로 구성된 데이터베이스는 항상 같은 데이터를 가지고 있기 때문에 하나의 데이터베이스를 사용해서 모든 애플리케이션을 처리할 때보다 업무 특성(DML 과 SELECT) 등을 고려해서 애플리케이션을 분산시키면, 데이터베이스에 가해지는 부하가 줄어들게 되고, 이는 전체적인 성능 향상을 가져오게 된다.
- 장애, 재해 시 데이터 손실 최소화
- 물리적인 시스템 장애나 천재지변과 같은 재해 시에 하나의 시스템을 운영하게 되면 장애를 복구할 동안 정상적인 서비스를 할 수 없게 된다. 그래서 일반적으로 백업 서버를 운영하게 되는데, 레플리케이션을 사용하게 되면 백업 서버의 운영을 손쉽게 할 수 있다. 레플리케이션을 엑티브 스탠바이(ACTIVE-STANDBY) 형태로 구성하여, 하나의 데이터베이스에서만 서비스를 운영하게 되면, 별도의 백업 작업을 하지 않아도 레플리케이션으로 구성된 백업 데이터베이스에는 동일한 데이터가 복제되어 저장된다.[2]
구성요소
방식
데이터베이스 레플리케이션을 하기 위하여, 지역 서버는 데이터베이스에서 발생하는 데이터 변경 내용을 원격 서버로 전송하고, 원격 서버는 전송받은 내용을 자신의 데이터베이스에 반영하는 방법을 사용한다. 지역 서버와 원격 서버는 데이터베이스 서비스 스레드와 별도로 레플리케이션 관리에 필요한 스레드를 구동한다. 지역 서버의 레플리케이션 송신 스레드는 데이터베이스의 데이터 변경 내역을 원격 서버로 전송하며, 원격 서버의 레플리케이션 수신 스레드는 전송받은 변경 내용을 데이터베이스에 반영시킨다. 또한 레플리케이션 송수신 스레드는 대응 서버의 정상 및 비정상 종료를 자동 감지하며 이에 상응하는 작업을 수행한다.
서버 선정
레플리케이션을 하기 위해서는 데이터베이스 서버들의 데이터베이스 캐릭터 셋과 내셔널 캐릭터 셋이 서로 동일해야 한다
대상 선정
레플리케이션 대상을 선정하는 기준으로 객체의 '이름'을 사용한다. 레플리케이션을 생성할 때에는 레플리케이션 대상이 되는 테이블 이름과 그 소유자 이름을 직접 지정해야 한다. 파티션드 테이블의 특정 파티션만 복제하려면, 파티션 이름과 파티션이 속한 테이블 이름 및 그 소유자 이름을 직접 지정해야 한다. 또한 레플리케이션을 수행 시 지역 서버와 원격 서버에서 이름이 같은 컬럼만 복제된다.
모드
데이터 베이스 레플리케이션은 변경 내용의 전달 방식에 따라 LAZY 모드와 EAGER 모드로 나뉜다. 레플리케이션 모드 별로 성능, 레플리케이션 밀림현상, 데이터 일관성 측면에서 아래 표에서 보는 것처럼 서로 다른 특징을 갖는다.
요약표 모드 성능 레플리케이션 밀림 현상 데이터 일관성 LAZY 높음 발생 가능 낮음 EAGER 중간 발생 불가능 높음
- LAZY 모드
- LAZY 모드는 지역 서버에서 레플리케이션 대상 테이블에 대한 DML 을 수행하는 주 트랜잭션이 발생하면, 레플리케이션의 송신 스레드가 주 트랜잭션이 기록한 로그를 수집하여 XLog로 가공하여 전송한다. 그리고 원격 서버의 수신 스레드는 XLog를 수신하여 복제 트랜잭션으로 데이터베이스에 반영하는 형태이다. 이처럼 서비스 트랜잭션 (주 트랜잭션)과 복제 트랜잭션이 완전히 별개로 동작하기 때문에 트랜잭션의 영향을 받지 않아 지역 서버의 성능이 우수하다. 그러나 송신 스레드가 언제나 주 트랜잭션을 따라가는 입장이기 때문에, 매우 바쁜(busy) 사이트 환경에서는 레플리케이션이 밀리는 현상이 발생할 수 있다.
- EAGER 모드
- EAGER 모드는 지역 서버에서 발생한 주 트랜잭션과 관련된 모든 로그가 원격 서버에서도 정상적으로 반영된 것을 확인한 후에 지역 서버에서 커밋을 수행하고, 동시에 원격 서버에서도 복제 트랜잭션의 커밋을 수행하는 트랜잭션 동기화 방식이다. EAGER 모드의 이점은 트랜잭션을 동기화하기 때문에 트랜잭션을 병렬로 복제할 수 있다는 점이다. 그러므로, EAGER 모드로 레플리케이션을 수행할 때는 다수의 송신 스레드가 병렬로 복제를 수행한다. 병렬 스레드의 개수는 REPLICATION_EAGER_PARALLEL_FACTOR 프로퍼티로 설정할 수 있다. 트랜잭션 동기화로 인해 성능이 조금 떨어지는 단점이 있으나, 트랜잭션 발생이 매우 빈번한 사이트에서도 LAZY 모드처럼 레플리케이션이 밀리는 현상이 발생하지는 않는다.
부가 기능
- 복구 옵션 : 레플리케이션을 진행 중에 서버가 비정상 종료되면 서버 간 데이터가 불일치하는 것을 방지하기 위해 레플리케이션을 이용한 데이터 복구 기능
- 오프라인 옵션 : 액티브 스탠바이 레플리케이션 환경에서 액티브 서버에 장애가 발생하면, 오프라인 옵션을 사용하여 미전송된 로그를 스탠바이 서버에 반영할 수 있는 기능
- 레플리케이션 갭 해소 옵션 : 레플리케이션을 수행할 때 발생하는 레플리케이션 갭을 해소하는 기능
- 병렬 적용자 옵션 : 송신자로부터 받은 XLog를 수신자가 병렬로 적용할 수 있는 기능
- 레플리케이션 트랜잭션 그룹 옵션 : 레플리케이션 갭이 발생하였을 때 전송해야 할 복수의 트랜잭션들을 하나의 트랜잭션처럼 그룹화하여 수신 스레드에 로그를 전송하는 기능
주의사항
레플리케이션할 수 있는 객체는 테이블 또는 파티션이며, 양쪽 서버에서 대응하는 레플리케이션 대상 아이템은 서로 종류가 동일해야 한다. 즉 테이블은 테이블로, 파티션은 파티션으로 레플리케이션할 수 있지만, 서로 교차되는 레플리케이션은 지원하지 않는다. 레플리케이션 객체에서 레플리케이션 대상 테이블 또는 파티션을 삭제할 때에는 추가할 때 지정한 그대로 명시해야 한다. 예를 들어, 한 파티션드 테이블의 모든 파티션을 레플리케이션 대상으로 추가했어도, 파티션드 테이블을 지정해서 레플리케이션 대상에서 제외하는 것은 불가능하고 파티션을 각각 지정해서 제외할 수 있다.
충돌 해결
충돌
“데이터 충돌(Data Conflict)”은 주 트랜잭션에 의한 변경 내용이 복제 트랜잭션에 의해 재현될 때 프라이머리 키 또는 제약 조건으로 인해 데이터 변경이 불가능한 상황을 일컫는 말이다. 지연 레플리케이션(Deferred Replication) 방식을 사용할 때, 데이터 충돌을 피하는 가장 좋은 방법은 각 데이터베이스에서 갱신하는 데이터 집합을 서로 다르게 두는 것이다. 아래는 3가지의 데이터 충돌과 각 충돌이 발생하는 이유이다.
- 인서트 충돌(INSERT Conflict)
- 복제 트랜잭션이 프라이머리 키 컬럼에 이미 존재하는 값으로 인서트를 시도할 때
- 복제 트랜잭션이 인서트 하려고 하는 테이블이 이미 다른 지역 트랜잭션에 의해 잠금 상태일 때, 복제 트랜잭션은 잠금을 획득하기 위해 기다려야 하는데, 잠금 시간제한 설정(Lock timeout) 때문에 인서트 충돌이 발생할 수 있다.
- 복제 트랜잭션이 유일 키 제약 조건을 가지는 컬럼에 이미 존재하는 값으로 인서트 하려고 할 때
- 업데이트 충돌(UPDATE Conflict)
- 존재하지 않는 프라이머리 키값으로 레코드 변경을 시도할 때
- 복제 트랜잭션이 변경하려 하는 레코드의 데이터가 주 트랜잭션에 의해 변경된 레코드의 이전 이미지(Before Image : 변경되기 전의 데이터)와 다를 때
- 변경에 의해 중복된 유일 키값이 생성될 때
- 델리트 충돌(DELETE Conflict)
- 복제 트랜잭션이 존재하지 않는 프라이머리 키값을 가지는 레코드를 삭제하려고 할 때
- 로컬 트랜잭션에 의해 이미 잠금 상태인 레코드를 삭제하려고 할 때, 복제 트랜잭션은 잠금을 획득하기 위해 기다려야 하는데, 잠금 시간제한 설정 때문에 인서트 충돌이 발생할 수 있다.
충돌 해결
“충돌 해결(Conflict Resolution)”은 데이터 충돌을 제거하기 위한 여러 방법을 일컫는다. 가장 좋은 방법으로는 양쪽 서버에서 동일한 키값으로 인서트/업데이트/델리트를 수행하지 않도록 하는 것이다. 예를 들어 만약 특정 테이블에 대하여 시퀀스가 프라이머리 키일 경우 한 쪽은 홀수로, 다른 쪽 서버에는 짝수로만 데이터를 인서트/업데이트/델리트 수행한다면 절대로 레플리케이션 충돌이 발생되지 않는다. 그리고 벌크(bulk)상 인서트/업데이트/델리트를 수행하지 않도록 해야 한다. 알티베이스 기준으로 예를 들자면 아래와 같은 해결방안이 존재한다.
- 사용자 중심 계획(User-Oriented Scheme)
- 인서트 충돌 : 동일한 키를 가진 데이터를 인서트 하려는 경우, 반영하지 않는다. (altibase_rp.log에 Conflict Error Message 출력)
- 델리트 충돌 : 동일한 키를 가진 데이터를 델리트 하려는 경우, 반영하지 않는다. (altibase_rp.log에 Conflict Error Message 출력)
- 업데이트 충돌 : 동일한 키를 가진 데이터를 업데이트 하려는 경우 아래의 속성값에 따라서 반영 여부를 판단한다.
- - REPLICATION_UPDATE_REPLACE=1 : 갱신함
- - REPLICATION_UPDATE_REPLACE=0 : 갱신하지 않으며 Conflict Error Message 출력
- 마스터-슬레이브 계획(Master-slave Scheme)
- 레플리케이션 객체를 선언 시 구문에 as master 또는 as slave를 지정하면 다음과 같이 레플리케이션 충돌을 처리한다.
- 마스터의 처리 방식 : 인서트/업데이트/델리트 충돌에 대하여 모두 반영하지 않는다.
- 슬레이브의 처리 방식
- - 인서트 충돌 : 기존에 존재하는 레코드를 삭제하고 새로운 레코드를 추가한다.
- - 업데이트 충돌 : 충돌을 무시하고 무조건 반영한다.
- - 델리트 충돌 : 반영하지 않는다.
- 타임스탬프 기반 계획(Timestamp-based Scheme)
- REPLICATION_TIMESTAMP_RESOLUTION 프로퍼티 값을 1로 설정한 후 레플리케이션 테이블에 타임 스탬프(timestamp) 칼럼을 사용하여 최신의 값으로 반영하는 방법이다. 이 방법은 레플리케이션 대상 테이블 모두에 타임 스탬프 칼럼을 추가해야 하고 레플리케이션되는 양 서버 간의 시간을 동일하게 설정해야 하는 제약사항이 존재한다.[3]
각주
- ↑ 1.0 1.1 레플리케이션 위키백과 - https://ko.wikipedia.org/wiki/레플리케이션
- ↑ Altibase, 〈ALTIBASE HDB 5.3.3 기초강좌〉, 《꿈꾸는 개발자, DBA 커뮤니티 구루비》, 2012-04-14
- ↑ 〈replication conflict 발생원인과 해결방법〉, 《ALTIBASE》, 2013-07-09
참고자료
- 레플리케이션 위키백과 - https://ko.wikipedia.org/wiki/레플리케이션
- Altibase, 〈ALTIBASE HDB 5.3.3 기초강좌〉, 《꿈꾸는 개발자, DBA 커뮤니티 구루비》, 2012-04-14
- 〈replication conflict 발생원인과 해결방법〉, 《ALTIBASE》, 2013-07-09
같이 보기
