/ /

쓰기 고려

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

참고

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

복제본 세트와 샤딩된 클러스터는 글로벌 기본값 쓰기 고려 (write concern) 지원 . 명시적인 쓰기 고려 (write concern) 없는 작업은 전역 기본값 상속합니다. 기본값 전역 쓰기 고려 (write concern) 대다수입니다. 자세한 내용은 setDefaultRWConcern 를 참조하세요.

MongoDB Atlas에서 호스팅되는 배포서버에 대한 쓰기 고려 설정에 대해 자세히 알아보려면 MongoDB Atlas로 복원력 있는 애플리케이션 구축을 참조하세요.

쓰기 고려 사양

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

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

w: Requests acknowledgment that the write operation has propagated to a specified number of mongod instances or to mongod instances with specified tags.
j: Requests acknowledgment that the write operation has been written to the on-disk journal.
wtimeout: Specifies a time limit to prevent write operations from blocking indefinitely.

`w` 옵션

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

참고

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

w 옵션은 다음과 같은 w: <value> 쓰기 고려 (write concern)를 지원합니다.

값	설명
`"majority"`	데이터를 보유한 투표 멤버의 계산된 과반수가 로컬 oplog에 변경 사항을 영구적으로 작성했다는 확인을 요청합니다. 그런 다음 멤버는 로컬 oplogs에서 읽을 때 변경 사항을 비동기적으로 적용합니다. 복제본 세트의 데이터를 보유한 투표 멤버는 프라이머리 멤버 그리고 `members[n].votes`가 `0`보다 큰 모든 세컨더리 멤버를 말합니다. 자세한 내용은 { w: "majority" } 쓰기 후 읽기를 참조하세요. `{ w: "majority" }` 대부분의 MongoDB 배포에 대한 기본 쓰기 고려입니다. 자세한 내용은 암시적 기본 쓰기 고려를 참조하세요. 예시 들어 개의 투표 멤버가 있는 복제본 세트 3 프라이머리-세컨더리-세컨더리(PSS)를 생각해 보세요. 이 복제본 세트 의 경우 2 계산된 과반수는 이며, 쓰기 (write) 프라이머리 oplog와 하나의 세컨더리 oplog로 전파되어 클라이언트 에 쓰기 고려 (write concern) 확인합니다. 가 `members[n].votes` 보다 큰 숨겨진, 지연 및 우선 순위 0 `0` 멤버는 쓰기 (write) 작업을 `"majority"` 승인할 수 있습니다. 지연된 세컨더리는 구성된 `secondaryDelaySecs`보다 이전에 완료된 쓰기 확인을 반환할 수 없습니다. If you specify a `"majority"` write concern for writes and the operation does not replicate to the calculated majority of replica set members before it returns a response, then the data eventually replicates or rolls back. See `wtimeout`. See Acknowledgment Behavior for when `mongod` instances acknowledge the write.
`<number>`	쓰기 작업이 지정된 수의 `mongod` 인스턴스에 전파되었음을 확인 요청합니다. 예시: `w: 1` 쓰기 (write) 작업이 독립형 `mongod` 또는 복제본 세트 의 프라이머리 머리로 전파되었음을 확인 요청합니다. 쓰기 (write) 작업이 세컨더리에 복제되기 전에 프라이머리 머리가 강등된 경우 데이터가 롤백 될 수 있습니다. WARNING: If write operations use `{ w: 1 }` write concern, the rollback directory may exclude writes submitted after an oplog hole if the primary restarts before the write operation completes. `w: 0` 쓰기 (write) 작업에 대한 승인을 요청하지 않습니다. 그러나 `w: 0` 은(는) 소켓 예외 및 네트워킹 오류에 대한 정보를 애플리케이션 에 반환할 수 있습니다. 쓰기 (write) 작업이 세컨더리에 복제되기 전에 프라이머리가 다운되면 데이터는 롤백될 수 있습니다. If you specify `w: 0` but include j: true, j: true prevails to request acknowledgment from the standalone `mongod` or the primary of a replica set. `w` 1 보다 크면 지정된 쓰기 고려 (write concern) 충족하는 데 필요한 만큼의 프라이머리 및 세컨더리로부터 승인을 받아야 합니다. 쓰기 고려 (write concern) 곗값을 충족하기 위해 세컨더리가 꼭 투표 멤버일 필요는 없습니다. 예시 들어 프라이머리 및 2 세컨더리가 있는 3노드 복제본 세트 가정해 보겠습니다. `w: 2` 를 지정하려면 프라이머리 와 하나의 세컨더리 승인이 필요합니다. `w: 3` 를 지정하려면 프라이머리 와 두 세컨더리의 확인이 필요합니다. 숨겨진, 지연 및 우선 순위 0 멤버는 쓰기 (write) 작업을 `w: <number>` 승인할 수 있습니다. 지연된 세컨더리는 구성된 `secondaryDelaySecs`보다 이전에 완료된 쓰기 확인을 반환할 수 없습니다. See Acknowledgment Behavior for when `mongod` instances acknowledge the write.
`<custom write concern name>`	쓰기 작업이 `settings.getLastErrorModes`에 정의된 사용자 지정 쓰기 고려를 충족하는 `tagged` 멤버에 전파되었음을 확인 요청합니다. 예시는 사용자 지정 멀티 데이터 센터 쓰기 고려를 참조하세요. 사용자 지정 쓰기 고려 (write concern) 가 프라이머리 의 승인만 필요로 하고 쓰기 (write) 작업이 세컨더리에 복제되기 전에 프라이머리 머리가 강등된 경우 데이터가 롤백 할 수 있습니다. See Acknowledgment Behavior for when `mongod` instances acknowledge the write.

팁

`j` 옵션

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

j

If j: true, requests acknowledgment that the mongod instances, as specified in the w: <value>, have written to the on-disk journal. j: true alone does not guarantee that the write will not roll back due to replica set primary failover.

With j: true, MongoDB returns only after the requested number of members, including the primary, have written to the journal. Previously j: true write concern in a replica set only requires the primary to write to the journal, regardless of the w: <value> write concern.

참고

저널링 없이 실행 mongod 인스턴스에 j: true 가 포함된 쓰기 고려 (write concern) 지정하면 오류가 발생합니다.
If journaling is enabled, w: "majority" may imply j: true. The writeConcernMajorityJournalDefault replica set configuration setting determines the behavior. See Acknowledgment Behavior for details.
j: true를 포함하거나 암시하는 쓰기 고려는 즉시 저널 동기화를 유발합니다. 자세한 내용은 저널링 프로세스를 참조하세요.

`wtimeout`

이 옵션은 프라이머리 에서 작업이 성공한 후 쓰기 고려 (write concern) 달성할 수 있을 만큼 쓰기 (write) 작업이 충분한 멤버에 전파되는 데 걸리는 시간 제한(밀리초)을 지정합니다. w 이 1보다 작거나 같은 경우 wtimeout 은 적용 되지 않습니다. 쓰기 (write) 작업이 이 시간 제한 내에 쓰기 고려 (write concern) 달성하지 못하면 MongoDB 쓰기 고려 (write concern) 오류를 반환합니다.

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

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

참고

프라이머리 쓰기 (write) 작업에 시간 제한을 설정하다 하려면 maxTimeMS() 메서드를 사용합니다.

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

The implicit default write concern is w: majority. w: majority ensures write durability by requiring replica sets to wait for on-disk journaling by default, controlled by writeConcernMajorityJournalDefault. However, there is an edge case for replica set deployments containing arbiters:

복제 세트의 투표 과반수는 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" } 발생합니다.

On a sharded cluster, DDL (Data Definition Language) operations run with write concern "majority". If you specify a different write concern, the operation overrides the provided write concern with "majority".

승인 동작

The w option and the j option determine when mongod instances acknowledge write operations.

독립형

독립형 mongod 는 메모리에 쓰기 (write) 적용하거나 디스크 저널에 쓴 후 쓰기 (write) 작업을 확인합니다. 다음 표에는 관련 쓰기 (write) 고려와 함께 독립형 의 확인 동작이 나열되어 있습니다.

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

참고

With writeConcernMajorityJournalDefault set to false, MongoDB does not wait for w: "majority" writes to be written to the on-disk journal before acknowledging the writes. As such, "majority" write operations could possibly roll back in the event of a transient loss (e.g. crash and restart) of a majority of nodes in a given replica set.

복제본 세트

The w value determines the number of replica set members that must acknowledge the write before returning success. For each eligible member, the j option determines whether the member acknowledges writes after applying the write in memory or after writing to the on-disk journal.

w: "majority"

Any data-bearing voting member of the replica set can contribute to write acknowledgment of "majority" write operations.

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

`j` 는 지정되지 않음	확인은 `writeConcernMajorityJournalDefault`의 값에 따라 달라집니다. `true`인 경우 승인은 MongoDB 쓰기를 `j: true`에 해당하는 온디스크 저널 에 동기화하여 쓰기를 지속형 만들어야 합니다. `writeConcernMajorityJournalDefault` 기본값 `true` `false`인 경우 확인에는 메모리에 쓰기 작업이 필요하며, 이는 `j: false`에 해당합니다.
`j: true`	승인을 위해서는 MongoDB 쓰기를 디스크 상의 저널링에 동기화하여 쓰기를 지속형 만들어야 합니다.
`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) 결과를 읽을 수 있습니다.

For behavior details, see w: "majority" Behavior.

w: <number>

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

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

`j` 는 지정되지 않음	승인에는 `j: false`에 해당하는 메모리에 쓰기 작업이 필요합니다.
`j: true`	승인을 위해서는 MongoDB 쓰기를 디스크 상의 저널링에 동기화하여 쓰기를 지속형 만들어야 합니다.
`j: false`	확인에는 메모리에 수행된 쓰기 작업이 필요합니다.

참고

Hidden, delayed, and priority 0 members can acknowledge w: <number> write operations.

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

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

MongoDB 8.0부터, { w: "majority" } 쓰기는 과반수 데이터 보유 노드가 oplog 항목을 지속적으로 쓰기 (write) 후 승인을 반환합니다. 그런 다음 멤버는 로컬 oplog에서 변경 사항을 읽을 때 비동기적으로 변경 사항을 적용 . 이전 릴리스에서는 멤버가 쓰기 (write) 적용할 때까지 MongoDB 승인을 반환했습니다.

{ w: "majority" } 쓰기 (write) 승인 직후의 세컨더리 쿼리는 세컨더리 쓰기 (write) 의 변경 사항을 적용하기 전에 컬렉션 에서 읽을 수 있습니다.

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

추가 정보

읽기 및 쓰기 고려 권장 사항

To read your own writes on the primary, use the "majority" read concern and the { w: "majority" } write concern. During an election, a read routed to the former primary can return a snapshot that does not include a majority-acknowledged write accepted by the new primary.

If you use a { w: n } write concern where n is greater than the calculated majority of the cluster's nodes and the cluster uses the default settings, enable the write concern "j" option to acknowledge the write to the journal. The "majority" read concern only allows you to read updates that are durable on a majority of nodes in the replica set.

참고

{ w: n } 쓰기 고려 (write concern) 로 쓰기를 수행하고 n 값이 계산된 과반수보다 큰 경우, 저널링 없이 기본값 클러스터 설정을 사용하여 대부분의 노드에서 쓰기 (write) 지속형 전에 쓰기 (write) 승인을 받을 수 있습니다.

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

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

관련된 읽기 작업은 "majority" 읽기 고려를 사용합니다.
the associated write operations use "majority" write concern.

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

`w: "majority"` 행동

With writeConcernMajorityJournalDefault set to false, MongoDB does not wait for w: "majority" writes to be written to the on-disk journal before acknowledging the writes. As such, "majority" write operations could possibly roll back in the event of a transient loss (e.g. crash and restart) of a majority of nodes in a given replica set.
Hidden, delayed, and priority 0 members with members[n].votes greater than 0 can acknowledge "majority" write operations.
- 지연된 세컨더리는 구성된 secondaryDelaySecs보다 이전에 완료된 쓰기 확인을 반환할 수 없습니다.
MongoDB 5.0부터 STARTUP2 상태의 복제본 집합 멤버는 쓰기 과반수에 참여하지 않습니다.

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

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

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

팁

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

The majority for write concern "majority" is calculated as the smaller of the following values:

중재자를 포함한 모든 투표 멤버의 과반수
데이터를 보유한 모든 투표 노드 수

경고

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

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

3개의 투표 구성원, P-S-S(프라이머리-세컨더리-세컨더리)가 있는 복제본 세트:
- 모든 투표 멤버의 과반수는 2명입니다.
- 모든 데이터 보유 투표 멤버의 수는 3명입니다.
계산된 과반수는 2 2 이고 최소값은 와 3 입니다. 쓰기 고려 (write concern) 를 클라이언트 에 확인하려면 쓰기 (write) "majority" 프라이머리 와 세컨더리 중 하나에 전파되어야 합니다.
3 투표 멤버인 프라이머리-세컨더리-중재자(PSA)가 있는 복제본 세트 .
- 모든 투표 멤버의 과반수는 2명입니다.
- 데이터를 보유한 모든 투표 멤버 수는 2입니다.
계산된 과반수는 2 2 이고 최소값은 와 2 입니다. 쓰기 (write) 는 데이터를 보유한 멤버에게만 적용할 수 있으므로 쓰기 (write) 프라이머리 멤버와 세컨더리 로 전파되어야 클라이언트 에 대한 쓰기 고려 (write concern) 를 확인할 수 있습니다."majority"

팁
Avoid using "majority" write concern with P-S-A or other topologies that require all data-bearing voting members to be available to acknowledge writes. For the durability guarantees of a "majority" write concern, deploy a topology that does not require all data-bearing voting members to be available, such as P-S-S.

경고

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

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

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

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

팁

기본 쓰기 관심사 공식

우려 사항 출처 작성

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

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

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

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

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

인덱스 빌드는 쿼럼 커밋 사용합니다.
쓰기 작업은 쓰기 고려 사용합니다.

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

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

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

8.0 버전에서 변경됨:

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

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

돌아가기

재시도 가능한 쓰기

라이프사이클 다이어그램