Restaurar um cluster fragmentado a partir de um snapshot
Nesta página
Quando você restaura um cluster a partir de um snapshot, o Ops Manager fornece arquivos de restauração para o ponto de restauração selecionado.
Para saber mais sobre o processo de restauração, consulte Visão Geral da Restauração.
Importante
Alterado no Ops Manager 3.6: restaurações de ponto no tempo
Antes de 3.6, o Backup Daemon criou a restauração point-in-time completa em seu host. Com o 3.6, você baixa uma ferramenta do lado do cliente junto com seu snapshot. Essa ferramenta baixa e aplica o oplog a um snapshot no sistema do cliente. Isso reduz as necessidades de rede e armazenamento para o sistema do MongoDB Ops Manager.
Considerações
Revise a alteração no BinData subtipo de BSON
A especificação BSON alterou o subtipo padrão para o tipo de dados binários BSON (BinData) de 2 para 0. Alguns dados binários armazenados em um snapshot podem ser BinData subtipo 2. O Backup detecta e converte automaticamente dados de snapshot no BinData subtipo 2 para BinData subtipo 0. Se o código do aplicação espera BinData subtipo 2, você deverá atualizar o código do aplicação para funcionar com BinData subtipo 0.
Restaurar usando as configurações fornecidas em restoreInfo.txt
O arquivo de restauração da cópia de segurança inclui um arquivo de metadados denominado restoreInfo.txt. Esse arquivo captura as opções que o banco de dados usou quando o snapshot foi tirado. O banco de dados deve ser executado com as opções listadas após ser restaurado. Este arquivo contém:
groupName
ReplicaSetName
ID do cluster (se aplicável)
Carimbo de data/ hora do snapshot (como registro de data/hora em UTC)
Restaurar carimbo de data/hora (como carimbo de data/hora BSON em UTC)
Último oplog aplicado (como carimbo de data/hora BSON em UTC)
Versão do MongoDB
tipo storage engine
opções de inicialização do mongod usadas no banco de dados quando o snapshot foi tirado
Criptografia (só aparece se a criptografia estiver habilitada no snapshot)
UUID da chave mestra (só aparece se a criptografia estiver habilitada no snapshot)
Se estiver restaurando a partir de um backup criptografado, você deverá ter um certificado provisionado para essa chave mestra.
Considerações de backup
Todos os reconhecimento de data centerFCV do devem atender às considerações de backup apropriadas.
Considerações de criptografia
Para restaurar a partir de um backup criptografado, você precisa da mesma chave mestra usada para criptografar o backup e do mesmo certificado que está no host do Backup Daemon ou de um novo certificado provisionado com essa chave do host KMIP .
Se o snapshot for criptografado, o painel de restauração exibirá o id da chave mestra KMIP e as informações do servidor KMIP. Você também pode encontrar as informações ao visualizar o próprio snapshot, bem como no arquivo restoreInfo.txt .
Desabilitar solicitações de clientes para MongoDB durante a restauração
Você deve garantir que a implementação do MongoDB não receba solicitações de clientes durante a restauração. Você deve:
Restaure em novos sistemas com novos nomes de host e reconfigure o código do seu aplicativo assim que a nova implantação estiver em execução ou
Certifique-se de que a implementação do MongoDB não receba solicitações de clientes enquanto você restaura os dados.
Restaurar um snapshot
Para que o Ops Manager restaure automaticamente o snapshot:
Selecione o ponto de restauração.
Escolha o ponto de partida do qual deseja restaurar o backup.
Tipo de RestauraçãoDescriçãoem açãoSnapshot
Permite escolher um snapshot armazenado.
Selecione um snapshot existente para restaurar.
Point In Time
Cria um snapshot personalizado que inclui todas as operações até, mas não incluindo, o horário selecionado. Por padrão, o Oplog Store armazena 24 horas de dados.
Por exemplo, se você selecionar
12:00, a última operação na restauração será11:59:59ou anterior.IMPORTANTE: no FCV 4.0, você não pode executar uma restauração de PIT que abranja qualquer momento anterior à última ressincronização de backup. Para saber as condições que causam uma ressincronização, consulte Sincronizar novamente um backup. Esta nota não se aplica ao FCV 4.2 ou posterior.
Selecione um Date e Time.
Oplog Timestamp
Cria um snapshot personalizado que inclui todas as operações até e incluindo o carimbo de data/hora do oplog inserido. O registro de data e hora do oplog contém dois campos:
Timestamp
Registro de data/hora no número de segundos decorridos desde a UNIX epoch
Increment
Ordem de operação aplicada naquele segundo como um ordinal de 32 bits.
Digite um oplog Timestamp e Increment.
Execute uma query em
local.oplog.rsno seu conjunto de réplicas para encontrar o carimbo de data/hora desejado.Clique em Next.
Escolha restaurar os arquivos para outro cluster.
Clique em Choose Cluster to Restore to.
Preencha os seguintes campos:
Campoem açãoProject
Cluster to Restore to
Selecione um cluster no qual você deseja restaurar o snapshot.
O gerente de operações deve gerenciar o cluster fragmentado de destino.
AVISO: a automação remove todos os dados existentes do cluster. Ele preserva todos os dados de backup e snapshots do cluster existente.
Clique em Restore.
O Ops Manager observa quanto espaço de armazenamento a restauração exige em sua interface de usuário.
Importante
Girar chave-mestra após restaurar snapshots criptografados com AES256-GCM
Se você restaurar um snapshot criptografado que o Ops Manager criptografou com AES256-GCM, gire sua chave mestra após concluir a restauração.
O processo de restauração manual pressupõe que:
O host de destino não tem dados implementados.
Você não usou um snapshot criptografado.
Você não habilitou a autenticação de dois fatores.
Aviso
Restaure o snapshot manualmente somente se não puder executar uma restauração automática. Se você determinar que deve usar uma restauração manual, entre em contato com o suporte do MongoDB para obter ajuda. Esta seção fornece uma visão geral de alto nível dos estágios do procedimento de restauração manual.
O processo de restauração manual tem os seguintes estágios de alto nível que você executa com a ajuda do Suporte do MongoDB :
Conecte-se a cada conjunto de réplicas e ao Config Server Replica Set (CSRS) com o shell
mongolegado oumongosh.(Opcional). Revise o arquivo de configuração de cada conjunto de réplicas e CSRS. Depois de concluir o processo de restauração, você poderá reconstruir a configuração nos conjuntos de réplicas restauradas usando os arquivos de configuração salvos.
Pare todos os processos do
mongodem execução nos hosts de destino.Provisione espaço de armazenamento suficiente para manter os dados restaurados.
Prepare diretórios para dados e registros.
Adicione um arquivo de configuração ao diretório do MongoDB Server com os caminhos de armazenamento e registro do host de destino e a configuração para réplicas e funções de fragmentação.
O procedimento de restauração manual completo pode ser encontrado na documentação do MongoDB Server 4.2 . Para o MongoDB 4.4 ou sistemas posteriores, consulte as versões correspondentes do manual.