요약
replication conflict 발생원인과 해결방법을 설명 합니다.
replication 환경에서 데이터 충돌이 발생하는 경우
replication conflict 는 동일한 key 값에 대하여 동시에 insert/update/delete 를 수행할 경우 발생합니다.
● insert conflict: INSERT 충돌이 발생하면, INSERT는 실패하며 altibase_rp.log에 충돌 오류 메시지가 출력됩니다. 존재하는 레코드와 동일한 Key를 가진 데이터를 삽입하려는 경우 발생하는 충돌을 해결하는 정책을 설정하려면, REPLICATION_INSERT_REPLACE 프로퍼티를 사용 합니다. REPLICATION_INSERT_REPLACE=1: 삭제 후 삽입 합니다. REPLICATION_INSERT_REPLACE=0: 삭제하지 않거나 삽입하며, 오류 메시지 출력를 합니다.
● update conflict: UPDATE 충돌이 발생하면, UPDATE는 실패하며 altibase_rp.log에 충돌 오류 메시지가 출력됩니다. 충돌 해결을 위해 REPLICATION_UPDATE_REPLACE 프로퍼티를 사용할 수 있습니다. 이전 이미지가 다른 데이터를 변경시키거나, 존재하지 않는 프라이머리 키로 변경하려 할 때 발생합니다. 예를 들어, 현재 10이라는 데이터가 있는데 복제 트랜잭션은 20에서 30으로 바꾸라는 갱신이 발생한 경우, 상황에 따라 다음과 같은 정책을 사용할 수 있습니다. REPLICATION_UPDATE_REPLACE=1 : 갱신 합니다. REPLICATION_UPDATE_REPLACE=0 : 갱신하지 않으며, 충돌 오류 메시지를 출력 합니다.
● delete conflict: DELETE 충돌이 발생하면, DELETE 는 실패하며 altibase_rp.log에 충돌 오류 메시지가 출력됩니다.
insert 의 경우를 예를 들면
1) A 서버에서 key=1 인 데이타가 insert 된 후 B서버로 이중화데이타를 전송하기 전에
2) B서버에서 동일한 key=1 데이타가 insert 될 경우 나중에 B서버에서 수신한 이중화 데이터는 이미 B서버에 동일한 key=1 인 데이타가 존재하므로 conflict 가 발생하게 됩니다.
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 confilct : 동일한 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 : 충돌을 무시하고 무조건 반영한다.
- Insert conflict : 반영하지 않는다.
3) Timestamp-based Scheme
REPLICATION_TIMESTAMP_RESOLUTION 프로퍼티 값을 1로 설정한 후 이중화테이블에 timestamp 컬럼을 사용하여 최신의 값으로 반영하는 방법입니다. 이 방법은 이중화대상 테이블 모두에 timestamp 컬럼을 추가해야 하고 이중화되는 양 서버간의 시간을 동일하게 설정해야 하는 제약사항이 존재합니다.
conflict 유형
conflict가 발생하면 $ALTIBASE_HOME/trc/altibase_rp.log에 로그가 남습니다.
● insert conflict: 이미 동일한 PK(Primary Key)가 존재할 경우 발생 합니다.
● update conflict: PK(Primary Key) 는 같으나 리모트 서버에서 온 변경전 값이 현재값과 다를 경우 발생 합니다.
● delete conflict: PK(Primary Key) 는 같으나 리모트 서버에서 온 변경전 값이 현재값과 다를 경우 발생 합니다.