Docs Menu
Docs Home
/
MongoDB 매뉴얼
/
CRUD 작업

쓰기 고려

이 페이지의 내용

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

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

참고

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

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

복제본 세트와 샤딩된 클러스터는 글로벌 기본 쓰기 고려 설정을 지원합니다. 명시적인 쓰기 고려가 지정되지 않은 작업에는 글로벌 기본 쓰기 고려 설정이 적용됩니다. 자세한 내용은 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"

데이터를 보유한 투표 멤버의 계산된 다수가 로컬 oplog에 변경 사항을 영구적으로 작성했다는 확인을 요청합니다. 그런 다음 멤버는 로컬 oplogs에서 읽을 때 변경 사항을 비동기적으로 적용합니다.

8.0 버전 변경 사항: MongoDB는 이전 릴리스에서처럼 멤버가 변경 사항을 적용할 때까지 기다리지 않고 쓰기를 승인합니다.

복제본 세트의 데이터를 보유한 투표 멤버는 프라이머리 멤버 그리고 members[n].votes가 0보다 큰 모든 세컨더리 멤버를 말합니다.

자세한 내용은 { w: "majority" } 쓰기 후 읽기를 참조하세요.

{ w: "majority" } 대부분의 MongoDB 배포에 대한 기본 쓰기 고려입니다. 자세한 내용은 암시적 기본 쓰기 고려를 참조하세요.

예를 들어, 투표권이 있는 노드가 3인 복제본 세트, 즉 프라이머리-세컨더리-세컨더리(P-S-S)가 있다고 고려합니다. 이 복제본 세트의 경우 계산된 과반수는 2이며, 쓰기는 프라이머리와 하나의 세컨더리의 oplog로 전파되어야 클라이언트에게 쓰기 고려를 알릴 수 있습니다.

members[n].votes가 0보다 크고 숨겨지거나, 지연되거나, 우선순위가 0인 멤버는 "majority" 쓰기 작업을 확인할 수 있습니다.

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

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

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

어떤 조건에서 mongod 인스턴스가 쓰기를 인정하는지는 인정 행동을 참조하여 확인하세요.

<number>

쓰기 작업이 지정된 수의 mongod 인스턴스에 전파되었음을 확인 요청합니다. 예시:

w: 1

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

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

w: 0

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

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

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

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

숨겨지거나, 지연되거나, 우선순위 0인 멤버는 w: <number> 쓰기 작업을 확인할 수 있습니다.

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

어떤 조건에서 mongod 인스턴스가 쓰기를 인정하는지는 인정 행동을 참조하여 확인하세요.

<custom write concern name>

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

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

어떤 조건에서 mongod 인스턴스가 쓰기를 인정하는지는 인정 행동을 참조하여 확인하세요.

팁

다음도 참조하세요.

j 옵션

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

j

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

j: true 을 사용하면 MongoDB 는 프라이머리 를 포함하여 요청된 수의 멤버가 저널 에 쓴 후에만 반환합니다. 이전에는 복제본 세트 의 쓰기 j: true 고려 (write concern) 가w: 쓰기 고려 (write concern) <value> 에 관계없이 프라이머리 저널 에 쓰기 (write) 만 요구했습니다.

참고

  • 저널링 없이 실행되는 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" }

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

Non-Arbiters
중재자
투표 노드
과반수 투표 노드
자세한 내용은 암시적 기본 쓰기 고려를 참조하세요.
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
On-disk journal
inMemory
w: "majority"
저널링을 사용하여 실행하는 경우 온디스크 저널
On-disk journal
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

확인에는 메모리에 수행된 쓰기 작업이 필요합니다.

일반적으로 j: false 이 설정하다 경우 디스크 상의 저널 에 작업을 쓸 필요가 없습니다. 그러나 writeConcernMajorityJournalDefault: true 이 설정하다 있으면 j: false 이 설정하다 있더라도 저널 에 작업을 기록해야 합니다.

j: false 및 writeConcernMajorityJournalDefault: true 이 설정하다 되면 쓰기 (write) 작업이 저널 에 비동기적으로 기록됩니다.

  • w: majority 이 설정하다 쓰기는 저널 이 디스크로 플러시될 때까지 완료된 것으로 확인되지 않습니다.

  • w: majority 쓰기는 j 설정에 관계없이 "majority" 읽기 스냅샷 이 완료될 때까지 기다립니다. 이는 writeConcernMajorityJournalDefault: true 로 설정하다 되면 대다수 읽기 스냅샷 이 대부분의 저널링된 쓰기를 기반으로 하기 때문입니다.

  • 쓰기 (write) 작업이 클라이언트 애플리케이션 에 w: majority 승인과 함께 반환된 후 majority 읽기 고려 (read concern) 가 설정하다 있으면 애플리케이션 에서 쓰기 (write) 결과를 읽을 수 있습니다.

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

w: <number>

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

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

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

참고

숨겨지거나, 지연되거나, 우선순위 0인 멤버는 w: <number> 쓰기 작업을 확인할 수 있습니다.

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

{ w: "majority" } 쓰기 후 읽기

MongoDB 8.0, { w: "majority" } 쓰기는 대다수의 데이터 보유 멤버가 oplog 항목을 안정적으로 작성한 후 승인을 반환합니다. 그런 다음, 멤버들은 로컬 oplog에서 변경 사항을 읽으면서 비동기적으로 적용합니다. 이전 릴리스에서 MongoDB는 멤버가 쓰기를 적용할 때까지 기다렸다가 승인을 반환했습니다.

{ w: "majority" } 쓰기 직후에 세컨더리 데이터베이스에 대한 쿼리는 승인을 반환하고 세컨더리 데이터베이스가 쓰기에서 변경 사항을 적용하기 전에 컬렉션에서 읽을 수 있습니다.

애플리케이션이 세컨더리에서 읽고 { w: "majority" } 쓰기에서 변경된 사항에 즉시 액세스해야 하는 경우 이러한 작업을 인과적 일관성 세션에서 실행하세요.

추가 정보

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

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

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

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

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

w: "majority" 행동

데이터베이스에서 쓰기 고려가 local 지원되지 않음

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

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

팁

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

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

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

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

경고

계산된 과반수가 데이터를 가진 모든 투표 구성원의 수와 동일한 상황(3개의 구성원을 가진 프라이머리-세컨더리-중재자 배포에서 등)에서, 데이터를 가진 투표 구성원이 다운되거나 접근할 수 없는 경우 쓰기 고려 "majority"(은)는 타임아웃되거나 인정되지 않을 수 있습니다. 가능하다면 중재자 대신 데이터를 가진 투표 구성원을 사용하세요.

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

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

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

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

    The calculated majority is 2, the minimum of 2 and 3. The write must propagate to the primary and one of the secondaries to acknowledge the write concern "majority" to the client.

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

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

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

    The calculated majority is 2, the minimum of 2 and 2. Since the write can only be applied to data-bearing members, the write must propagate to the primary and the secondary to acknowledge the write concern "majority" to the client.

    팁

    데이터를 보유한 모든 투표권 있는 멤버가 쓰기를 승인할 수 있어야 하는 (P-S-A) 또는 기타 토폴로지에 "majority" 쓰기 고려를 사용하지 마세요. "majority" 쓰기 고려를 사용할 때 내구성이 보장되기를 원하는 고객은 대신 P-S-S와 같이 모든 데이터 보유 투표 멤버를 사용할 필요가 없는 토폴로지를 사용해야 합니다.

경고

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

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

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

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

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

팁

다음도 참조하세요.

기본 쓰기 관심사 공식

우려 사항 출처 작성

MongoDB는 특정 쓰기 고려의 원인을 나타내는 쓰기 고려 provenance를 추적합니다. provenance는 getLastError 메트릭, 읽기 고려 오류 객체, MongoDB 로그에 표시됩니다.

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

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

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

쿼럼 커밋과 쓰기 고려(write concern) 간에는 다음과 같은 중요한 차이점이 있습니다.

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

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

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

커밋 쿼럼은 프라이머리 멤버를 포함하여 몇 개의 데이터 보유 투표 멤버 또는 어떤 투표 멤버가 동시 인덱스 빌드를 커밋할 준비가 되어 있어야 하는지를 지정합니다. 이 준비가 완료되면 프라이머리 멤버가 커밋을 실행합니다.

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

8.0 버전 변경 사항: 커밋 쿼럼은 프라이머리가 인덱스 빌드를 커밋하기 전에 인덱스 빌드를 완료할 준비가 되어 있어야 하는 노드 수를 지정합니다. 반대로 프라이머리가 인덱스 빌드를 커밋한 경우 쓰기 고려는 명령이 성공을 반환하기 전에 인덱스 빌드 oplog 항목을 복제해야 하는 노드 수를 지정합니다.

이전 릴리스에서는 프라이머리가 인덱스 빌드를 커밋했을 때 쓰기 고려가 명령이 성공적으로 반환되기 전에 인덱스 빌드를 완료해야 하는 노드 수를 지정했습니다.

돌아가기

"snapshot"

다음

라이프사이클 다이어그램