O ApsaraDB for MongoDB opera em uma arquitetura de alta disponibilidade (HA). Quando o sistema HA detecta a indisponibilidade de um nó, ele aciona automaticamente um failover primário/secundário e notifica você por Short Message service (SMS) ou mensagem interna.
Exemplo de notificação
[Alibaba Cloud] Prezado(a) \\\\: Sua instância do ApsaraDB for MongoDB dds-bp\\\\ (nome: \\\\) apresentou um erro. Um failover foi acionado para garantir a execução estável da sua instância. Recomendamos verificar se sua aplicação ainda está conectada à instância e configure-a para reconectar-se automaticamente.
Como funciona
Uma instância de conjunto de réplicas possui três nós por padrão. Cada shard em uma instância de cluster fragmentado também conta com três nós. Os nós primários e secundários gerenciam as conexões da aplicação, enquanto os nós ocultos funcionam como alvos de reserva para o failover. Para mais informações, consulte Replica set instances ou Sharded cluster instances.
Motivos do acionamento do failover
Duas condições podem acionar um failover primário/secundário:
Nó indisponível: O sistema de monitoramento de integridade detecta que um nó não responde e promove um nó oculto a primário.
Host offline: Uma exceção ocorre no host que executa o nó primário. O sistema HA transfere a operação para um host íntegro para evitar tempo de inatividade prolongado.
Solucionar a causa de um failover HA
A utilização excessiva de recursos, como alto consumo de CPU ou memória, pode tornar um nó indisponível e provocar um failover HA. Para avaliar se a pressão sobre os recursos influenciou o failover, inspecione as métricas de desempenho do período em que ele ocorreu.
No console do ApsaraDB for MongoDB, abra a instância desejada. No painel de navegação à esquerda, selecione DAS Performance Trend.
-
Selecione o intervalo de tempo em que o failover ocorreu. Analise as seguintes métricas e compare suas variações com o horário do failover:
CPU utilization e memory utilization: Utilização sustentada elevada ou picos repentinos podem indicar que a pressão sobre os recursos afetou a capacidade de resposta do nó.
Affected Documents e Scanned Indexes and Documents: Aumentos anormais podem sinalizar consultas ineficientes que consomem recursos da instância.
Repl Opcounters e Oplog Retention Period: Valores fora do padrão ajudam a avaliar a atividade e o status da replicação.
Caso a utilização de CPU ou memória esteja anormal, selecione Monitoring Information no painel de navegação à esquerda. Escolha o nó afetado e o intervalo de tempo correspondente para revisar seu histórico.
Correlacione o período da métrica anormal com o horário do failover. Um pico de utilização de CPU seguido de interrupção nos dados de monitoramento indica que a pressão sobre os recursos pode ter contribuído para o failover da instância. Avalie esse dado em conjunto com as demais métricas antes de identificar a causa raiz.
DAS Performance Trend é o novo nome do antigo recurso de diagnóstico de desempenho Dukang-Telescope.
Quando a utilização de CPU estiver anormal, continue a investigação com Troubleshoot high CPU utilization on an ApsaraDB for MongoDB instance.
Impacto do failover
O failover causa uma interrupção transitória de conexão inferior a 30 segundos.
Se sua aplicação se conectar diretamente ao endpoint do nó primário, as operações de leitura e gravação serão afetadas durante a janela do failover.
O que fazer
Para problemas imediatos de reconexão: Configure sua aplicação para reconectar-se automaticamente após uma desconexão. A maioria dos drivers do MongoDB oferece suporte à reconexão automática por padrão.
Para ambientes de produção: Utilize uma URI de string de conexão para acessar a instância. Isso permite que sua aplicação realize failover automático para um nó íntegro, mantendo as operações de leitura e gravação disponíveis mesmo quando o nó primário mudar. Para mais informações, consulte Connect to a replica set instance ou Connect to a sharded cluster instance.