Restaurar um cluster fragmentado a partir de um snapshot
Nesta página
- A autenticação OAuth 2.0 para acesso programático ao Cloud Manager está disponível como um recurso de visualização.
- O recurso e a documentação correspondente podem mudar a qualquer momento durante o período de Pré-visualização. Para usar a 2.0 autenticação OAuth, crie uma conta de serviço para usar em suas solicitações para a API pública do Cloud Manager .
Quando você restaura um cluster a partir de um snapshot, o Cloud 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.
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
mongodopções de inicialização usadas no banco de dados quando o snapshot foi tirado
Snapshots quando o agente não consegue parar o balanceador
O Cloud Manager exibe um aviso ao lado dos snapshots de cluster obtidos enquanto o balanceador 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.
Considerações de backup
Todos os reconhecimento de data centerFCV do devem atender às considerações de backup apropriadas.
Considerações de criptografia
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 Cloud Manager restaure automaticamente o snapshot:
No MongoDB Cloud Manager, acesse aGo Continuous Backup página do seu projeto.
Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.
Clique em Continuous Backup na barra lateral.
A página Backup contínuo é exibida.
Selecione o ponto de restauração.
Escolha o ponto de partida do qual deseja restaurar o backup.
Tipo de RestauraçãoDescriçãoem açãoSnapshotPermite escolher um snapshot armazenado.Selecione um snapshot existente para restaurar.Point In TimeCria 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 TimestampCria 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:
TimestampRegistro de data/hora no número de segundos decorridos desde a UNIX epoch
IncrementOrdem 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çãoProjectCluster to Restore toSelecione um cluster no qual você deseja restaurar o snapshot.
O Cloud Manager deve managed 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.
Cloud 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 Cloud 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.
Para que o Cloud Manager restaure automaticamente o snapshot:
No MongoDB Cloud Manager, acesse aGo Continuous Backup página do seu projeto.
Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.
Clique em Continuous Backup na barra lateral.
A página Backup contínuo é exibida.
Selecione o ponto de restauração.
Escolha o ponto de partida do qual deseja restaurar o backup.
Tipo de RestauraçãoDescriçãoem açãoSnapshotPermite escolher um snapshot armazenado.Selecione um snapshot existente para restaurar.Point In TimePermite 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.
Por exemplo, se você selecionar
12:00, a última operação na restauração será11:59:59ou anterior.IMPORTANTE: se você estiver restaurando um cluster fragmentado que execute
FCV4.0 ou anterior, será necessário 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 Cloud Manager solicitará que você choose another point in time.IMPORTANTE: você não pode executar uma restauração de PIT que cubra 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.Clique em Next.
Se você estiver restaurando um cluster fragmentado que executa o
FCV4.0 ou anterior e escolheu Point In Time:Uma lista de Checkpoints mais próximo da hora selecionada aparece.
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.
Escolha restaurar os arquivos para outro cluster.
Clique em Choose Cluster to Restore to.
Preencha os seguintes campos:
Campoem açãoProjectCluster to Restore toSelecione um cluster no qual você deseja restaurar o snapshot.
O Cloud Manager deve managed 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 Cloud Manager observa quanto espaço de armazenamento a restauração exige em seu console.
Importante
Girar chave-mestra após restaurar snapshots criptografados com AES256-GCM
Se você restaurar um snapshot criptografado que o Cloud 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 .