Sincronizar um backup novamente
Nesta página
- A autenticação OAuth 2.0 para acesso programático ao Cloud Manager está disponível como um recurso de visualização.
- O recurso e a documentação correspondente podem mudar a qualquer momento durante o período de Pré-visualização. Para usar a 2.0 autenticação OAuth, crie uma conta de serviço para usar em suas solicitações para a API pública do Cloud Manager .
Observação
Você não precisa sincronizar novamente os bancos de dados MongoDB executados com FCV 4.2 ou posterior.
Quando um backup fica fora de sincronia com o sistema do MongoDB, o Cloud 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 Cloud Manager não produz novos snapshots.
Observação
Para implantações de produção com FCV 4.0 ou anterior, você deve ressincronizar todos os backups anual.
Importante
O Cloud 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 FCV 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 o agente do Cloud 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 ressincronizar o banco de dados principal depois de criar um índice de forma contínua para garantir que o reconhecimento de data center leve em consideração o novo índice.
Dica
Veja também:
Para obter mais informações sobre o oplog de backup, consulte as Perguntas frequentes: backup e restauração.
Procedimento
No MongoDB Cloud Manager, acesse aGo Continuous Backup página do seu projeto.
Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.
Clique em Continuous Backup na barra lateral.
A página Backup contínuo é exibida.