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.
Outside of multi-document transactions, read concern "snapshot" is available on primaries and secondaries for the following read operations:
distinct(em coleções não fragmentadas)
All other read commands prohibit "snapshot".
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
Multi-document transactions support read concern "snapshot" as well as "local", and "majority".
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
Outside of multi-document transactions, reads with read concern "snapshot" support the optional parameter atClusterTime. The parameter atClusterTime allows you to specify the timestamp for the read. To satisfy a read request with a specified atClusterTime of T, the mongod performs the request based on the data available at time T. If the mongod has not yet reached time T in its oplog, it waits to service the request.
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().
The following command performs a find operation with read concern "snapshot" and specifies that the operation should read data from the snapshot at cluster time Timestamp(1613577600, 1).
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.
Outside of transactions, "snapshot" reads are guaranteed to read from majority-committed data.
atClusterTime Considerações e comportamento
The allowed values for
atClusterTimedepend on theminSnapshotHistoryWindowInSecondsparameter.minSnapshotHistoryWindowInSecondsis the minimum time window in seconds for which the storage engine keeps the snapshot history. If you specify an atClusterTime value older than the oldest snapshot retained according tominSnapshotHistoryWindowInSeconds,mongodreturns an error.If you perform a read operation with
"snapshot"without specifyingatClusterTimeagainst a delayed replica set member, the returned majority-committed data could be stale. If you specifyatClusterTime, themongodwaits for the specified timestamp instead of returning stale data, though the read may block or time out.It is not possible to specify
atClusterTimefor"snapshot"inside of causally consistent sessions.
Leia sobre as coleções com capas
Starting in version 5.0, you cannot use read concern "snapshot" when reading from a capped collection.