Menu Docs
Página inicial do Docs
/
MongoDB Ops Manager
/ /

Restaurar um cluster fragmentado a partir de um snapshot

Nesta página

  • Considerações
  • Restaurar um snapshot

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.

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.

Dica

Veja também:

As notas sobre a especificação BSON explicar as especificidades desta mudança.

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.

MongoDB Ops Manager exibe um aviso ao lado dos snapshots de cluster obtidos enquanto o balancer está ativado. Se você restaurar a partir desse snapshot, correrá o risco de ter dados perdidos ou órfãos. Para obter mais informações, consulte Snapshots quando o agente não consegue parar o balanceador.

Todos os reconhecimento de data centerFCV do devem atender às considerações de backup apropriadas.

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 .

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.

Para que o Ops Manager restaure automaticamente o snapshot:

1
2
3
  1. Escolha o ponto de partida do qual deseja restaurar o backup.

    Tipo de Restauração
    Descrição
    em ação
    Snapshot
    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:59 ou anterior.

    Importante

    No FCV 4.0, não é possível executar uma restauração de PIT que abranja qualquer momento anterior à ressincronização de backup mais recente. 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.rs no seu conjunto de réplicas para encontrar o carimbo de data/hora desejado.

  2. Clique em Next.

4
  1. Clique em Choose Cluster to Restore to.

  2. Preencha os seguintes campos:

    Campo
    em ação
    Project
    Selecione um projeto para o qual deseja restaurar o snapshot.
    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.

  1. Clique em Restore.

    O Ops Manager observa quanto espaço de armazenamento a restauração exige em sua interface de usuário.

5

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 :

  1. Conecte-se a cada conjunto de réplicas e ao Config Server Replica Set (CSRS) com o shell mongo legado ou mongosh.

  2. (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.

  3. Prepare os hosts de destino.

    • Pare todos os processos do mongod em 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.

  4. Restaure o CSRS.

  5. Restaure o conjunto de réplicas de cada shard.

  6. Reinicie cada processo mongos no cluster de destino.

  7. Verifique se você pode se conectar ao cluster.

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.

Para que o Ops Manager restaure automaticamente o snapshot:

1
2
3
  1. Escolha o ponto de partida do qual deseja restaurar o backup.

    Tipo de Restauração
    Descrição
    em ação
    Snapshot
    Permite escolher um snapshot armazenado.
    Selecione um snapshot existente para restaurar.
    Point In Time

    Permite que você escolha uma data e uma hora como objetivo de tempo de restauração para o snapshot. Por padrão, o oplog Store armazena 24 horas de dados.

    Exemplo

    Se você selecionar 12:00, a última operação na restauração será 11:59:59 ou anterior.

    Importante

    • Se você estiver restaurando um cluster fragmentado que executa FCV de 4.0 ou anterior, deverá ativar os checkpoints do cluster para executar uma restauração PIT em um cluster fragmentado.

      Se nenhum checkpoint que inclua sua data e hora estiver disponível, o MongoDB Ops Manager solicitará que você choose another point in time.

    • Não é possível executar uma restauração do 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.

    Selecione um Date e Time.
  2. Clique em Next.

  3. Se você estiver restaurando um cluster fragmentado que executa FCV de 4.0 ou anterior e escolheu Point In Time:

    1. Uma lista de Checkpoints mais próximo da hora selecionada aparece.

    2. Para iniciar a restauração ponto -in-time, você pode:

      • Escolha um dos pontos de verificação listados ou

      • Clique em Choose another point in time para remover a lista de pontos de verificação e selecionar outra data e hora a partir dos menus.

4
  1. Clique em Choose Cluster to Restore to.

  2. Preencha os seguintes campos:

    Campo
    em ação
    Project
    Selecione um projeto para o qual deseja restaurar o snapshot.
    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.

  1. Clique em Restore.

    MongoDB Ops Manager observa quanto espaço de armazenamento a restauração exige em seu console.

5

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 :

  1. Conecte-se a cada conjunto de réplicas e ao Config Server Replica Set (CSRS) com o shell mongo legado ou mongosh.

  2. (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.

  3. Prepare os hosts de destino.

    • Pare todos os processos do mongod em 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.

  4. Restaure o CSRS.

  5. Restaure o conjunto de réplicas de cada shard.

  6. Reinicie cada processo mongos no cluster de destino.

  7. Verifique se você pode se conectar ao cluster.

O procedimento de restauração manual completo pode ser encontrado na documentação do MongoDB Server .

Voltar

Restaurar de um momento específico