Quando você perde o MongoDB Ops Manager primário, restaure seus bancos de dados de apoio do MongoDB Ops Manager secundário e, em seguida, inicie um novo MongoDB Ops Manager primário. Use este procedimento após um evento, como uma atualização com falha, exclusão acidental de dados ou falha de infraestrutura. Quando o MongoDB Ops Manager primário é reiniciado, ele entra automaticamente no Modo de Restauração para reconciliar a configuração do agente antes que a operação normal seja retomada. Para obter uma visão geral desse padrão, consulte Fazer backup e restaurar o MongoDB Ops Manager usando uma instância secundária. Para configurar esse padrão, consulte Configurar um MongoDB Ops Manager secundário para fazer backup do MongoDB Ops Manager.
Considerações
Restaurar Ordem
A sequência de restauração dos bancos de dados de apoio e inicialização do MongoDB Ops Manager primário é crítica.
Aviso
Restaure os bancos de dados de apoio antes de iniciar o MongoDB Ops Manager primário. Se você iniciar o MongoDB Ops Manager primário antes de restaurar seus bancos de dados de apoio, o MongoDB Ops Manager primário poderá gravar um estado inconsistente e criar um cenário de divisão de cérebro entre as implantações antigas e novas.
Se o MongoDB Ops Manager secundário também fizer backup do armazenamento de metadados de snapshot e do armazenamento de metadados de oplog, restaure todos os três bancos de dados de apoio para o mesmo ponto no tempo ou restaure os armazenamentos de metadados para um ponto ligeiramente posterior no tempo do que o banco de dados de aplicativo, antes de iniciar o MongoDB Ops Manager primário. A restauração dos armazenamentos de metadados para um ponto anterior ao banco de dados de aplicativo faz com que o MongoDB Ops Manager primário rejeite as tarefas de restauração afetadas com HTTP 409 ("blocos de snapshot ausentes").
Ponto de recuperação
Uma restauração point-in-time recupera o banco de dados de aplicativo para o ponto no tempo que você seleciona, não para o momento do desastre. As operações que o backup não capturou em um oplog slice antes do desastre podem não ser recuperáveis. Selecione um ponto de restauração o mais próximo possível do desastre que sua janela de recuperação point-in-time permitir.
Depois que o MongoDB Ops Manager primário for reiniciado, a reconciliação recuperará a configuração de automação de implantação dos agentes do MongoDB. Outras alterações recentes no banco de dados de aplicativo refletem o ponto de restaurar selecionado.
Compatibilidade de versão
As versões primária e secundária do MongoDB Ops Manager devem permanecer compatíveis.
Aviso
Restaure o banco de dados de aplicativo para um MongoDB Ops Manager primário que executa a mesma versão ou uma versão posterior do MongoDB Ops Manager primário original do qual o snapshot foi tirado. Se o binário de substituição for mais antigo do que a versão registrada do banco de dados de aplicativo, o MongoDB Ops Manager se recusará a iniciar com um erro de "Downgrades não são permitidos".
Pré-requisitos
O modo de restauração é habilitado por padrão no MongoDB Ops Manager 8.0.24 e posterior. Se você o desativou, reative-o no MongoDB Ops Manager primário antes de restaurar. Para as etapas, consulte Configurar um MongoDB Ops Manager secundário para fazer backup do MongoDB Ops Manager.
Confirme se o MongoDB Ops Manager secundário tem um snapshot concluído e uma janela de recuperação contínua point-in-time para os bancos de dados de apoio.
Confirme se você preservou o estado necessário por host para recuperação, incluindo o arquivo
gen.keyda instalação original do MongoDB Ops Manager primário.
Preservar o estado por hospedar
Uma recuperação completa do MongoDB Ops Manager primário requer mais do que o banco de dados de aplicativo. Preserve o seguinte estado em cada hospedar, além do banco de dados de aplicativo que o MongoDB Ops Manager secundário faz backup:
Item | Localização | Descrição |
|---|---|---|
chave de criptografia |
| Criptografa o conteúdo do banco de dados de aplicativo. Deve corresponder à chave usada para a instalação original, ou o MongoDB Ops Manager primário não poderá descriptografar o banco de dados de aplicativo restaurado na inicialização. |
Configuração do MongoDB Ops Manager |
| Armazena URIs de banco de dados, configuração de blockstore, chaves de licença e certificados TLS. Sem ele, você deve reconfigurar o MongoDB Ops Manager primário manualmente. |
Configuração do agente |
| Armazenar |
Importante
Se o arquivo gen.key estiver ausente ou não corresponder ao banco de dados de aplicativo restaurado, o Ops Manager primário falhará em sua verificação pré-voo de inicialização com um erro de que gen.key não corresponde à chave já usada para esta instalação do Ops Manager. Mantenha gen.key em seu backup de recuperação de desastre junto com os dados do banco de dados do aplicativo.
Restaure o MongoDB Ops Manager primário
Restaurar os bancos de dados de apoio
No MongoDB Ops Manager secundário, restaure o banco de dados de aplicativo do MongoDB Ops Manager primário para o ponto no tempo que você escolheu:
Clique em Continuous Backup e selecione o conjunto de réplicas do banco de dados do aplicativo.
Clique no menu e, em seguida, clique em Restore.
Selecione Point in Time e, em seguida, insira a data e a hora de destino.
Clique em Choose Cluster to Restore to, selecione os hosts do conjunto de réplicas do banco de dados de aplicativo e, em seguida, clique em Restore.
O MongoDB Agent do Ops Manager secundário interrompe os processos do banco de dados do aplicativo, substitui os dados pelo snapshot restaurado, reproduz o oplog para o tempo de destino e reinicia os processos.
Aviso
Se o MongoDB Ops Manager secundário também fizer backup do snapshot e dos armazenamentos de metadados do oplog, restaure-os para o mesmo ponto no tempo que o banco de dados do aplicativo, ou para um ponto um pouco posterior, antes de iniciar o MongoDB Ops Manager primário. A restauração dos armazenamentos de metadados para um ponto anterior faz com que o MongoDB Ops Manager primário rejeite as tarefas de restauração afetadas com HTTP 409 ("blocos de snapshot ausentes").
Se você restaurar apenas o banco de dados de aplicativo, o Ops Manager secundário deixará os armazenar de metadados inalterados. Isso é seguro para operações normais, mas os snapshots de backup que o MongoDB Ops Manager primário tirou entre o ponto de restauração e agora podem não estar disponíveis.
Inicie o MongoDB Ops Manager primário
Inicie o Ops Manager primário. O Ops Manager primário conecta-se ao banco de dados de aplicativo restaurado, lê o estado restaurado e inicia a recuperação. Para aprender mais, consulte Iniciar e parar o aplicativo de Ops Manager.
Deixe a reconciliação ser concluída
O MongoDB Ops Manager primário entra no modo de restauração e reconcilia a configuração da implantação automaticamente. Enquanto a reconciliação é executada, o MongoDB Ops Manager primário mostra um banner do modo de restauração. Nenhuma ação manual é necessária. O MongoDB Ops Manager primário sai do modo de restauração quando a reconciliação é concluída.
Modo de Restauração e Reconciliação
Depois de restaurar o banco de dados de aplicativo e iniciar o MongoDB Ops Manager primário, o MongoDB Ops Manager primário compara a versão de configuração de cada MongoDB Agent com a versão de configuração restaurada. Se um agente relatar uma versão posterior, o MongoDB Ops Manager primário entrará no modo de restauração para esse projeto e reconciliará a configuração automaticamente:
O principal Ops Manager isola o projeto. Ele mostra um banner do Modo de Restauração, retorna uma resposta inalterada às pesquisas do agente e bloqueia alterações de implantação na interface do usuário e na API até que a reconciliação seja concluída.
O MongoDB Ops Manager primário coleta a versão de configuração de cada agente, seleciona o agente com a configuração mais recente e grava essa configuração no banco de dados de aplicativo como a configuração autoritativa.
O MongoDB Ops Manager primário sai do modo de restauração do projeto e retoma a operação normal. O backup é retomado automaticamente.
Essa reconciliação evita um cenário de divisão do cérebro. Ele converge todos os agentes em uma única configuração autoritativa antes que qualquer agente receba uma nova configuração.
Quando você reverte o banco de dados de aplicativo para um ponto anterior no tempo, a configuração restaurada não inclui mais as alterações de implantação feitas após o ponto de restaurar. Sem reconciliação, os agentes recebem a configuração mais antiga e interrompem os processos que a configuração não referencia mais. O impacto depende da alteração de implantação:
Alteração de implantação | Risco sem reconciliação |
|---|---|
Nó do conjunto de réplicas | Os dados existem em outros nós, portanto, você não perde dados. |
Novo shard com partes migradas | As partes migradas existem apenas no novo shard. Pará-lo torna esses dados inacessíveis, o que causa perda de dados. |
Nova versão do processo | O processo não pode ser executado na versão binária revertida, o que causa desvio operacional. |
Novo índice | As query de índice se degradam até que o MongoDB Ops Manager reconstrua o índice. |
A reconciliação evita esses resultados. O MongoDB Ops Manager primário converge todos os agentes na configuração mais recente e enfileira um snapshot sob demanda antes de sair do modo de restauração, o que fornece um ponto de backup coerente.
Validar o MongoDB Ops Manager restaurado
Confirme se o MongoDB Ops Manager primário restaurado está saudável:
Confirme se os agentes do MongoDB se reconectam e relatam como saudáveis.
Confirme se a automação, o backup e o monitoramento são retomados para suas implantações gerenciadas.
Confirme se o MongoDB Ops Manager primário sai do modo de restauração. Para verificar o status do modo de restauração, envie uma solicitação
GETpara o seguinte ponto de extremidade como um usuário com a funçãoProject Read Only. A resposta mostra o estado atual, o motivo do trigger e os carimbos de data/hora do projeto:GET /api/public/v1.0/groups/{PROJECT-ID}/restorationMode
Recuperar de uma reconciliação presa
Se o MongoDB Ops Manager primário for reiniciado enquanto estiver no modo de restauração, ele aciona novamente a reconciliação na próxima pesquisa do MongoDB Agent. Você não precisa tomar nenhuma ação para o caso de reinício.
A reconciliação pode não ser concluída, por exemplo, porque os agentes estão inacessíveis. Nesse caso, use um dos seguintes pontos de extremidade da API como um usuário com a função Project Owner:
Para tentar a reconciliação novamente, envie uma solicitação
POSTpara o seguinte ponto de extremidade. A nova tentativa redefine o contador de falhas de reconciliação e executa a reconciliação novamente sem sair do modo de restauração:POST /api/public/v1.0/groups/{PROJECT-ID}/restorationMode/retry Para forçar o MongoDB Ops Manager primário a sair do modo de restauração e aceitar a configuração restaurada, envie uma solicitação
DELETEpara o seguinte ponto de extremidade:DELETE /api/public/v1.0/groups/{PROJECT-ID}/restorationMode
Aviso
Quando você força o MongoDB Ops Manager primário a sair do modo de restauração, ele aceita a configuração restaurada sem reconciliar as configurações posteriores do agente. Use este ponto de extremidade somente quando a reconciliação não puder ser concluída. Após a saída forçada, o MongoDB Ops Manager primário serve a configuração restaurada para todos os agentes no projeto e não reentrará no modo de restauração até que todos os agentes tenham convergido para ele.
Cortar para o MongoDB Ops Manager restaurado
Este padrão restaura o MongoDB Ops Manager primário no local. Ele não promove o MongoDB Ops Manager secundário para substituir o MongoDB Ops Manager primário.
Depois de validar o MongoDB Ops Manager primário restaurado, conclua a transição:
Atualize a configuração
URL to Access Ops Managere todos os registros DNS para apontar para o MongoDB Ops Manager primário restaurado.Confirme se os agentes do MongoDB se conectam ao MongoDB Ops Manager primário restaurado. Os agentes se reconectam sem novo registro quando o
mmsGroupIde ommsApiKeyem sua configuração correspondem aos registros de projeto restaurados.
Orientação operacional
Use as práticas a seguir para operar e validar esse padrão ao longo do tempo.
Testar Fazer backup e restaurar
Uma restauração não testada é um risco operacional. Teste este caminho de backup e restauração regularmente. Trate o seguinte runbook como uma prática necessária, não como orientação opcional:
Execute uma restauração de teste em um agendar. Restaure os bancos de dados de apoio para um sandbox MongoDB Ops Manager e confirme se ele inicia e reconcilia.
Confirme se os snapshots aparecem no agendamento e se a janela de recuperação point-in-time permanece contínua.
Revisar os logs primários do MongoDB Ops Manager e secundários do MongoDB Ops Manager para erros de backup e restauração.
Monitorar o MongoDB Ops Manager secundário
Monitore o MongoDB Ops Manager secundário e os bancos de dados de apoio que ele faz backup:
Use alertas de backup do MongoDB Ops Manager para observar snapshots perdidos ou com falha dos bancos de dados de apoio.
Confirme se a janela de recuperação point-in-time permanece contínua e continua avançando.
Monitore a integridade do banco de dados de aplicativo do MongoDB Ops Manager secundário e do Backup Daemon.
Cenários de falha
A tabela a seguir descreve como esse padrão se comporta em cenários comuns de falha:
Cenário | Impacto | Recuperação |
|---|---|---|
MongoDB Ops Manager secundário temporariamente indisponível | Novos backups e restaurações são pausados. O Ops Manager primário e todos os agentes gerenciados continuam em execução. | Restaure o MongoDB Ops Manager secundário. Os agentes de backup são retomados automaticamente. |
O MongoDB Ops Manager secundário falha após uma restauração | Nenhum. Depois de restaurar o banco de dados de aplicativo, o Ops Manager primário entra no modo de restauração e reconcilia sem o Ops Manager secundário. | Nenhuma ação necessária. |
Perda de ambas as instâncias do MongoDB Ops Manager | Você perde a recuperação pontual para o banco de dados de aplicativo primário do MongoDB Ops Manager. | Reconstrua o Ops Manager secundário e reimporte o banco de dados de aplicativo, ou reconstrua o Ops Manager primário e reimporte seus clusters manualmente. |
Considerações de desempenho, armazenamento e custo
Considere o seguinte ao executar um MongoDB Ops Manager secundário dedicado:
Dimensione o MongoDB Ops Manager secundário materialmente menor do que um MongoDB Ops Manager primário de produção. Ele gerencia apenas os bancos de dados de apoio do MongoDB Ops Manager primário para backup e restaurar, e não gerencia seus clusters MongoDB.
Planeje a capacidade de armazenamento de snapshot para os bancos de dados de apoio com base em sua programação de snapshot e política de retenção.
Considere os custos adicionais de infraestrutura e operacionais de execução de um MongoDB Ops Manager secundário dedicado.