Você pode implantar uma segunda instância do MongoDB Ops Manager, chamada de MongoDB Ops Manager secundário, para fazer backup de um MongoDB Ops Manager primário e seus bancos de dados de apoio. O MongoDB Ops Manager secundário também serve como seu caminho de recuperação se você perder o MongoDB Ops Manager primário.
Este padrão protege os dados operacionais que o MongoDB Ops Manager armazena em seu banco de dados de aplicativo e armazenamentos de metadados. Use este guia para projetar, configurar e operar a recuperação de desastre para o próprio MongoDB Ops Manager.
Este guia é para administradores do MongoDB Ops Manager que gerenciam backup e recuperação de desastre e para equipes que projetam topologias de alta disponibilidade e recuperação de desastre para o MongoDB Ops Manager.
Como funciona o backup do MongoDB Ops Manager secundário
Nesse padrão, duas instâncias do MongoDB Ops Manager têm responsabilidades distintas:
O MongoDB Ops Manager primário gerencia suas implantações do MongoDB e seus backups, como de costume.
O MongoDB Ops Manager secundário gerencia e faz backup apenas dos bancos de dados de apoio do MongoDB Ops Manager primário. O MongoDB Ops Manager secundário não gerencia seus cluster de aplicativos.
O MongoDB Agent é executado em cada host do banco de dados de aplicativo do MongoDB Ops Manager primário e se registra no MongoDB Ops Manager secundário. O MongoDB Ops Manager secundário faz backups contínuos e pontuais desses bancos de dados de apoio.
Se você perder 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. O MongoDB Ops Manager primário se reconecta aos bancos de dados de apoio restaurados e retoma o gerenciamento de suas implantações do MongoDB.
Quando os agentes do MongoDB se reconectam após a reinicialização, eles relatam uma versão de configuração mais recente do que o banco de dados restaurado. O Ops Manager primário detecta a incompatibilidade, entra automaticamente no modo de restauração para o projeto afetado, converge todos os agentes na configuração restaurada e bloqueia as alterações de implantação até que a reconciliação seja concluída.
Arquitetura
A tabela a seguir descreve os componentes neste padrão e suas responsabilidades:
Componente | Responsabilidade |
|---|---|
MongoDB Ops Manager primário | Gerencia suas implantações do MongoDB e seus backups. Armazena seus próprios dados operacionais em seu banco de dados de aplicativo, armazenamento de metadados de snapshot e armazenamento de metadados de oplog. |
Ops Manager secundário | Executa um Backup Daemon que grava em um blockstore de armazenamento compatível com S3para snapshots de banco de dados de aplicativo e fatias de oplog. Faz backup continuamente dos bancos de dados de apoio do MongoDB Ops Manager primário. Não gerencia seus clusters de aplicativo. |
Banco de dados de aplicativos | Armazena os dados operacionais do MongoDB Ops Manager primário, incluindo configuração do projeto, estado de automação e metadados de backup. Você deve fazer backup do banco de dados de aplicativo. |
Repositórios de metadados de snapshot e oplog | Armazene o bloco e os índices oplog para as implantações que o MongoDB Ops Manager primário faz backup. Faça backup dessas lojas também. |
MongoDB Agent | Executa em cada host de banco de dados de apoio e registra-se no MongoDB Ops Manager secundário para executar backup e restaurações. |
O MongoDB Ops Manager secundário armazena os backups dos bancos de dados de apoio do MongoDB Ops Manager primário em seu próprio blockstore de armazenamento compatível com S3, separado do armazenamento de backup do MongoDB Ops Manager primário.
Variantes de implantação
Implante o MongoDB Ops Manager secundário em um domínio de falha separado do MongoDB Ops Manager primário para evitar que uma única falha afete ambas as instâncias. As variantes comuns incluem:
Região diferente
Implante o MongoDB Ops Manager secundário em uma região de nuvem diferente do MongoDB Ops Manager primário. Essa variante protege contra a perda de uma região.
Data center diferentes
Implante o MongoDB Ops Manager secundário em um data center diferente do MongoDB Ops Manager primário. Esta variante protege contra a perda de um data center.
Rede de backup separada
Coloque o MongoDB Ops Manager secundário em uma rede separada dedicada ao tráfego de backup. Essa variante isola o tráfego de backup da rede do seu aplicativo.
Importante
Implante o MongoDB Ops Manager secundário em um domínio de falha separado, como um rack, zona de disponibilidade, região ou segmento de rede diferente do MongoDB Ops Manager primário. Se ambas as instâncias compartilharem um domínio de falha, uma única falha poderá interromper o MongoDB Ops Manager primário e seu caminho de recuperação.
Versões e limitações compatíveis
Antes de usar esse padrão, revise os seguintes requisitos e limitações.
Versões suportadas
Tanto as instâncias primárias quanto as secundárias do MongoDB Ops Manager devem executar o MongoDB Ops Manager 8.0.24 ou posterior.
O MongoDB Ops Manager secundário deve executar a mesma versão ou uma versão posterior do que o MongoDB Ops Manager primário. Não execute um MongoDB Ops Manager secundário que seja uma versão anterior do que o MongoDB Ops Manager primário.
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".
Limitações
Este padrão faz backup dos bancos de dados de apoio do MongoDB Ops Manager primário. Ele não faz backup de clusters MongoDB arbitrários. O MongoDB Ops Manager primário continua a gerenciar backups para suas implantações MongoDB.
Fazer backup e reconciliar o armazenamento de metadados de snapshot e o armazenamento de metadados de oplog é um procedimento manual. O MongoDB Ops Manager não seleciona automaticamente um ponto de restaurar para esses armazenamentos. Como resultado, os metadados de backup podem ser inconsistentes após uma restauração, e alguns backups podem não ser restauráveis. O MongoDB Ops Manager valida um snapshot antes de restaurá-lo e falha com um erro em vez de executar uma restauração insegura.
O modo de restauração não se aplica a implantações gerenciadas externamente, como implantações que um operador do Kubernetes gerencia. Depois de restaurar o banco de dados do aplicativo, os agentes nesses projetos recebem a configuração restaurada diretamente em sua próxima pesquisa e convergem sem entrar no modo de restauração. Nenhuma ação é necessária para esses projetos.
Um snapshot pode se tornar irrecuperável se seus blocos de dados não estiverem mais no armazenamento de snapshots. Antes de uma restauração, o MongoDB Ops Manager primário verifica se os blocos do snapshot existem. Se os blocos estiverem ausentes, a restauração falhará com um erro e deixará o conjunto de réplicas inalterado, em vez de apagá-lo e falhar no meio do processo.
Uma restauração não testada é um risco operacional. Valide o caminho de backup e restaurar regularmente. Consulte o runbook de validação em Restaurar o MongoDB Ops Manager a partir de um MongoDB Ops Manager secundário.
Próximos passos
Para configurar e operar este padrão, consulte as seguintes páginas: