Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/

Alterar fluxos de recomendações de produção

Nesta página

  • Conjuntos de réplicas
  • Clusters fragmentados
  • Índices e desempenho
  • Alterar fluxos e documentos órfãos

Se você descartar ou renomear uma collection ou um banco de dados com change streams abertos, os cursores dos change streams serão fechados quando avançarem para esse ponto no oplog. Altere os cursores de streams com a opção fullDocument : updateLookup pode retornar null para o documento de pesquisa.

Os documentos de resposta do change stream devem obedece o limite de 16 MB para documentos BSON. Dependendo do tamanho dos documentos na collection em que você abre um change stream, as notificações podem falhar caso o documento de notificação resultante supere o limite de 16 MB. Por exemplo, operações de atualização em change streams configurados para retornar o documento atualizado completo ou operações de inserção/substituição por um documento que esteja no limite ou logo abaixo.

Importante

A partir da versão 6.0.9, você pode usar o estágio de agregação $changeStreamSplitLargeEvent para divisão os eventos em fragmentos menores.

Para conjuntos de réplicas com membros árbitros , change stream poderá permanecer ocioso se membros portadores de dados suficientes não estiverem disponíveis, de modo que as operações não possam ser confirmadas majoritariamente.

Por exemplo, considere um conjunto de réplicas com 3 membros, sendo dois nós portadores de dados e um árbitro. Se o secundário ficar inativo, por exemplo, devido a uma falha ou atualização, as gravações não poderão ser confirmadas por maioria. O fluxo de alterações permanece aberto, mas não envia nenhuma notificação.

Nesse cenário, o aplicativo pode alcançar todas as operações que ocorreram durante o tempo de inatividade, desde que a última operação que o aplicativo recebeu ainda esteja no registro do conjunto de réplicas.

Se for estimado um tempo de inatividade significativo, como para uma atualização ou um desastre significativo, considere aumentar o tamanho do oplog de modo que as operações sejam mantidas por um período maior do que o tempo de inatividade estimado. Utilize o rs.printReplicationInfo() para recuperar informações sobre o status do oplog, incluindo o tamanho do oplog e a faixa de tempo das operações.

Os fluxos de alterações fornecem uma ordem total de alterações entre fragmentos utilizando um relógio lógico global. O MongoDB garante que a ordem das alterações seja preservada e que as notificações de fluxo de alterações possam ser interpretadas com segurança na ordem recebida. Por exemplo, um cursor de fluxo de alterações aberto em um cluster de 3 fragmentos retorna notificações de alteração respeitando a ordem total dessas alterações em todos os três estilhaços.

Para garantir a ordem total das alterações, para cada notificação de alteração o mongos verifica cada fragmento para ver se o fragmento sofreu alterações mais recentes. Clusters fragmentados com um ou mais fragmentos que têm pouca ou nenhuma atividade para a coleção, ou são "frios", podem afetar negativamente o tempo de resposta do fluxo de mudança, pois o mongos ainda deve verificar esses fragmentos frios para garantir a ordem total de mudanças. Este efeito pode ser mais aparente com fragmentos distribuídos geograficamente ou cargas de trabalho em que a maioria das operações ocorre num subconjunto de fragmentos no cluster. Para minimizar a latência para fragmentos frios, você pode especificar um valor periodicNoopIntervalSecs mais baixo.

Se uma collection fragmentada tiver altos níveis de atividade, o mongos poderá não ser capaz de acompanhar as alterações em todos os shards. Considere usar filtros de notificação para esses tipos de collections. Por exemplo, passar um pipeline $match configurado para filtrar apenas operações insert .

Os fluxos de mudança não podem usar índices. O MongoDB não oferece suporte à criação de índices na coleção de oplogs . Portanto, evite abrir um grande número de fluxos de alterações especificamente direcionados, pois eles podem afetar o desempenho do servidor.

A partir do MongoDB 5.1, os change streams são otimizados, proporcionando uma utilização mais eficiente dos recursos e uma execução mais rápida de alguns estágios do aggregation pipeline.

A partir do MongoDB 5.3, durante a range migration, os eventosde change stream não são gerados para atualizações de documentos órfãos.

Voltar

Fluxos de alterações