복제

중복성 및 데이터 가용성

복제는 중복성을 제공하고 데이터 가용성을 높입니다. 서로 다른 데이터베이스 서버에 여러 개의 데이터 복사본이 있는 경우, 복제는 단일 데이터베이스 서버의 손실에 대비한 내결함성 수준을 제공합니다.

일부 경우에는 클라이언트가 읽기 작업을 다른 서버로 보낼 수 있으므로 복제를 통해 읽기 용량이 증가할 수 있습니다. 여러 데이터 센터에 데이터 복제본을 유지하면 분산된 애플리케이션의 데이터 지역성과 가용성이 향상될 수 있습니다. 재해 복구, 보고 또는 백업과 같은 전용 목적을 위해 추가 복사본을 유지 관리할 수도 있습니다.

MongoDB에서의 복제

복제본 세트는 동일한 데이터 세트를 유지하는 mongod 인스턴스 그룹입니다. 복제본 세트에는 여러 개의 데이터 보유 노드와 선택적으로 하나의 중재자 노드가 포함됩니다. 데이터 보유 노드 중 단 하나의 구성원만이 프라이머리 노드로 간주되고, 다른 노드는 세컨더리 노드로 간주됩니다.

프라이머리 노드는 모든 쓰기 작업을 수신합니다. 복제본 세트에는 { w: "majority" } 쓰기 고려로 쓰기를 확인할 수 있는 프라이머리가 하나만 있을 수 있지만, 경우에 따라 다른 mongod 인스턴스가 일시적으로 자신을 프라이머리로 간주할 수도 있습니다. [1] 프라이머리는 데이터 세트에 대한 모든 변경 사항을 작업 로그, 즉 oplog에 기록합니다. 프라이머리 노드 작업에 대한 자세한 내용은 복제본 세트 프라이머리를 참조하세요.

클릭하여 확대

세컨더리는 프라이머리의 oplog를 복제하고 작업을 데이터 세트에 적용하여 세컨더리의 데이터 세트가 프라이머리의 데이터 세트를 반영하도록 합니다. 만약 프라이머리를 사용할 수 없다면, 적격 세컨더리는 투표를 실시하여 자신을 새로운 프라이머리로 선출합니다. 세컨더리 구성원에 대한 자세한 내용은 복제본 세트 세컨더리 멤버를 참조하세요.

일부 상황(예: 프라이머리와 세컨더리를 보유 중이지만 비용 제약으로 인해 세컨더리를 추가할 수 없는 경우)에서는 복제본 세트에 mongod 인스턴스를 중재자로 추가하도록 선택할 수 있습니다. 중재자는 선거에 참여하지만 데이터를 보유하지 않습니다(즉, 데이터 중복성을 제공하지 않습니다). 중재자에 대한 자세한 내용은 복제본 세트 중재자를 참조하세요.

중재자는 항상 중재자 역할을 수행하지만, 선거 기간 중에는 프라이머리 후보가 물러나서 세컨더리 후보가 될 수도 있고 세컨더리 후보가 프라이머리 후보가 될 수도 있습니다.

비동기 복제

세컨더리는 프라이머리의 oplog를 복제하고 해당 데이터 세트에 비동기적으로 작업을 적용합니다. 세컨더리 데이터 세트가 기본 데이터 세트를 반영하도록 하면 한 명 이상의 구성원이 장애가 발생하더라도 복제본 세트가 계속 작동할 수 있습니다.

복제 메커니즘에 대한 자세한 내용은 복제본 세트 Oplog 및 복제본 세트 데이터 동기화를 참조하세요.

자동 페일오버

프라이머리가 electionTimeoutMillis의 시간(기본값은 10초)을 초과하여 세트의 다른 구성원과 통신하지 않으면 적격 세컨더리가 자신을 새 프라이머리로 지명하기 위한 투표를 요청합니다. 클러스터는 새로운 프라이머리 투표를 완료하고 정상 작업을 재개하려고 시도합니다.

클릭하여 확대

복제본 세트는 투표가 성공적으로 완료될 때까지 쓰기 작업을 처리할 수 없습니다. 프라이머리가 오프라인인 동안 이러한 쿼리가 세컨더리에서 실행되도록 구성된 경우 복제본 세트는 읽기 쿼리를 계속 제공할 수 있습니다.

클러스터가 새 프라이머리를 선택하기 전의 시간 중앙값은 기본값 replica configuration settings 을 가정할 때 일반적으로 12 초를 초과하지 않아야 합니다. 여기에는 프라이머리를 사용 불가 로 표시하고 투표 를 호출하여 완료하는 데 필요한 시간이 포함됩니다. settings.electionTimeoutMillis 복제 구성 옵션을 수정하여 이 기간을 조정할 수 있습니다. 네트워크 지연 시간과 같은 요인으로 인해 복제본 세트 투표가 완료되는 데 필요한 시간이 연장될 수 있으며, 이는 다시 프라이머리 없이 클러스터가 작동할 수 있는 시간에 영향을 미칩니다. 이러한 요인들은 특정 클러스터 아키텍처에 따라 달라집니다.

electionTimeoutMillis 복제 구성 옵션을 기본값 10000(10초)에서 낮추면 프라이머리 실패를 더 신속하게 탐지할 수 있습니다. 그러나 클러스터는 프라이머리가 정상적으로 작동하더라도 일시 네트워크 지연과 같은 요인으로 인해 투표를 더 자주 호출할 수 있습니다. 이로 인해 w : 1 쓰기 작업의 롤백이 증가할 수 있습니다.

애플리케이션 연결 로직에는 자동 페일오버 및 후속 투표에 대한 허용 범위가 포함되어야 합니다. MongoDB 드라이버는 프라이머리의 손실을 감지하고 특정 쓰기 작업을 한 번만 자동으로 재시도할 수 있으며, 자동 페일오버 및 투표에 대한 추가 기본 처리 기능을 제공합니다.

호환 가능한 드라이버는 기본적으로 재시도 가능 쓰기를 허용

MongoDB는 가장 최근에 액세스한 데이터로 투표 가능한 세컨더리 멤버의 캐시를 미리 워밍하기 위해 미러링된 읽기 를 제공합니다. 세컨더리의 캐시를 미리 워밍업하면 투표 후 성능을 더 빠르게 복원하는 데 도움이 될 수 있습니다.

MongoDB의 페일오버 프로세스에 대해 자세히 알아보려면 다음을 참조하세요.

• 복제본 세트 선거

• 재시도 가능한 쓰기

• 복제 세트 페일오버 중 롤백

읽기 작업

읽기 설정

기본적으로 클라이언트는 프라이머리[1]에서 읽지만, 클라이언트는 읽기 설정을 지정하여 읽기 작업을 세컨더리로 보낼 수 있습니다.

클릭하여 확대

세컨더리에 대한 비동기 복제 는 세컨더리에서 읽기가 프라이머리의 데이터 상태를 반영하지 않는 데이터를 반환할 수 있음을 의미합니다.

분산 트랜잭션 에 포함된 읽기 작업은 primary로 읽기 설정을 사용해야 합니다. 특정 트랜잭션의 모든 작업은 동일한 노드로 라우팅되어야 합니다.

복제본 세트에서의 읽기에 관한 자세한 내용은 읽기 설정을 참조하세요.

db.adminCommand( {
  setParameter: 1,
  mirrorReads: { samplingRate: 0.0 }
} )

db.serverStatus( { mirroredReads: 1 } )

트랜잭션

MongoDB 4.0부터는 복제본 세트에 대해 다중 문서 트랜잭션을 사용할 수 있습니다.

분산 트랜잭션 에 포함된 읽기 작업은 primary로 읽기 설정을 사용해야 합니다. 특정 트랜잭션의 모든 작업은 동일한 노드로 라우팅되어야 합니다.

트랜잭션이 커밋될 때까지 트랜잭션에서 변경된 데이터는 트랜잭션 외부에 표시되지 않습니다.

그러나 트랜잭션이 여러 샤드에 쓰기를 수행하는 경우, 모든 외부 읽기 작업이 커밋된 트랜잭션의 결과가 샤드 전체에 표시될 때까지 기다릴 필요는 없습니다. 예를 들어, 트랜잭션이 커밋되고 쓰기 1이 샤드 A에 표시되지만 쓰기 2가 샤드 B에 아직 표시되지 않는 경우, 읽기 고려 "local"의 외부 읽기는 쓰기 2를 보지 않고 쓰기 1의 결과를 읽을 수 있습니다.

변경 스트림

MongoDB 3.6부터는 복제본 세트와 샤드 클러스터에 대해 변경 스트림을 사용할 수 있습니다. 변경 스트림을 통해 애플리케이션은 복잡한 방식 및 oplog를 테일링하는 위험 없이 실시간 데이터 변경에 액세스할 수 있습니다. 애플리케이션은 변경 스트림을 사용하여 단일 또는 복수 컬렉션의 모든 데이터 변경 사항을 구독할 수 있습니다.

추가 기능

복제본 세트는 애플리케이션 요구 사항을 지원하기 위한 다양한 옵션을 제공합니다. 예를 들어, 여러 데이터 센터에 멤버가 있는 복제본 세트를 배포하거나 일부 멤버의 members[n].priority를 조정하여 투표 결과를 제어할 수 있습니다. 복제본 세트는 보고, 재해 복구 또는 백업 기능을 위한 전용 구성원도 지원합니다.

자세한 내용은 우선 순위가 0인 복제본 세트 멤버, 숨겨진 복제본 세트 멤버 및 지연된 복제본 세트 멤버를 참조하세요.