MongoDB log e a mensagem - "RSM Not Processing Response”

# análise
Jean da Silva
Updated date:
7 min read

Originally written for Percona Blog in April, 2024 – MongoDB Log and the Message “RSM Not Processing Response”

Uma das tarefas mais comuns para os DBAs é verificar os logs; você pode trabalhar diretamente com o arquivo ou processá-lo usando outra ferramenta. De qualquer forma, verificar os logs regularmente continua sendo essencial. Dentro desse contexto, algumas mensagens de log ocasionalmente começam a aparecer e, infelizmente, não há muita literatura sobre algumas delas. Isso acontece porque nem a comunidade nem a documentação oferecem explicações detalhadas. Este artigo tem como objetivo explicar mais profundamente a mensagem “RSM not processing response” e fornecer uma base mais sólida para entendê-la. Dividiremos este artigo em três seções:

  1. O que é essa mensagem?
  2. Por que isso acontece?
  3. Como corrigir?

Primeiramente, vamos dar uma olhada em uma instância típica do erro que estamos discutindo:

{"t":{"$date":"2024-03-05T08:33:41.685-03:00"},"s":"I", "c":"-", "id":4495400, "ctx":"ReplicaSetMonitor-TaskExecutor","msg":"RSM not processing response","attr":{"error":{"code":0,"codeName":"OK"},"replicaSet":"rs0"}}

Antes de entrarmos nas seções, vamos detalhar essa mensagem e explicar o que o mongo.log está tentando nos comunicar.

O que é essa mensagem?

Conforme vimos na análise do log, essa mensagem está associada à thread ReplicaSetMonitor-TaskExecutor. O ReplicaSetMonitor (RSM) é um componente crítico do MongoDB, responsável por monitorar o status e a configuração do replica set. Quando o log exibe a mensagem “RSM not processing response”, isso sugere um problema na forma como o RSM está lidando ou reagindo às respostas recebidas durante suas atividades de monitoramento. Conforme a documentação, os objetivos do ReplicaSetMonitor (RSM) incluem:

Esse monitoramento e descoberta são realizados através da operação isMaster/hello. O que está acontecendo aqui é que o nó recebeu uma resposta dessa operação isMaster/hello, mas está em um estado de desligamento (shutdown). Assim, ele não pode processar a resposta. Também é importante mencionar que o MongoDB usa dois métodos para esse processo de rastreamento: “sdam” (Server Discovery and Monitoring) e o método “streamable”.

Esse método mantém conexões atualizadas com cada banco de dados no conjunto de maneira inteligente, sem sobrecarregar o sistema, aprimorando a eficácia do RSM. Trecho relevante no código-fonte do MongoDB (_scheduleStreamableHello() e _scheduleSingleHello()):

if (self->_isShutdown) {
    self->_helloOutstanding = false;
    LOGV2_DEBUG(4495400,
                kLogLevel,
                "RSM not processing response",
                "error"_attr = result.response.status,
                "replicaSet"_attr = self->_setUri.getSetName());
    return;
}

Nas duas funções responsáveis pelo ReplicaSet Monitor:

Há a condição if (self->_isShutdown). Quando essa condição é verdadeira, indicando que o ReplicaSetMonitor (RSM) está em estado de desligamento (shutdown), ela aciona uma entrada de log com a mensagem ‘RSM not processing response’. O log inclui atributos como o status do erro e o nome do replica set. Quando em estado de shutdown, o RSM para de processar respostas, o que é refletido nos logs.

Por que isso acontece?

Em uma configuração padrão de replicação, o ReplicaSetMonitor (RSM) deve operar continuamente, monitorando o status dos nós em um replica set. Na camada administrativa, não temos controle sobre esse processo, pois ele é iniciado e encerrado automaticamente. Por exemplo, durante o desligamento do banco de dados, você provavelmente verá essa mensagem, já que o processo do banco está realizando a limpeza antes de encerrar. No entanto, o MongoDB controla todos os processos internamente. Outra condição que pode levar o processo ao estado de shutdown é uma mudança na configuração do Replica Set. Isso ocorre porque, se houver alterações significativas no replica set ou nos parâmetros de conexão, o RSM pode ser desligado para aplicar essas atualizações. Para compreender melhor, você pode rastrear a sequência de eventos do ReplicaSetMonitor nos logs. No entanto, além do desligamento do nó, o log não fornece muitos detalhes sobre o motivo pelo qual a tarefa do RSM entrou em estado de shutdown.

Como corrigir?

É importante mencionar que, embora a mensagem não seja exibida como um ERRO ou AVISO, ter o RSM em estado de shutdown durante a operação normal não é bom para o cluster, principalmente devido à sua função principal, que é monitorar o estado do replica set. Com o RSM inoperante, alguns problemas podem surgir:

  1. Atrasos ou informações incorretas sobre a topologia: O RSM é responsável por rastrear o status e a configuração dos nós no replica set. Se o RSM estiver inativo, o cliente pode não estar ciente de mudanças na topologia, como qual nó é o primário ou o estado dos nós secundários.
  2. Impacto em operações de leitura e escrita: Os clientes do MongoDB usam o RSM para direcionar operações de leitura e escrita com base no estado atual do replica set e nas preferências de leitura/escrita especificadas. Sem um RSM operacional, essas operações podem falhar ou ser menos eficientes, resultando em degradação do desempenho ou inconsistência no acesso aos dados.
  3. Manuseio ineficaz de failover: Em caso de falha do nó primário, o RSM ajuda a identificar um novo nó primário. Se o RSM não estiver funcionando, os processos de failover podem ser atrasados ou não ocorrer corretamente, afetando a disponibilidade e a resiliência do banco de dados.
  4. Alta disponibilidade e tolerância a falhas comprometidas: Um dos principais benefícios do uso de um replica set é a alta disponibilidade e tolerância a falhas. Com o RSM inativo, essas funcionalidades são comprometidas, pois o sistema pode não responder adequadamente a falhas de nós ou partições de rede.

Como mencionado anteriormente, não temos controle sobre a thread em si. Se você estiver sendo inundado por essas mensagens, a melhor ação que pode tomar é reiniciar o processo do banco de dados:

sudo systemctl restart mongodb

Embora seja uma solução um pouco drástica, um stop-and-start limpo é, atualmente, a única maneira de restaurar a saúde dos processos.

Conclusão:

Neste artigo, exploramos a mensagem ‘RSM not processing response’ no MongoDB, um indicador crítico do estado de shutdown do ReplicaSetMonitor. Entender essa mensagem ajuda a manter a saúde e o desempenho do sistema de replicação do MongoDB, com a reinicialização do processo do banco como uma solução potencial para problemas que persistem.

Share
Anterior
Configurando o Percona Backup para MongoDB em um Ambiente com Múltiplas Instâncias
Próximo
5 Mudanças que você precisa conhecer no MongoDB 7.0