1. replication 환경에서 데이터 충돌이 발생하는 경우는?(일반적인 경우)
replication conflict 는 동일한 key 값에 대하여 동시에 insert/update/delete를 수행할 경우 발생한다.
insert의 경우의 예
1) A서버에서 key=1인 데이터가 insert 된 후 B서버로 이중화데이터를 전송하기 전에
2) B서버에서 동이란 key=1 데이터가 insert 될 경우 나중에 B서버에서 수신한 이중화 데이터는 이미 B서버에 동일한 key=1 인 데이터가 존재하므로 conflict 가 발생하게 된다.
2. conflict 를 최대한 방지할 수 있는 방안은?
가장 좋은 방법은 양쪽 서버에서 동일한 key 값으로 insert/update/delete 를 수행하지 않도록 하는 것이다.
예를 들어,
특정 테이블에 대하여 sequence가 primary key 일 경우 한 쪽은 홀수로 다른 쪽 서버에는 짝수로만 데이터를 insert/update/delete 수행한다면 replication conflict 를 방지할 수 있다.
그리고 bulk 상 insert/update/delete를 수행하지 않도록 해야 한다.
알티베이스에서 지원하는 replication conflict resolution은 다음의 3가지 방안이 있다.
1) User-Oriented Scheme
(1) insert conflict : 동일한 key 를 가진 데이터를 insert 하려는 경우, 반영하지 않는다.
(altibase_rp.log에 Conflict Error Message 출력)
(2) delete conflict : 동일한 key 를 가진 데이터를 delete 하려는 경우, 반영하지 않는다.
(altibase_rp.log에 Conflict Error Message 출력)
(3) update conflict : 동일한 key 를 가진 데이터를 update 하려는 경우 아래의 속성 값에 따라서 반영여부를 판단한다.
- REPLICATION_UPDATE_REPLACE = 1 : 갱신함
- REPLICATION_UPDATE_REPLACE = 0 : 갱신하지 않으며 Conflict Error Message 출력
2) Master-Slave Scheme
이중화 객체를 선언 시 구문에 as master 또는 as slave 를 지정하면 다음과 같이 이중화 conflict 를 처리한다.
(1) Master의 처리 방식 : insert/update/delete conflict 에 대하여 모두 반영하지 않는다.
(2) Slave의 처리 방식
- Insert conflict : 기존에 존재하는 레코드를 삭제하고 새로운 레코드를 추가한다.
- Update conflict : 충돌을 무시하고 무조건 반영한다.
- Delete conflict : 반영하지 않는다.
3) Timestamp-based Scheme
REPLICATION_TIMESTAMP_RESOLUTION 프로퍼티 값을 1로 설정한 후 이중화테이블에 timestamp 컬럼을 사용하여 최신의 값으로 반영하는 방법이다.
이 방법은 이중화 대상 테이블 모두에 timestamp 컬럼을 추가해야 하고 이중화되는 양 서버간의 시간을 동일하게 설정해야 하는 제약사항이 존재한다.
---------------------------------------------------------------------------------------------------
HDB_6.1.1_Replication_KOR.pdf
이중화 관련 상세한 설명은 첨부파일을 참고하시기 바랍니다.(첨부문서는 altibase_6.1.1 버전입니다.)
출처 : http://support.altibase.com