문서 메뉴
문서 홈
/
MongoDB 매뉴얼
/
MongoDB CRUD 운영

쓰기 고려

이 페이지의 내용

  • 쓰기 고려 사양
  • 자세한 내용은 암시적 기본 쓰기 고려를 참조하세요.
  • 승인 동작
  • 추가 정보

쓰기 고려는 독립형 mongod, 복제본 세트 또는 샤딩된 클러스터에 대한 쓰기 작업에 대해 MongoDB에서 요청하는 승인 수준을 설명합니다. 샤딩된 클러스터에서 mongos 인스턴스는 쓰기 고려를 샤드에 전달합니다.

참고

다중 문서 트랜잭션의 경우 개별 작업 수준이 아닌 트랜잭션 수준에서 쓰기 고려를 설정합니다. 트랜잭션에서 개별 쓰기 작업의 쓰기 고려를 명시적으로 설정하면 안 됩니다.

다중 문서 트랜잭션"majority" 에 대해 쓰기 고려를 지정하고 트랜잭션이 복제본 세트 구성원의 계산된 과반수 에 복제되지 못하면 트랜잭션이 복제본 세트 구성원에서 즉시 롤백되지 않을 수 있습니다.복제본 세트는 최종적으로 일관성을 갖 습니다. 트랜잭션은 항상 모든 복제본 세트 멤버에 적용되거나 롤백됩니다.

복제본 세트와 샤드 cluster는 글로벌 기본 쓰기 고려 (write concern) 설정을 지원합니다. 명시적인 쓰기 고려 (write concern)를 지정하지 않은 작업에는 글로벌 기본 쓰기 고려 (write concern) 설정이 적용됩니다. 자세한 내용은 setDefaultRWConcern 를 참조하세요.

MongoDB Atlas에서 호스팅되는 배포에 대한 쓰기 고려 설정에 대해 자세히 알아보려면 MongoDB Atlas 로 복원력이 뛰어난 애플리케이션 빌드를 참조하세요.

쓰기 고려 사양

쓰기 고려에는 다음 필드가 포함될 수 있습니다.

{ w: <value>, j: <boolean>, wtimeout: <number> }

  • w 옵션을 사용하여 쓰기 작업이 지정된 수의 mongod 인스턴스 또는 지정된 태그가 있는 mongod 인스턴스로 전파되었음을 확인 요청하는 데 사용할 수 있습니다.

  • j 옵션을 사용하여 쓰기 작업이 온디스크 저널에 기록되었다는 확인을 요청합니다.

  • 쓰기 작업이 무기한 차단되지 않도록 시간 제한을 지정하는 wtimeout 옵션을 사용할 수 있습니다.

w 옵션

w 옵션은 쓰기 작업이 지정된 개수의 mongod 인스턴스 또는 태그가 지정된 mongod 인스턴스로 전파되었음을 확인하도록 요청합니다. 쓰기 고려에 w 필드가 없는 경우, MongoDB는 w 옵션을 기본 쓰기 고려 설정으로 사용합니다.

참고

setDefaultRWConcern을 사용해 기본 쓰기 고려를 설정하는 경우, 반드시 w 필드 값을 지정해야 합니다.

w 옵션을 사용하면 다음과 같은 w: <value> 쓰기 고려를 사용할 수 있습니다.

값
설명
"majority"

쓰기 작업이 데이터 보유 투표 멤버의 계산된 과반수 (즉, members[n].votes 가 0 보다 큰 프라이머리 및 세컨더리)에 지속적으로 커밋되었음을 확인 요청합니다. { w: "majority" } 는 대부분 의 MongoDB 배포에 대한 기본 쓰기 고려입니다. 암시적 기본 쓰기 고려를 참조하세요.

예를 들어 3 개의 투표 멤버가 있는 복제본 세트인 프라이머리-세컨더리-세컨더리(PSS)를 생각해 보세요. 이 복제본 세트의 경우 계산된 과반수 는 2이며, 쓰기는 프라이머리와 하나의 세컨더리로 전파되어야 클라이언트에 쓰기 고려를 알릴 수 있습니다.

참고

가 members[n].votes 보다큰 Hidden , 지연 및 우선 순위 0 0 멤버는 쓰기 작업을 승인할 "majority" 수 있습니다.

지연된 세컨더리는 구성된 secondaryDelaySecs보다 이전에 완료된 쓰기 확인을 반환할 수 없습니다.

쓰기 작업이 클라이언트에 대한 w: "majority" 승인과 함께 반환된 후 클라이언트는 "majority" readConcern을 사용하여 해당 쓰기 결과를 읽을 수 있습니다.

다중 문서 트랜잭션 "majority" 에 대해 쓰기 고려를 지정하고 트랜잭션이 복제본 세트 멤버의 계산된 과반수 에 복제되지 못할 경우, 트랜잭션이 복제본 세트 멤버에서 즉시 롤백되지 않을 수 있습니다.복제본 세트는 최종적으로 일관성을 갖 습니다. 트랜잭션은 항상 모든 복제본 세트 멤버에 적용되거나 롤백됩니다.

인스턴스가 mongod 쓰기를 승인하는 경우 승인 동작 을 참조하세요.

<number>

쓰기 작업이 지정된 수의 mongod 인스턴스에 전파되었음을 확인 요청합니다. 예를 들면 다음과 같습니다.

w: 1

쓰기 작업이 독립형 mongod 또는 복제본 세트의 프라이머리로 전파되었음을 확인 요청합니다. 쓰기 작업이 세컨더리에 복제되기 전에 프라이머리가 강등되었을 경우 데이터가 롤백될 수 있습니다.

경고

쓰기 작업에서 { w: 1 } 쓰기 고려를 사용하는 경우, 쓰기 작업이 완료되기 전에 프라이머리가 다시 시작되면 롤백 디렉토리에서 oplog 홀 이후에 제출된 쓰기를 제외할 수 있습니다.

w: 0

쓰기 고려에 대한 확인을 요청하지 않습니다. 하지만 w: 0은 소켓 예외와 네트워킹 오류에 관한 정보를 애플리케이션에 반환할 수 있습니다. 쓰기 작업이 세컨더리에 복제되기 전에 프라이머리가 강등되었을 경우 데이터가 롤백될 수 있습니다.

을 지정했지만 w: 0 j: true mongod 포함하는 경우 독립형 또는 복제본 세트의 프라이머리에서 승인을 요청하는 데 j:true 가 우선합니다.

w ~ 값이 1보다 큰 경우, 지정된 쓰기 고려를 충족하기 위해 프라이머리와 필요한 만큼의 데이터를 포함하는 세컨더리로부터 확인이 필요합니다. 쓰기 고려 임곗값을 충족하기 위해 세컨더리가 꼭 투표 구성원일 필요는 없습니다.

예를 들어, 1개의 프라이머리와 2개의 세컨더리가 있는 3개의 멤버를 가진 복제본 세트가 있다고 가정해 봅시다. w: 2를 지정하려면 프라이머리와 2개의 세컨더리 중 하나로부터 확인이 필요합니다. w: 3을 지정하면 프라이머리와 모든 세컨더리의 확인이 필요합니다.

참고

Hidden, 지연 및 우선 순위 0 멤버는 w: <number> 쓰기 작업을 승인할 수 있습니다.

지연된 세컨더리는 구성된 secondaryDelaySecs보다 이전에 완료된 쓰기 확인을 반환할 수 없습니다.

인스턴스가 mongod 쓰기를 승인하는 경우 승인 동작 을 참조하세요.

<custom write concern name>

쓰기 작업이 settings.getLastErrorModes에 정의된 사용자 지정 쓰기 고려를 충족하는 tagged 멤버에 전파되었음을 확인 요청합니다. 예시는 사용자 지정 멀티 데이터 센터 쓰기 고려를 참조하세요.

사용자 지정 쓰기 고려가 프라이머리의 인정만을 요구하고, 쓰기 작업이 세컨더리에 복제되기 전에 프라이머리가 강등되었을 경우 데이터가 롤백될 수 있습니다.

인스턴스가 mongod 쓰기를 승인하는 경우 승인 동작 을 참조하세요.

팁

다음도 참조하세요.

j 옵션

j 옵션은 MongoDB에 쓰기 작업이 온디스크 저널에 작성되었음을 확인 요청합니다.

j

인 j: true 경우,mongod w: 에 지정된 <value>인스턴스가 온디스크 저널에 기록했음을 확인 요청합니다. j: true 는 그 자체로는 복제본 세트 프라이머리 페일오버로 인해 쓰기가 롤백되지 않는다고 보장하지 않습니다.

버전 3.2에서 변경됨: j: true로 설정하면 MongoDB는 프라이머리를 비롯해 요청된 수의 멤버가 저널에 쓰기를 완료한 후에만 반환합니다. 이전 버전의 경우, 복제본 세트에 있는 j: true 쓰기 고려는 w: <value> 쓰기 고려와 관계없이 프라이머리만 저널에 쓰도록 요구했습니다.

참고

  • 저널링 없이 실행되는 mongod 인스턴스에 j: true를 포함하는 쓰기 고려를 지정하면 오류가 발생합니다.

  • 저널링이 활성화된 경우 w: "majority" 는 j: true 를 의미할 수 있습니다. writeConcernMajorityJournalDefault 복제본 세트 구성 설정에 따라 동작이 결정됩니다. 자세한 내용은 승인 동작 을 참조하세요.

  • j: true를 포함하거나 암시하는 쓰기 고려는 즉시 저널 동기화를 유발합니다. 자세한 내용은 저널링 프로세스를 참조하세요.

wtimeout

이 옵션은 쓰기 고려의 시간제한을 밀리초 단위로 지정합니다. wtimeout은 w가 1보다 큰 경우에만 적용됩니다.

wtimeout 은 필요한 쓰기 고려가 최종적으로 성공하더라도 지정된 제한 시간이 경과한 후에 쓰기 작업을 오류와 함께 반환하도록 합니다. 이러한 쓰기 고려가 반환되면 MongoDB는 쓰기 고려가 wtimeout 시간 제한을 초과하기 전에 수행된 성공적인 데이터 수정을 되돌리지 않습니다.

wtimeout 옵션을 지정하지 않았고 쓰기 고려 수준을 달성할 수 없는 경우, 쓰기 작업은 무기한으로 차단됩니다. wtimeout 값을 0으로 지정하면 wtimeout 옵션이 없는 쓰기 고려와 동일해집니다.

자세한 내용은 암시적 기본 쓰기 고려를 참조하세요.

MongoDB 5 부터 시작.0, 암시적 기본 쓰기 고려 는 w: majority 입니다. 그러나 중재자가 포함된 배포의 경우 특별히 고려해야 할 사항이 있습니다.

  • 복제 세트의 투표 과반수는 1에 투표 회원 수의 절반을 반올림한 값입니다. 데이터를 포함하는 투표 구성원의 수가 투표 과반수보다 많지 않은 경우 기본 쓰기 문제는 { w: 1 } 입니다.

  • 다른 모든 시나리오에서 기본 쓰기 우려는 { w: "majority" }입니다.

특히 MongoDB는 다음 공식을 사용하여 기본 쓰기 문제를 결정합니다.

if [ (#arbiters > 0) AND (#non-arbiters <= majority(#voting-nodes)) ]
    defaultWriteConcern = { w: 1 }
else
    defaultWriteConcern = { w: "majority" }

예를 들어 다음 배포와 해당 기본 쓰기 문제를 고려해보세요.

비중재인
중재자
투표 노드
과반수 투표 노드
자세한 내용은 암시적 기본 쓰기 고려를 참조하세요.
2
1
3
2
{ w: 1 }
4
1
5
3
{ w: "majority" }

  • 첫 번째 예제에서는

    • 총 3개의 투표 노드에는 2명의 비중재자와 1명의 중재자가 있습니다.

    • 투표 노드의 대다수(1 + 3의 절반, 반내림)는 2입니다.

    • 비중재자 수(2)는 대다수의 투표 노드(2)와 동일하므로 { w: 1 } 의 암시적 쓰기 문제가 발생합니다.

  • 두 번째 예제에서는

    • 총 5개의 투표 노드에는 4명의 비중재자와 1명의 중재자가 있습니다.

    • 투표 노드의 대다수(1 + 5의 절반, 반내림)는 3입니다.

    • 비 중재자 (4) 의 수가 투표 노드 (3) 의 과반수보다 많아서 암묵적인 쓰기 문제가 { w: "majority" } 발생합니다.

승인 동작

w 옵션과 j 옵션은 mongod 인스턴스가 쓰기 작업을 승인하는 시기를 결정합니다.

독립형

독립형 mongod는 메모리에 쓰기를 적용하거나 디스크 저널에 쓰기를 완료한 후 쓰기 작업을 확인합니다. 다음 표에는 독립형의 확인 동작과 관련된 쓰기 고려가 설명되어 있습니다.

j 는 지정되지 않음
j:true
j:false
w: 1
inMemory
온디스크 저널
inMemory
w: "majority"
저널링을 사용하여 실행하는 경우 온디스크 저널
온디스크 저널
inMemory

참고

writeConcernMajorityJournalDefault false 로 설정하면 MongoDB는 w: "majority" 쓰기가 디스크 저널에 기록될 때까지 기다리지 않고 쓰기를 승인합니다. 따라서 지정된 복제본 세트에 있는 대부분의 노드가 일시적으로 손실(예: 충돌 및 재시작)되는 경우 "majority" 쓰기 작업이 롤백될 수 있습니다.

복제본 세트

w 에 지정된 값은 성공을 반환하기 전에 쓰기를 확인해야 하는 복제본 세트 멤버의 수를 결정합니다. 각 적격 복제본 세트 멤버에 대해 j 옵션은 멤버가 메모리에 쓰기 작업을 적용한 후 또는 디스크 저널에 쓴 후 쓰기를 승인할지 여부를 결정합니다.

w: "majority"

복제본 세트의 모든 데이터 보유 투표 멤버는 "majority" 쓰기 작업의 쓰기 승인에 기여할 수 있습니다.

다음 표에는 멤버가 j 값에 따라 쓰기를 확인할 수 있는 시점이 제시되어 있습니다.

j 는 지정되지 않음

확인은 writeConcernMajorityJournalDefault의 값에 따라 달라집니다.

  • true인 경우, 확인에는 온디스크 저널에 수행된 쓰기 작업이 필요합니다(j: true).

    writeConcernMajorityJournalDefault 기본값 true

  • false인 경우, 확인에는 메모리에 수행된 쓰기 작업이 필요합니다(j: false).

j: true
확인에는 온디스크 저널에 수행된 쓰기 작업이 필요합니다.
j: false
확인에는 메모리에 수행된 쓰기 작업이 필요합니다.

참고

동작에 대한 자세한 내용은 w: "majority" 동작을 참조하세요.

w: <number>

데이터를 가지고 있는 복제본 세트의 모든 멤버는 w: <number> 쓰기 작업의 쓰기 확인에 기여할 수 있습니다.

다음 표에는 멤버가 j 값에 따라 쓰기를 확인할 수 있는 시점이 제시되어 있습니다.

j 는 지정되지 않음
확인에는 메모리에 수행된 쓰기 작업이 필요합니다(j: false).
j: true
확인에는 온디스크 저널에 수행된 쓰기 작업이 필요합니다.
j: false
확인에는 메모리에 수행된 쓰기 작업이 필요합니다.

참고

Hidden, 지연 및 우선 순위 0 멤버는 w: <number> 쓰기 작업을 승인할 수 있습니다.

지연된 세컨더리는 구성된 secondaryDelaySecs보다 이전에 완료된 쓰기 확인을 반환할 수 없습니다.

추가 정보

인과적으로 일관된 세션 및 쓰기 고려

인과적으로 일관된 클라이언트 세션의 경우, 클라이언트 세션은 다음과 같은 경우에만 인과적 일관성을 보장합니다.

  • 관련된 읽기 작업은 "majority" 읽기 고려를 사용합니다.

  • 연결된 쓰기 작업은 "majority" 쓰기 고려를 사용합니다.

자세한 내용은 인과적 일관성을 참조하세요.

w: "majority" 행동

  • writeConcernMajorityJournalDefault false 로 설정하면 MongoDB는 w: "majority" 쓰기가 디스크 저널에 기록될 때까지 기다리지 않고 쓰기를 승인합니다. 따라서 지정된 복제본 세트에 있는 대부분의 노드가 일시적으로 손실(예: 충돌 및 재시작)되는 경우 "majority" 쓰기 작업이 롤백될 수 있습니다.

  • 가 members[n].votes 보다큰 Hidden , 지연 및 우선 순위 0 0 멤버는 쓰기 작업을 승인할 "majority" 수 있습니다.

    • 지연된 세컨더리는 구성된 secondaryDelaySecs보다 이전에 완료된 쓰기 확인을 반환할 수 없습니다.

  • MongoDB 5.0부터 STARTUP2 상태의 복제본 집합 멤버는 쓰기 과반수에 참여하지 않습니다.

local 데이터베이스에서는 쓰기 고려 지원 불가

로컬 데이터베이스는 쓰기 고려를 지원하지 않습니다. MongoDB는 로컬 데이터베이스의 컬렉션에서의 작업에 대해 구성된 쓰기 고려를 자동으로 무시합니다.

쓰기 고려에 대한 과반수 계산

팁

rs.status() 는 계산된 과반수가 포함된 writeMajorityCount 필드를 반환합니다.

쓰기 고려 "majority" 의 과반수는 다음 값 중 더 작은 값으로 계산됩니다.

  • 모든 투표 멤버의 과반수(중재자 포함)와

  • 데이터를 보유한 모든 투표 멤버 수의 비교입니다.

경고

계산된 과반수가 데이터를 보유 하는 모든 투표 멤버 수와 동일한 경우(예: 31차-세컨더리-중재자 배포의 경우) 쓰기 고려 "majority" 는 다음과 같은 경우 시간 초과되거나 승인되지 않을 수 있습니다. 데이터 보유 투표 멤버가 다운되었거나 연결할 수 없습니다. 가능하면 중재자 대신 데이터를 보유한 투표 멤버를 사용하세요.

예를 들어 다음과 같이 생각해 보세요.

  • 3개의 투표 구성원, P-S-S(프라이머리-세컨더리-세컨더리)가 있는 복제본 세트:

    • 모든 투표 멤버의 과반수는 2명입니다.

    • 모든 데이터 보유 투표 멤버의 수는 3명입니다.

    계산된 과반수는 2 이고 최소값은 2 과 3 입니다. 쓰기 고려 "majority" 를 클라이언트에 확인하려면 쓰기가 프라이머리와 세컨더리 중 하나에 전파되어야 합니다.

  • 복제본 세트에는 투표 멤버 3명이 있으며, 프라이머리-세컨더리-중재자(P-S-A)입니다.

    • 모든 투표 멤버의 과반수는 2명입니다.

    • 데이터를 보유한 모든 투표 멤버 수는 2입니다.

    계산된 과반수는 2 이고 최소값은 2 과 2 입니다. 쓰기는 데이터를 보유한 멤버에게만 적용할 수 있으므로 쓰기를 프라이머리 멤버와 세컨더리 멤버로 전파해야 클라이언트에 쓰기 고려 "majority" 을 알릴 수 있습니다.

    팁

    (PSA) 또는 모든 데이터 보유 투표 멤버가 쓰기를 승인할 수 있어야 하는 기타 토폴로지에서는 "majority" 쓰기 고려를 사용하지 않도록 합니다. "majority" 쓰기 고려를 사용할 때 내구성이 보장되기를 원하는 고객은 대신 모든 데이터를 보유한 투표 멤버를 사용할 필요가 없는 토폴로지(예: PSS)를 배포해야 합니다.

경고

복제본 세트에 두 개 이상의 중재자를 배치하지 마세요. 복수 중재자 관련 우려 사항을 참조하세요.

기존 레플리카 세트에 중재자를 추가하려면 다음과 같이 하세요:

  • 일반적으로 복제본 세트에 데이터를 보유하는 멤버가 두 개 이하인 경우 먼저 복제본 세트에 대한 클러스터 전체 쓰기 우려를 설정해야 할 수 있습니다.

  • 클러스터 전체 쓰기 우려를 설정해야 하는 이유에 대한 자세한 내용은 클러스터 전체 쓰기 우려를 참조하세요.

중재자로 새로운 복제 세트를 시작하기 전에 클러스터 전체의 쓰기 고려 설정을 변경할 필요는 없습니다.

팁

다음도 참조하세요.

기본 쓰기 관심사 공식

우려 사항 출처 작성

MongoDB는 특정 쓰기 고려 (write concern) provenance의 출처를 추적합니다. getLastError 지표, 쓰기 고려 (write concern) 오류 객체 및 MongoDB 로그에 provenance 가 표시될 수 있습니다.

다음 표는 가능한 쓰기 고려 provenance 의 값과 그 중요성을 보여줍니다.

출처
설명
clientSupplied
쓰기 우려 사항은 애플리케이션에서 지정되었습니다.
customDefault
쓰기 고려는 사용자 정의된 기본값에서 비롯된 것입니다. setDefaultRWConcern을 참조하십시오.
getLastErrorDefaults
쓰기 고려는 복제본 세트의 settings.getLastErrorDefaults 필드에서 발생했습니다.
implicitDefault
쓰기 고려는 다른 모든 쓰기 고려 사양이 없는 상태에서 서버에서 발생했습니다.

쿼럼 커밋과 대조되는 쓰기 고려

쿼럼 커밋 과 쓰기 고려 간에는 중요한 차이점이 있습니다.

  • 인덱스 빌드는 쿼럼 커밋 사용합니다.

  • 쓰기 작업은 쓰기 고려 사용합니다.

클러스터 내의 각 데이터 보유 노드는 투표권을 가진 노드입니다.

'쿼럼 커밋'은 동시 인덱스 빌드를 커밋하기 위해 준비해야 하는 데이터 보유 투표 멤버의 수 또는 프라이머리를 포함한 특정 투표 멤버를 지정하며, 이는 프라이머리가 커밋을 실행하기 전에 수행됩니다.

쓰기 고려는 쓰기 작업이 지정된 수의 인스턴스로 전파되었다는 확인 수준입니다.

커밋 쿼럼 프라이머리는 프라이머리가 인덱스 빌드를 커밋하기 전에 인덱스 빌드를 완료할 준비가 되어 있어야 하는 노드 수를 지정합니다. 반대로 프라이머리에서 인덱스 빌드를 커밋한 경우 쓰기 고려가 명령이 반환되기 전에 인덱스 빌드를 완료해야 하는 노드 수를 지정합니다.

← readConcern "snapshot"
라이프사이클 다이어그램 쓰기 →

이 페이지의 내용