Observação
Você não precisa sincronizar novamente os bancos de dados MongoDB que são executados com um FCV de 4.2 ou posterior.
Quando um backup fica fora de sincronia com o sistema do MongoDB, o Ops Manager produz um alerta Backup requires a resync . Se você receber esse alerta, deverá ressincronizar o backup para a instância do MongoDB especificada.
Os seguintes cenários acionam um alerta Backup requires a resync :
- O Oplog passou
- Esse é o caso mais comum para o alerta
Backup requires a resync. Ocorre sempre que o cursor tailing do Backup não consegue acompanhar o oplog do sistema. Isso é semelhante a quando um secundário fica muito atrás do primário em um conjunto de réplicas. Sem uma ressincronização, os backups não serão atualizados. - applyOps não seguros
- Isso ocorre quando um documento do qual o Backup não tem uma cópia é indicado.
- Corrupção de dados ou outra instrução ilegal
- Isso normalmente faz com que a replicação e, portanto, a tarefa de backup, seja interrompida. Quando o daemon vê a tarefa interrompida, ele solicita uma ressincronização.
Durante a ressincronização, os dados são lidos de um secundário em cada conjunto de réplicas e o Ops Manager não produz novos snapshots.
Observação
Para sistemas de produção com um FCV de 4.0 ou anterior, você deve ressincronizar todos os backups anual.
Importante
O Ops Manager não tenta se recuperar automaticamente das condições que causaram o alerta Backup requires a resync . Esse alerta significa que não há dados suficientes para concluir uma restauração. Não há como se recuperar automaticamente por não ter dados suficientes dos snapshots e do oplog. Sincronizar novamente o backup é a melhor opção.
Considerações
A partir do FCV 4.2, os sistemas são armazenados em backup com checkpoints WiredTiger usando cursores de backup. Os aplicativos podem continuar as operações de leitura e escrita no banco de dados enquanto o WiredTiger tira o snapshot.
Para implantações de produção com um FCV de 4.0 ou anterior, para evitar a necessidade de ressincronizações, verifique se o oplog de backup não fica atrás do oplog da implantação. Isso exige que:
Os recursos de máquina adequados são provisionados para o agente.
Você reinicia os agentes do Ops Manager em tempo hábil após manutenção ou outro tempo de inatividade.
Para fornecer um buffer para manutenção e para explosões ocasionalmente de atividade, certifique-se de que o oplog no primário seja grande o suficiente para conter pelo menos 24 horas de atividade.
Você deve sincronizar novamente o banco de dados principal depois de criar um índice de forma contínua para garantir que o banco de dados principal leve em consideração o novo índice.
Dica
Para obter mais informações sobre o oplog de backup, consulte as Perguntas frequentes: backup e restauração.