Dicas para executar o MongoDB em produção usando fluxos de mudança

Bancos de dados modernos devem ter a capacidade de capturar e reagir aos dados conforme eles fluem em tempo real. Isso explica por que o MongoDB possui um recurso chamado MongoDB Change Streams responsável por capturar e responder aos dados em tempo real. Change Streams é um recurso introduzido para transmitir informações do aplicativo para o banco de dados em tempo real. Ele é baseado em uma estrutura de agregação que monitora as coleções e permite que ocorram alterações no banco de dados e na coleção de banco de dados. Além disso, o MongoDB Change Stream pode capturar dados de sensores IOT e atualizar relatórios como alterações de dados operacionais em uma empresa. Este blog abrirá o discurso sobre o MongoDB Change Stream e alterará as recomendações em produção.

Fluxos de mudança do MongoDB e coleção de descarte

Renomear ou descartar um banco de dados ou coleção levará ao fechamento do cursor se houver um fluxo de mudança aberto trabalhando na coleção descartada. Renomear ou descartar uma coleção faz com que o cursor seja FullDocument:updateLookup para retornar null em qualquer documento de pesquisa. Ocorre um erro se alguém tentar retomar após eliminar um banco de dados com um fluxo de mudança em execução.

Além disso, todas as alterações nos dados feitas antes de renomear uma coleção com um fluxo de mudança em execução são perdidas. O limite de documentos para o fluxo de mudança ainda é 16 MB BSON; portanto, documentos maiores que 16 MB não são aceitos. Se alguém tentar trabalhar com um documento maior que 16 MB, a notificação falhará e o documento será substituído por outro documento que atenda ao limite definido.

Quando uma coleção ou banco de dados com fluxos de mudança abertos é descartado ou renomeado, os cursores de fluxo de mudança tendem a fechar à medida que avançam para esse ponto no oplog. Se você alterar os cursores de fluxo com o documento completo, a opção updateLookup poderá retornar nulo ao documento de pesquisa.

 Portanto, uma tentativa de retomar os fluxos de mudança em uma coleção que foi descartada resultará em um erro. Qualquer ocorrência de alterações de dados na coleção entre o último evento do fluxo de mudança capturado e o evento de descarte da coleção é perdida.

A alteração de documentos de resposta de fluxo deve estar em conformidade com o limite de documentos BSON de 16 MB. Dependendo do tamanho dos documentos na coleção em relação à qual você está abrindo o fluxo de mudança, as notificações podem falhar se o documento de notificação resultante tiver mais de 16 MB. Um bom exemplo são as operações de atualização nos fluxos de mudança configurados para retornar um documento totalmente atualizado ou substituir/inserir processos com o documento no limite ou um pouco abaixo do limite.

MongoDB Change Stream e conjuntos de réplicas

Um conjunto de réplicas do MongoDB é uma coleção de processos no MongoDB cujo conjunto de dados não muda; ou seja, o conjunto de dados permanece o mesmo. No caso de conjuntos de réplicas com membros árbitros, os fluxos de mudança provavelmente permanecerão inativos se membros suficientes com os dados não estiverem disponíveis para que a maioria não possa confirmar as operações. Por exemplo, podemos considerar um conjunto de réplicas com três membros com dois nós portadores de dados ao lado de um árbitro. Caso o secundário esteja inativo, por exemplo, como resultado de falha ou atualização ou manutenção, será impossível que as operações de gravação sejam confirmadas majoritariamente. O fluxo de alterações permanecerá aberto, mas não enviará notificações. No cenário em questão, o aplicativo pode acompanhar todas as operações que ocorreram no período de inatividade, desde que a última operação recebida pelo aplicativo ainda esteja no oplog desse conjunto de réplicas específico. Além disso, o comando  rs.printReplicationInfo() é usado para recuperar dados do oplog; os dados recuperados incluem uma variedade de operações e tamanho do oplog.

Se o tempo de inatividade for estimado significativamente, por exemplo, para realizar uma atualização ou em caso de desastre, aumentar o tamanho do oplog será a melhor opção para reter as operações por um período maior que o tempo de inatividade aproximado. Para recuperar informações de status do oplog, o comando usado é printReplicationInfo(). O comando recuperará não apenas as informações de status do oplog, mas também o tamanho do oplog e o intervalo de tempo das operações.

Disponibilidade de fluxos de mudança do MongoDB

Os fluxos de mudança do MongoDB podem ser obtidos para conjuntos de réplicas e clusters fragmentados:Habilitação de “maioria” do Read Concern, mecanismo de armazenamento e versão do protocolo de conjunto de réplicas. Ativação de “maioria” de leitura:a partir do MongoDB versão 4.2 e superior, os fluxos de mudança são acessíveis apesar das circunstâncias predominantes do suporte de preocupação de leitura “majoritária”, o que significa que o suporte à maioria de preocupação de leitura pode ser ativado ou desativado.No MongoDB versão 4.0 e versões mais antigas, os fluxos de mudança só estarão disponíveis se o suporte a preocupações de leitura "maioria" estiver ativado.

1. Mecanismo de armazenamento:o mecanismo de armazenamento WiredTiger é o tipo de mecanismo de armazenamento usado pelos conjuntos de réplicas e clusters fragmentados.
2. Versão do protocolo de conjunto de réplicas:conjuntos de réplicas e clusters fragmentados devem sempre usar a versão 1 do protocolo de conjunto de réplicas (pv1).

Clusters fragmentados do MongoDB

Clusters fragmentados no MongoDB consistem em fragmentos, mongos e servidores de configuração. Um estilhaço consiste em um subconjunto de dados fragmentados. No caso do MongoDB 3.6, os shards são utilizados como um conjunto de réplicas. O Mongos fornece uma interface entre clusters fragmentados e aplicativos cliente; mongos desempenha o papel de um roteador de consulta. A partir da versão 4.4 e superior do MongoDB, o mongos suporta leituras protegidas para reduzir as latências. Os servidores de configuração são os locais de armazenamento para definições e metadados de configuração de cluster.

Os fluxos de alterações usam um relógio lógico global para fornecer uma ordenação global das alterações nos estilhaços. O MongoDB garante que a ordem das alterações seja mantida e que as notificações do fluxo de alterações possam ser interpretadas com segurança na ordem em que foram recebidas. Por exemplo, o cursor do fluxo de mudança aberto em um cluster de 3 fragmentos retorna as notificações de alteração referentes à ordem total das alterações nos três fragmentos.

Para garantir a ordem total das alterações, o Mongos verifica com cada fragmento se ele viu as alterações mais recentes para cada notificação de alteração. Clusters fragmentados com um a vários fragmentos com pouca ou nenhuma atividade de coleta ou "frios" provavelmente terão efeitos negativos no tempo de resposta do fluxo de mudança, pois os mongos ainda precisam verificar esses fragmentos frios para garantir a ordem total das alterações. Esse efeito pode ser mais aparente quando os estilhaços são distribuídos geograficamente ou quando as cargas de trabalho com a maioria das operações ocorrem em um subconjunto de estilhaços em um cluster. Se a coleção de fragmentos tiver um alto nível de atividade, os mongos podem não conseguir acompanhar as alterações em todos os fragmentos. Considere usar filtros de notificação para esse tipo de coleção, por exemplo, passando o pipeline $match, que está configurado para filtrar apenas as operações de inserção.

No caso de coleções fragmentadas, multi:operações de atualização adequadas provavelmente farão com que os fluxos de mudança abertos na coleção enviem notificações para documentos órfãos. A partir do momento em que uma coleção não fragmentada é fragmentada até o momento em que o fluxo de mudança chega ao primeiro fragmento de migração, a documentKey no documento de notificação do fluxo de mudança inclui apenas a ID do documento e não a chave de fragmentação completa.

Conclusão