Página inicial do Docs → Desenvolver aplicações → Manual do MongoDB
getDefaultRWConcern
Definição
getDefaultRWConcern
O comando administrativo
getDefaultRWConcern
recupera as configurações globais padrão de read ou write concern.Para clusters fragmentados, emita o
getDefaultRWConcern
em ummongos
.
Sintaxe
O comando tem o seguinte formato:
db.adminCommand( { getDefaultRWConcern: 1 , inMemory: <boolean>, comment: <any> } )
Campos de comando
O comando tem os seguintes campos:
Campo | Tipo | Descrição |
---|---|---|
int | Defina como | |
booleano | Opcional. Defina como Defina como | |
comment | qualquer | Opcional. Um comentário fornecido pelo usuário para anexar a este comando. Depois de definido, esse comentário aparece junto com os registros desse comando nos seguintes locais:
Um comentário pode ser qualquer tipo BSON válido (string, inteiro, objeto, array etc). |
Saída
A saída pode incluir os seguintes campos:
Campo | Tipo | Descrição |
---|---|---|
object | A configuração padrão global da preocupação de gravação. Se o sistema não tiver configurações de write concern padrão globais, esse campo estará ausente da saída | |
object | A configuração da preocupação de leitura padrão global. Se a implantação não tiver configurações de read concern padrão globais, esse campo estará ausente da saída | |
String | A origem da write concern padrão. Por padrão, o valor é | |
String | A origem da read concern padrão. Por padrão, o valor é | |
Timestamp | O carimbo de data e hora da operação de quando houve a última mudança nas configurações padrão globais de read ou write concern. Presente se um padrão já tiver sido definido para o cluster. | |
Data | A data do wall clock em que um administrador definiu pela última vez a read ou write concern padrão global. Este valor é informativo e não deve ser usado para comparações de recenticidade. | |
Data |
Dica
Veja também:
Comportamento
Observação
Exige featureCompatibilityVersion 4.4+
Cada mongod
no conjunto de réplicas ou cluster fragmentado deve ter featureCompatibilityVersion configurado para pelo menos 4.4
para usar getDefaultRWConcern
. Se você fizer o downgrade do featureCompatibilityVersion do seu sistema de 4.4
para 4.2
, todos os padrões da read e write concerns em todo o cluster serão perdidos, mas as instâncias do mongos
poderão continuar aplicando os padrões por até 30 segundos.
Conjuntos de réplicas
Você pode emitir getDefaultRWConcern
contra qualquer membro portador de dados do conjunto de réplicas (ou seja, não contra um arbiter).
Um secundário pode retornar uma versão "obsoleta" das configurações padrão globais se ainda não tiver replicado as alterações mais recentes do primário.
Clusters fragmentados
Emita setDefaultRWConcern
contra um mongos
no cluster.
Cada mongos
atualiza periodicamente sua cópia local das configurações padrão globais. Um mongos
pode retornar uma versão "obsoleta" das configurações padrão globais se ainda não tiver atualizado sua cópia local após uma atualização recente conforme as configurações padrão globais ou se tiver buscado suas configurações de um servidor de configuração secundário com atraso.
As configurações padrão globais não se propagam para os shards individuais. Você não pode executar getDefaultRWConcern
em um shard.
Controle de acesso
Para conjuntos de réplicas ou clusters fragmentados que forçam Autenticação, getDefaultRWConcern
exige que o usuário autenticado tenha a ação de privilégio getDefaultRWConcern
.
As roles embutidas de clusterManager
ou clusterMonitor
fornecem os privilégios exigidos para executar getDefaultRWConcern
.
Exemplo
A operação a seguir recupera as read e write concerns padrão globais configuradas para o mongod
.
db.adminCommand({ "getDefaultRWConcern": 1 })
A operação gera uma saída semelhante ao seguinte:
{ "defaultWriteConcern" : { "w" : "majority" }, "defaultReadConcern" : { "level" : "majority" }, "defaultWriteConcernSource" : "global", "defaultReadConcernSource" : "global", "updateOpTime" : Timestamp(1586290895, 1), "updateWallClockTime" : ISODate("2020-04-07T20:21:41.849Z"), "localUpdateWallClockTime" : ISODate("2020-04-07T20:21:41.862Z"), "ok" : 1, "$clusterTime" : { ... } "operationTime" : Timestamp(1586290925, 1) }