티스토리 뷰

DB/MongoDB

[MongoDB] 복제 셋 구성 요소

snail voyager 2023. 7. 27. 16:46
728x90
반응형

11.1 동기화

프라이머리가 수행한 쓰기를 모두 포함하는 로그 oplog를 보관함으로써 복제를 수행

oplog는 프라이머리의 로컬 데이터베이스에 있는 제한 컬렉션

세컨더리는 이 컬렉션에 복제를 위한 연산을 쿼리

각 세컨더리는 프라이머리로부터 복제한 작업을 각각 기록하는 oplog를 보관

oplog는 다른 멤버에 대한 동기화 소스로 사용되도록 한다

세컨더리가 다운되면 재시작할 때 oplog에 있는 마지막 연산과 동기화

oplog는 크기가 고정되어 있으므로 담을 수 있는 연산의 수가 정해져 있다

일반적으로 oplog는 기본 크기면 충분

11.1.1 초기 동기화

초기 동기화를 수행해 복제 셋의 한 멤버에서 다른 멤버로 모든 데이터를 복사

모든 데이터를 대상 멤버에 있는 자체 컬렉션 복사본에 삽입

대상 멤버의 기존 데이터는 복제 작업을 시작하기 전에 삭제

mongod는 데이터를 모두 삭제하는 작업을 가장 먼저 수행

데이터가 필요 없거나 데이터를 다른 곳으로 옮겼을 때만 수행해야함

각 컬렉션에서 도큐먼트가 복사될 때 초기 동기화가 모든 컬렉션 인덱스를 구축

데이터베이스가 복제되면 oplog를 사용해 복제 셋의 현재 상태를 반영하고 데이터셋을 갱신

초기 동기화를 수행하면 해당 멤버는 자주 사용되는 데이터를 축출해 메모리로 페이징

멤버가 급격하게 느려지는 이유

데이터셋이 작고 서버에 여유 공간이 있으면 초기 동기화는 쉽고 좋은 방법

시간이 오래 걸리기 때문에 덜 바쁜 시간에 초기 동기화를 시도하거나 백업으로부터 복원하는 방법

11.1.2 복제

세컨더리 멤버는 초기 동기화 후 지속적으로 데이터를 복제

동기화 소스에서 oplog를 복사한 후 이러한 작업을 비동기 프로세스에 적용

투표수가 더 낮은 멤버와 동기화할 수 없음

지연된 멤버나 숨겨진 멤버와 동기화하지 않음

11.1.3 실효 처리

세컨더리는 동기화 소스상에서 수행된 실제 연산들보다 훨씬 뒤떨어지면 실효 상태가 된다

세컨더리가 다운타임 중이거나, 쓰기 요청이 처리량을 뛰어넘거나, 읽기 작업 때문에 매우 바쁠 때 발생

실효 상태가 되면 복제 셋의 각 멤버로부터 차례로 복제를 시도해, 

독자적으로 이행할 수 있는 긴 oplog를 갖는 멤버가 있는지 확인

세컨더리가 동기화되지 못하는 상황을 피하려면, 프라이머리가 많은 양의 연산 이력을 보관하는 큰 oplog를 가지면됨

 

11.2 하트비트

멤버는 복제 셋에 대한 최신 정보를 유지하기 위해 복제 셋의 모든 멤버로 2초마다 하트비트 요청을 보낸다

하트비트의 가장 중요한 기능은 복제 셋의 과반수 도달 가능 여부를 프라이머리에 알리는 기능

서버의 과반 수에 도달할 수 없다면, 프라이머리 스스로를 강등해 세컨더리가 된다

11.2.1 멤버 상태

멤버들이 가질 수 있는 일반적인 상태

  • STARTUP : 멤버를 처음 시작할 때의 상태. 구성정보가 로드되면 STARTUP2로 전환
  • STARTUP2 : 초기 동기화 과정 전반에 걸쳐 지속. 몇 초 동안만 지속. 다음 RECOVERING으로 변환
  • RECOVERING : 멤버가 현재 올바르게 작동하지만 읽기 작업은 수행할 수 없음을 의미. 조금 과부화된 상태
  • ARBITER : 아비터는 연산 중에는 특수한 상태를 유지
  • DOWN : 멤버가 살아 있지만 도달할 수 없는 상태. 네트워크 문제 때문에 도달할 수 없을 수 있음
  • UNKOWN : 멤버가 다른 멤버에 도달한 적이 없었다면 상태를 전혀 알 수 없음. 두 멤버 간에 네트워크에 문제
  • REMOVED : 멤버가 복제 셋으로부터 제거된 상태
  • ROLLBACK : 멤버가 데이터를 롤백할 때 사용. 롤백 마지막에 RECOVERING 상태로 전환 후 세컨더리가 됨

 

11.3 선출

멤버가 프라이머리에 도달하지 못하면 프라이머리 선출을 모색

복제 셋의 과반수로부터 득표하면 선출은 성공적으로 이뤄지고 해당 멤버는 프라이머리 상태로 전환

네트워크 상태가 양호하고 서버의 과반수가 살아있으면 선출은 빠르게 진행

 

11.4 롤백

프라이머리가 수행한 쓰기를 세컨더리가 복제하기 전에 프라이머리가 다운되면 

다음에 선출되는 프라이머리에 해당 쓰기가 없어짐

롤백은 복구 전에 복제되지 않은 연산을 원래 상태로 되돌리는 데 사용

영향 받은 각 도큐먼트 버전을 데이터 디렉터리의 rollback 디렉터리에 있는 .bson 파일에 쓴다

해당 서버는 다른 서버로부터 동기화를 시작하고, 동기화 소스에 가장 최근 수행한 연산을 찾을 수 없음을 인지

ROLLBACK 상태로 전환해서 롤백 프로세스를 시작

롤백이 완료되면 RECOVERING 상태로 전환되고 다시 정상적으로 동기화

728x90
반응형

'DB > MongoDB' 카테고리의 다른 글

[MongoDB] 복제 셋 관리  (0) 2023.08.08
[MongoDB] 애플리케이션에서 복제 셋 연결  (0) 2023.08.01
[MongoDB] 복제 셋 설정  (0) 2023.07.11
[MongoDB] 트랜잭션  (0) 2023.07.02
[MongoDB] 애플리케이션 설계  (0) 2023.06.20
반응형
300x250