안녕하세요. KT Hitel 에서 메일, SNS 개발 및 Cubrid 의 활성화를 위해 노력(?) 하는 사람 입니다.
오픈화 정책의 기본 정신인 공유를 위해 이렇게 공개 Q&A에 질문을 드립니다.
1. 이번 HA 구현의 핵심은 Replication 일텐데요.(Sync,Semi Sync 추가가 핵심일듯) 인덱스, 트리거, 사용자 계정과 같은 DBMS 입장에서 저장소에 저장된 메타 데이터나 인덱스와 같은 참조형 데이터도 대상으로 하고 있는지요?
2. 이번 릴리즈 노트를 보니 인덱스 수정, 삭제시 성능향상이 있다고 들었습니다. 이러한 성능향상의 배경에 raw 데이터의 자료 구조 변경이 있었는지요? 아니면 인덱스 변경을 위한 접근 방법 변경을 통한 개선인가요? (이 부분은 저희측 테스트 수행에 있어 차이가 있을수 있기에 질문 드립니다.)
3. Replication 환경에서 Unique 제약조건을 가진 속성의 경우 selection 대상 기준으로 다중업데이트가 불가능 하다는 얘기를 들었는데 이에 대한 이유로는 여러가지가 있을 수 있겠네요. (복제를 위해 주고 받는 로그의 크기라든가 처리 과정의 복잡성이라든가) 하지만 이 Unique 제약조건은 DBMS 가 튜플의 상관 관계에 대한 제약 조건의 기본이라 할 수 있기에 일반적인 DB 설계에서 자주 사용되고 있습니다. 또한 어플리케이션 레벨에서 이러한 제약조건을 준수하기 위한 로드는 클 수 밖에 없을 것이구요. 이에 대한 대안을 생각하고 계신지요? 만일 있다면 구현 계획은 있으신지요?
4. Replication 환경에서 Slave 는 현재 특별한 제약 없이 DDL 을 수행할 수 있게 되어 있습니다. 따라서 Slave 만 별도의 테이블이나 오브젝트를 가진다면 Raw 로그 데이터를 기반으로 한 Replication 에서 문제가 되진 않나요? 예전 테스트 결과에서는 사실 이 부분이 큰문제는 아니었습니다. Replication 을 위한 로그가 변경의 작은 단위(예: 테이블, 컬럼)를 범위로 하고 있는것 같아서요.
5. HA를 위한 Replication 은 기존의 Async 와 Sync, Semi-Sync 를 지원한다고 하였습니다. 각각에 대한 성능이 어느정도 차이가 있을 까요?
6. 현재 Replication 장애의 가장 대표적인게 트랜젝션이 직렬화 되지 못하고 바뀌어 전달됨으로 인한 무결성 깨짐이라 들었습니다. HA 를 위한 Replication 에서 Sync를 이용할 때 이러한 트랜젝션 단위의 직렬화를 보장하는지요? 아니면 현재 Deadlock 검출 기준을 Serialize 로 적용을 같이 해야 보장 되는지요?
7. 온라인 컴팩트를 Master 혹은 Slave 에서 하게되면 문제가 발생하는지요?
8. 서비스 중단 없이 OS, 소프트웨어 업그레이드 및 장비 교체, 확장 등의 유지보수 작업이 서비스 중지 없이 가능하다고 했는데 이는 HA를 위한 구현 기능 때문인가요? 만일 그렇다면 결국 유지보수를 대상 서버는 중단 되는 형태인가요?(하나의 서버로 운용될 수 있기 때문에 대상 서버를 마음대로 할 수 있기 때문?)
9. 마지막으로 유지보수 대상 서버의 보수 과정이 끝나고 재 투입시 데이터 초기화 과정 없이 중간 부터(예: 체크 포인트) 자동 복제가 일어나는지요?
그럼 답변 부탁드립니다.
좋은 하루 보내시고 수고하세요.
오픈화 정책의 기본 정신인 공유를 위해 이렇게 공개 Q&A에 질문을 드립니다.
1. 이번 HA 구현의 핵심은 Replication 일텐데요.(Sync,Semi Sync 추가가 핵심일듯) 인덱스, 트리거, 사용자 계정과 같은 DBMS 입장에서 저장소에 저장된 메타 데이터나 인덱스와 같은 참조형 데이터도 대상으로 하고 있는지요?
2. 이번 릴리즈 노트를 보니 인덱스 수정, 삭제시 성능향상이 있다고 들었습니다. 이러한 성능향상의 배경에 raw 데이터의 자료 구조 변경이 있었는지요? 아니면 인덱스 변경을 위한 접근 방법 변경을 통한 개선인가요? (이 부분은 저희측 테스트 수행에 있어 차이가 있을수 있기에 질문 드립니다.)
3. Replication 환경에서 Unique 제약조건을 가진 속성의 경우 selection 대상 기준으로 다중업데이트가 불가능 하다는 얘기를 들었는데 이에 대한 이유로는 여러가지가 있을 수 있겠네요. (복제를 위해 주고 받는 로그의 크기라든가 처리 과정의 복잡성이라든가) 하지만 이 Unique 제약조건은 DBMS 가 튜플의 상관 관계에 대한 제약 조건의 기본이라 할 수 있기에 일반적인 DB 설계에서 자주 사용되고 있습니다. 또한 어플리케이션 레벨에서 이러한 제약조건을 준수하기 위한 로드는 클 수 밖에 없을 것이구요. 이에 대한 대안을 생각하고 계신지요? 만일 있다면 구현 계획은 있으신지요?
4. Replication 환경에서 Slave 는 현재 특별한 제약 없이 DDL 을 수행할 수 있게 되어 있습니다. 따라서 Slave 만 별도의 테이블이나 오브젝트를 가진다면 Raw 로그 데이터를 기반으로 한 Replication 에서 문제가 되진 않나요? 예전 테스트 결과에서는 사실 이 부분이 큰문제는 아니었습니다. Replication 을 위한 로그가 변경의 작은 단위(예: 테이블, 컬럼)를 범위로 하고 있는것 같아서요.
5. HA를 위한 Replication 은 기존의 Async 와 Sync, Semi-Sync 를 지원한다고 하였습니다. 각각에 대한 성능이 어느정도 차이가 있을 까요?
6. 현재 Replication 장애의 가장 대표적인게 트랜젝션이 직렬화 되지 못하고 바뀌어 전달됨으로 인한 무결성 깨짐이라 들었습니다. HA 를 위한 Replication 에서 Sync를 이용할 때 이러한 트랜젝션 단위의 직렬화를 보장하는지요? 아니면 현재 Deadlock 검출 기준을 Serialize 로 적용을 같이 해야 보장 되는지요?
7. 온라인 컴팩트를 Master 혹은 Slave 에서 하게되면 문제가 발생하는지요?
8. 서비스 중단 없이 OS, 소프트웨어 업그레이드 및 장비 교체, 확장 등의 유지보수 작업이 서비스 중지 없이 가능하다고 했는데 이는 HA를 위한 구현 기능 때문인가요? 만일 그렇다면 결국 유지보수를 대상 서버는 중단 되는 형태인가요?(하나의 서버로 운용될 수 있기 때문에 대상 서버를 마음대로 할 수 있기 때문?)
9. 마지막으로 유지보수 대상 서버의 보수 과정이 끝나고 재 투입시 데이터 초기화 과정 없이 중간 부터(예: 체크 포인트) 자동 복제가 일어나는지요?
그럼 답변 부탁드립니다.
좋은 하루 보내시고 수고하세요.
