db.watch()
Nesta página
Definição
db.watch( pipeline, options )
Somente para conjuntos de réplica e clusters fragmentados
Abre umcursor de fluxo de alteração para um banco de dados de dados para relatar todas as suas coleções que não sejam
system
.ParâmetroTipoDescriçãopipeline
arrayOpcional. Um pipeline de agregação que consiste em um ou mais dos seguintes estágios de agregação :
Especifique um pipeline para filtrar/modificar o resultado dos eventos de alteração.
A partir do MongoDB 4.2, os fluxos de alteração lançarão uma exceção se o pipeline de agregação do fluxo de alterações modificar o campo _id de um evento.
options
documentoOpcional. Opções adicionais que modificam o comportamento dodb.watch()
.O documento
options
pode conter os seguintes campos e valores:CampoTipoDescriçãoresumeAfter
documentoOpcional. Especifica um token de currículo como o ponto de partida lógico para o fluxo de alteração. Não pode ser usado para retomar o fluxo de alterações após um evento
invalidate
.resumeAfter
é mutuamente exclusivo comstartAfter
estartAtOperationTime
.startAfter
documentoOpcional. Especifica um token de resumo como o ponto de partida lógico para o fluxo de alterações. Ao contrário de
resumeAfter
,startAfter
pode retomar notificações após um eventoinvalidate
criando um novo fluxo de alterações.startAfter
é mutuamente exclusivo comresumeAfter
estartAtOperationTime
.fullDocument
stringOpcional. Por padrão,
db.watch()
retorna o delta dos campos modificados por uma operação de atualização, em vez de todo o documento atualizado.Defina
fullDocument
como"updateLookup"
para direcionardb.watch()
para procurar a versão mais atual confirmada por maioria do documento atualizado.db.watch()
retorna um campofullDocument
com a pesquisa de documento, além do deltaupdateDescription
.A partir do MongoDB 6.0, você pode definir
fullDocument
como:"whenAvailable"
para produzir o documento pós-imagem, se disponível, depois que o documento foi inserido, substituído ou atualizado."required"
para gerar a pós-imagem do documento após o documento ter sido inserido, substituído ou atualizado. Cria um erro se a pós-imagem não estiver disponível.
fullDocumentBeforeChange
stringOpcional. O padrão é
"off"
.A partir do MongoDB 6.0, você pode usar o novo campo
fullDocumentBeforeChange
e defini-lo como:"whenAvailable"
para gerar a pré-imagem do documento, se disponível, antes do documento ser substituído, atualizado ou excluído."required"
para gerar a pré-imagem do documento antes do documento ser substituído, atualizado ou excluído. Gera um erro se a pré-imagem não estiver disponível."off"
para suprimir a pré-imagem do documento."off"
é o padrão.
batchSize
intOpcional. Especifica o número máximo de eventos de alteração a serem retornados em cada lote da resposta do cluster MongoDB.
Tem a mesma funcionalidade que
cursor.batchSize()
.maxAwaitTimeMS
intOpcional. A quantidade máxima de tempo em milissegundos que o servidor aguarda por novas alterações de dados para relatar ao cursor do fluxo de alterações antes de retornar um lote vazio.
Padrão para
1000
milissegundos.collation
documentoOpcional. Passe um documento de agrupamento para especificar um agrupamento para o cursor do change stream.
Se omitido, o padrão é
simple
comparação binária.startAtOperationTime
TimestampOpcional. O ponto de partida para o fluxo de alterações. Se o ponto de partida especificado estiver no passado, ele deverá estar no intervalo de tempo do oplog. Para verificar o intervalo de tempo do oplog, consulte
rs.printReplicationInfo()
.startAtOperationTime
é mutuamente exclusivo comresumeAfter
estartAfter
.Retorna: Um cursor sobre os documentos do evento de alteração. Consulte Eventos de mudança para obter exemplos de documentos de eventos de mudança.
Disponibilidade
Implantação
db.watch()
está disponível para conjuntos de réplicas e clusters fragmentados:
Em um conjunto de réplicas, você pode emitir
db.watch()
em qualquer membro portador de dados.Em um cluster fragmentado, você deve emitir
db.watch()
em uma instânciamongos
.
Mecanismo de armazenamento
Você só pode usar db.watch()
com o mecanismo de armazenamento Wired Tiger.
Leia o suporte do Concern majority
A partir do MongoDB 4.2, os fluxos de alteração estão disponíveis independentemente do suporte à "majority"
de leitura; ou seja, o suporte a majority
de leitura pode ser habilitado (padrão) ou desabilitado para usar fluxos de alteração.
No MongoDB 4.0 e versões anteriores, os fluxos de alteração estarão disponíveis somente se "majority"
suporte a preocupações de leitura estiver habilitado (padrão).
Comportamento
Não é possível executar
db.watch()
no banco de dadosadmin
,local
ouconfig
.db.watch()
notifica apenas sobre alterações de dados que persistiram para a maioria dos membros portadores de dados.O cursor do fluxo de alterações permanece aberto até que ocorra uma das seguintes situações:
O cursor está explicitamente fechado.
Ocorre um evento de invalidar; por exemplo, um drop de coleção ou renomear.
A conexão com a implantação do MongoDB fecha ou expira. Consulte Comportamentos do cursor para obter mais informações.
Se a implantação for um cluster fragmentado, uma remoção de fragmento pode fazer com que um cursor de fluxo de alteração aberto seja fechado e o cursor de fluxo de alterações fechado pode não ser totalmente retomável.
Você pode executar o
db.watch()
em relação a um banco de dados que não existe. No entanto, assim que o banco de dados for criado e você descartar o banco de dados, o cursor do fluxo de alterações será fechado.
Retomabilidade
Ao contrário dos drivers do MongoDB, omongosh
não tenta retomar automaticamente um cursor de fluxo de alterações após um erro. Os drivers do MongoDB fazem uma tentativa de retomar automaticamente um cursor de fluxo de alterações após determinados erros.
db.watch()
usa informações armazenadas no oplog para produzir a descrição do evento de alteração e gerar um token de retomada associado a essa operação. Se a operação identificada pelo token de retomada passada para a opção resumeAfter
ou startAfter
já tiver sido descartada do oplog, db.watch()
não poderá retomar o fluxo de alterações.
Consulte Retomar um fluxo de alterações para obter mais informações sobre como retomar um fluxo de alterações.
Observação
Não é possível usar
resumeAfter
para retomar um fluxo de alterações depois que um evento de invalidação (por exemplo, um descarte ou renomeação de coleção) fechar o fluxo. Em vez disso, você pode usar startAfter para iniciar um novo fluxo de alterações após um evento de invalidação.Se a implantação for um cluster fragmentado, uma remoção de fragmento pode fazer com que um cursor de fluxo de alteração aberto seja fechado e o cursor de fluxo de alterações fechado pode não ser totalmente retomável.
Observação
Não é possível usar resumeAfter
para retomar um fluxo de alterações depois que um evento de invalidação (por exemplo, um descarte ou renomeação de coleção) fechar o fluxo. Em vez disso, você pode usar startAfter para iniciar um novo fluxo de alterações após um evento de invalidação.
Pesquisa completa de documentos de operações de atualização
Por padrão, o cursor de fluxo de alterações retorna alterações/deltas de campos específicos para operações de atualização. Você também pode configurar o fluxo de alterações para procurar e retornar a versão atual de compromisso majoritário do documento alterado. Dependendo de outras operações de gravação que podem ter ocorrido entre a atualização e a pesquisa, o documento retornado pode diferir significativamente do documento no momento da atualização.
Dependendo do número de alterações aplicadas durante a operação de atualização e o tamanho do documento completo, há o risco de que o tamanho do documento do evento de alteração para uma operação de atualização seja maior do que os 16MB que são o limite de documentos BSON. Se isso ocorrer, o servidor fechará o cursor de fluxo de alterações e retornará um erro.
Controle de acesso
Ao executar com controle de acesso, o usuário deve ter as ações de privilégio do find
e changeStream
no recurso do banco de dados. Ou seja, um usuário deve ter uma função que conceda o seguinte privilégio:
{ resource: { db: <dbname>, collection: "" }, actions: [ "find", "changeStream"] }
O papel do read
embutido fornece os privilégios apropriados.
Iteração do cursor
O MongoDB oferece várias maneiras de iterar em um cursor.
O método cursor.hasNext()
bloqueia e aguarda o próximo evento. Para monitorar o cursor watchCursor
e iterar sobre os eventos, use hasNext()
assim:
while (!watchCursor.isClosed()) { if (watchCursor.hasNext()) { firstChange = watchCursor.next(); break; } }
O método cursor.tryNext()
não está bloqueando. Para monitorar o cursor watchCursor
e iterar sobre os eventos, use tryNext()
assim:
while (!watchCursor.isClosed()) { let next = watchCursor.tryNext() while (next !== null) { printjson(next); next = watchCursor.tryNext() } }
Exemplo
A operação a seguir em mongosh
abre um cursor de fluxo de alterações no banco de dados hr
. O cursor retornado relata as alterações de dados em todas as coleções nãosystem
nesse banco de dados.
watchCursor = db.getSiblingDB("hr").watch()
Itere o cursor para verificar novos eventos. Use o método cursor.isClosed()
com o método cursor.tryNext()
para garantir que o loop só saia se o cursor do fluxo de alteração estiver fechado e não houver objetos restantes no lote mais recente:
while (!watchCursor.isClosed()) { let next = watchCursor.tryNext() while (next !== null) { printjson(next); next = watchCursor.tryNext() } }
Para obter a documentação completa sobre a saída do fluxo de alterações, consulte Eventos de alteração.
Observação
Você não pode usar isExhausted()
com alterar colunas.