Alterado na versão 5.0.
Uma query com read concern "snapshot" retorna dados comprometidos pela maioria como aparece nos fragmentos a partir de um único ponto específico no passado recente. A Read concern "snapshot" fornece suas garantias somente se a transação se ligar com a write concern "majority".
A read concern "snapshot" está disponível para transações com vários documentos e, a partir do MongoDB 5.0, certas operações de leitura fora das transações com vários documentos.
Se a transação não fizer parte de uma sessão causalmente consistente, após a confirmação da transação com write concern
"majority", é garantido que as operações de transação tenham lido a partir de um snapshot dos dados comprometidos pela maioria.Se a transação fizer parte de uma sessão causalmente consistente, após o commit da transação com a write concern
"majority", as operações da transação terão a garantia de ter lido de um snapshot de dados comprometidos pela maioria que fornece consistência causal com a operação imediatamente anterior ao início da transação.
Importante
Uma leitura de "snapshot" só pode ser realizada dentro do período de tempo especificado por minSnapshotHistoryWindowInSeconds. Uma operação de leitura que dure mais de minSnapshotHistoryWindowInSeconds pode ser encerrada.
Além de transações de vários documentos, a preocupação "snapshot" de leitura está disponível em primários e secundários para as seguintes operações de leitura:
distinct(em coleções não fragmentadas)
Todos os outros comandos de leitura "snapshot" proíbem.
operações
Para obter uma lista de todas as operações que aceitam preocupações de leitura, consulte Operações que suportam preocupações de leitura.
Read Concern e Transações
As transações de vários documentos suportam a preocupação de leitura "snapshot" , bem "local" "majority" como, e.
Observação
Você define a preocupação de leitura no nível da transação, não no nível da operação individual. Para definir a preocupação de leitura para transações, consulte Transações e preocupação de leitura.
Read Concern e atClusterTime
Fora das transações de vários documentos, as leituras com preocupação de leitura oferecem suporte ao "snapshot" parâmetro atClusterTime opcional. O parâmetro atClusterTime permite a você especificar o carimbo de data/hora para a leitura. Para satisfazer uma solicitação de leitura com um atClusterTime de T especificado, o mongod executa a solicitação com base nos dados disponíveis no tempo T. Se o ainda não tiver atingido mongod o tempo T em seu oplog, ele espera para atender o solicitar.
Dica
Se você tiver leituras direcionadas a nós de conjunto de réplicas atrasados, poderá usar maxTimeMS para limitar o tempo de espera para leituras com um atClusterTime especificado. maxTimeMS garante que a operação não bloqueie indefinidamente e, em vez disso, retorne um erro se o mongod não atingir o atClusterTime especificado a tempo.
Você pode obter o operationTime ou clusterTime de uma operação a partir da resposta de db.runCommand() ou do objeto Session().
O comando a seguir executa uma operação de localização com de preocupação de leitura e especifica que a operação deve ler dados do snapshot no momento "snapshot" do Timestamp(1613577600, 1) cluster.
db.runCommand( { find: "restaurants", filter: { _id: 5 }, readConcern: { level: "snapshot", atClusterTime: Timestamp(1613577600, 1) }, } )
Se o parâmetro atClusterTime não for fornecido, o mongos, ou em conjuntos de réplicas de um único membro mongod, seleciona o timestamp do último snapshot confirmado pela maioria como atClusterTime e o retorna ao cliente.
Fora das transações, "snapshot" leituras têm a garantia de ler a partir de dados comprometidos pela maioria.
atClusterTime Considerações e comportamento
Os valores permitidos para
atClusterTimedependem dominSnapshotHistoryWindowInSecondsparâmetro.minSnapshotHistoryWindowInSecondsé a janela de tempo mínimo em segundos para a qual o mecanismo de armazenamento mantém o histórico de snapshots. Se você especificar um valor de atClusterTime mais antigo do que o snapshot mais antigo retido de acordominSnapshotHistoryWindowInSecondscom, retornará ummongoderro.Se você executar uma operação de leitura com sem
"snapshot"especificaratClusterTimeem um membro do conjunto de réplicas atrasado, os dados retornados com comprometimento da maioria poderão estar obsoletos. Se vocêatClusterTimeespecificar, omongodaguardará o registro de data/hora especificado em vez de retornar dados obsoletos, embora a leitura possa bloquear ou atingir o tempo limite.Não é possível especificar
atClusterTimepara dentro"snapshot"de sessões normalmente consistentes.
Leia sobre as coleções com capas
A partir da 5.0 versão, você não pode usar "snapshot" a preocupação de leitura ao ler de uma collection limitada.