Ao perder o Ops Manager primário, você restaura seus bancos de dados de backup do Ops Manager secundário e, em seguida, inicia um novo Ops Manager primário. Use esse procedimento após um evento , como falha na atualização, exclusão acidental de dados ou falha na infraestrutura. Quando o Ops Manager principal é 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 Ops Manager usando uma instância secundária. Para configurar esse padrão, consulte Configurar um Ops Manager secundário para fazer backup do Ops Manager.
Considerações
Restaurar ordem
A sequência de restaurar os bancos de dados de backup e iniciar o Ops Manager principal é crítica.
Aviso
Restaure os bancos de dados de backup antes de iniciar o Ops Manager principal. Se você iniciar o Ops Manager primário antes de restaurar seus bancos de dados de backup, o Ops Manager principal poderá escrever em um estado inconsistente e criar um cenário de divisão entre os sistemas antigo e novo.
Se o Ops Manager secundário também fizer backup do armazenamento de metadados de snapshots e do armazenamento de metadados oplog, restaure todos os três bancos de dados de backup no mesmo ponto no tempo ou restaure os armazenamentos de metadados em um ponto no tempo um pouco posterior ao banco de dados de aplicativo, antes de iniciar o gerente de operações principal. A restauração dos armazenamentos de metadados para um ponto anterior ao banco de dados de aplicativo faz com que o Ops Manager principal rejeite os trabalhos de restauração afetados com HTTP 409 ("blocos de snapshot ausentes").
Ponto de recuperação
Uma restauração point-in-time recupera o banco de dados de aplicativo no momento ponto selecionado, não no momento do desastre. As operações que o backup não captou em uma fatia de oplog antes do desastre podem não ser recuperáveis. Selecione um ponto de restauração o mais próximo do desastre que a janela de recuperação point-in-time permitir.
Depois que o Ops Manager principal for reiniciado, a reconciliação recupera a configuração de automação de implantação dos MongoDB Agents. Outras alterações recentes no banco de dados de aplicativo refletem o ponto de restauração selecionado.
Compatibilidade de versão
As versões primária e secundária do Ops Manager devem permanecer compatíveis.
Aviso
Restaure o banco de dados de aplicativo em um Ops Manager primário que execute a mesma versão ou uma versão posterior ao Ops Manager principal original do qual o snapshot foi obtido. Se o binário de substituição for mais antigo do que a versão registrada do banco de dados do aplicação , o Ops Manager se recusará a iniciar com um erro "Downgrades não são permitidos".
Pré-requisitos
O modo de restauração é ativado por padrão no Ops Manager 8.0.24 e posteriores. Se você o desabilitou, reative-o no Ops Manager principal antes de restaurar. Para saber as etapas, consulte Configurar um Ops Manager secundário para fazer backup do Ops Manager.
Confirme se o Ops Manager secundário tem um snapshot concluído e uma janela de recuperação point-in-time contínua para os bancos de dados de backup.
Confirme que você preservou o estado por host necessário para recuperação, incluindo o arquivo
gen.keyda instalação original do Ops Manager primário.
Preservar estado por host
Uma recuperação primária completa do Ops Manager exige mais do que o banco de dados de aplicativo. Preservar o seguinte estado em cada host, além do banco de dados de aplicativo que o 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 Ops Manager principal não pode descriptografar o banco de dados de aplicativo restaurado na inicialização. |
Configuração do 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 Ops Manager principal manualmente. |
Configuração do agente |
| Armazena |
Importante
Se o arquivo gen.key estiver ausente ou não corresponder ao banco de dados de aplicativo restaurado, o Ops Manager principal falhará na verificação de simulação de inicialização com um erro de que gen.key não corresponde à chave já usada para essa instalação do Ops Manager. Mantenha o gen.key em sua cópia de segurança do desastre junto com os dados do banco de dados de aplicativo .
Restaurar o Primary Ops Manager
Restaurar os bancos de dados de backup
No Ops Manager secundário, restaure o banco de dados de aplicativo do Ops Manager primary para o ponto no tempo que você escolheu:
Clique em Continuous Backup e selecione o conjunto de réplicas do banco de dados de aplicativo .
Clique no menu e, em seguida, clique Restore em.
Selecione Point in Time e 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 clique em Restore.
O MongoDB Agent do gerente de operações secundário interrompe os processos do banco de dados de aplicativo , substitui os dados pelo snapshot restaurado, reproduz o oplog para o tempo de destino e reinicia os processos.
Aviso
Se o Ops Manager secundário também fizer backup dos armazenamentos de metadados de snapshots e oplog, restaure-os para o mesmo ponto no tempo que o banco de dados de aplicativo ou para um ponto ligeiramente posterior antes de iniciar o Ops Manager primário. A restauração dos armazenamentos de metadados para um ponto anterior faz com que o Ops Manager principal rejeite os trabalhos de restauração afetados com HTTP 409 ("blocos de snapshot ausentes").
Se você restaurar apenas o banco de dados de aplicativo, o Ops Manager secundário deixará os armazenamentos de metadados inalterados. Isso é seguro para a operação normal, mas os snapshots de backup que o Ops Manager principal tirou entre o ponto de restauração e agora podem estar indisponíveis.
Inicie o Ops Manager principal
Inicie o Ops Manager principal. O Ops Manager principal se conecta ao banco de dados de aplicativo restaurado , lê o estado restaurado e inicia a recuperação. Para saber mais, consulte Iniciar e parar o aplicativo de Ops Manager.
Permita que a reconciliação seja concluída
O Ops Manager principal entra no Modo de Restauração e reconcilia a configuração de implantação automaticamente. Enquanto a reconciliação é executada, o gerente de operações principal mostra um banner do modo de restauração. Nenhuma ação manual é necessária. O gerente de operações principal 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 Ops Manager primário, o Ops Manager principal 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 gerente de operações principal entrará no modo de restauração desse projeto e reconciliará a configuração automaticamente:
O principal Ops Manager isola o projeto. Ela 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 gerente de operações 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 gerente de operações principal sai do modo de restauração do projeto e retoma a operação normal. Os backups são retomados automaticamente.
Essa reconciliação evita um cenário de quebra de ideias. Ele converge todos os agentes em uma única configuração autoritária antes que qualquer agente receba uma nova configuração.
Quando você reverte o banco de dados de aplicativo para um ponto no tempo anterior, a configuração restaurada não inclui mais as alterações de implantação que você fez após o ponto de restauração. Sem reconciliação, os agentes recebem a configuração mais antiga e interrompem os processos que a configuração não faz mais referência. O impacto depende da alteração do sistema:
Alteração do sistema | Risco sem reconciliação |
|---|---|
Novo membro do conjunto de réplicas | Os dados existem em outros membros, então você não perde dados. |
Novo shard com chunks migrados | Os chunks migrados existem somente no novo shard. Interrompê-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 queries de índice se degradam até que o Ops Manager reconstrói o índice. |
A reconciliação evita esses resultados. O Ops Manager principal 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 Ops Manager restaurado
Confirme se o Ops Manager primário restaurado está íntegro:
Confirme que os MongoDB Agents se reconectam e relatam como íntegros.
Confirme que a automação, o backup e o monitoramento são retomados para suas implementações gerenciadas.
Confirme que o gerente de operações principal sai do modo de restauração. Para verificar o status do modo de restauração, envie uma
GETsolicitação de para o seguinte endpoint como um usuário com a função. A resposta mostra o estado atual, a razão do trigger e os registros de data/hora doProject Read Onlyprojeto:GET /api/public/v1.0/groups/{PROJECT-ID}/restorationMode
Recuperar-se de uma reconciliação paralisada
Se o Ops Manager principal for reiniciado enquanto estiver no Modo de Restauração, ele acionará novamente a reconciliação na próxima pesquisa do MongoDB Agent . Você não precisa tomar ação para o caso de reinicialização.
A reconciliação pode não ser concluída, por exemplo , porque os agentes não estão acessíveis. Nesse caso, use um dos seguintes endpoints de API como um usuário com a Project Owner função:
Para tentar novamente a reconciliação, envie uma solicitação de
POSTpara o seguinte endpoint. A nova tentativa definia o contador de falhas de reconciliação e executava novamente a reconciliação sem sair do Modo de Restauração:POST /api/public/v1.0/groups/{PROJECT-ID}/restorationMode/retry Para forçar o Ops Manager principal a sair do Modo de Restauração e aceitar a configuração restaurada, envie uma solicitação de
DELETEpara o seguinte endpoint:DELETE /api/public/v1.0/groups/{PROJECT-ID}/restorationMode
Aviso
Quando você força o Ops Manager principal a sair do Modo de Restauração, ele aceita a configuração restaurada sem reconciliar as configurações posteriores do agente . Use esse endpoint somente quando a reconciliação não puder ser concluída. Após a saída forçada, o Ops Manager principal fornece a configuração restaurada a todos os agentes do projeto e não entrará novamente no Modo de Restauração até que todos os agente tenham convergido para ele.
Corta para o Ops Manager restaurado
Esse padrão restaura o Ops Manager principal no local. Ele não promover o Ops Manager secundário para substituir o Ops Manager principal.
Depois de validar o Ops Manager principal restaurado, conclua a transição:
Atualize a configuração
URL to Access Ops Managerdo e quaisquer registros DNS para ponto para o Ops Manager primário restaurado.Confirme que os MongoDB Agents se conectam ao Ops Manager primary restaurado. Os agentes se reconectam sem novo registro quando
mmsGroupIdemmsApiKeyem sua configuração correspondem aos registros de projeto restaurados.
Orientação operacional
Use as seguintes práticas para operar e validar esse padrão ao longo do tempo.
Teste o caminho de backup e restauração
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 obrigatória, não como uma orientação opcional:
Execute uma restauração de teste em um cronograma. Restaure os bancos de dados de backup em um Ops Manager de sandbox e confirme que ele é iniciado e reconciliado.
Confirme que os snapshots aparecem dentro do cronograma e que a janela de recuperação point-in-time permanece contínua.
Revise os registros primários do Ops Manager e secundários do Ops Manager em busca de erros de backup e restauração.
Monitore o gerente de operações secundário
Monitore o Ops Manager secundário e os bancos de dados de backup dos quais ele faz backup:
Use os alertas de backup do Ops Manager para observar snapshots perdidos ou com falha dos bancos de dados de backup.
Confirme que a janela de recuperação pontual permanece contínua e continua avançando.
Monitore a integridade do banco de dados de aplicativo do 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 de falha comuns:
Cenário | Impacto | Recuperação |
|---|---|---|
Gerente de operações secundário temporariamente indisponível | Novos backups e restaurações são pausados. O gerente de operações primário e todos os agentes gerenciados continuam em execução. | Restaure o Ops Manager secundário. Os agentes de backup são retomados automaticamente. |
O Ops Manager secundário falha após uma restauração | Nenhum. Depois de restaurar o banco de dados de aplicativo, o Ops Manager principal entra no Modo de Restauração e se reconcilia sem o Ops Manager secundário. | Nenhuma ação necessária. |
Perda de ambas as instâncias do Ops Manager | Você perde a recuperação point-in-time para o banco de dados de aplicativo do primary Ops Manager. | Reconstrua o Ops Manager secundário e importe novamente o banco de dados de aplicativo, ou reconstrua o Ops Manager primary e importe novamente os clusters manualmente. |
Considerações sobre desempenho, armazenamento e custo
Considere o seguinte ao executar um Ops Manager secundário dedicado:
Dimensione o Ops Manager secundário materialmente menor do que um Ops Manager principal de produção. Ele gerencia apenas os bancos de dados de backup do Ops Manager principal para backup e restauração e não gerencia seus clusters MongoDB .
Planeje a capacidade de armazenamento de snapshots para os bancos de dados de apoio com base em sua programação de snapshots e política de retenção.
Considere a infraestrutura extra e o custo operacional de executar um Ops Manager secundário dedicado.