Restaurar um conjunto de réplicas autogerenciado de backups do MongoDB
Nesta página
Este procedimento descreve o processo de obtenção de dados do MongoDB e restauração desses dados em um novo conjunto de réplicas. Use essa abordagem para semear implantações de teste a partir de backups de produção ou como parte da recuperação de desastres.
Importante
Você não pode restaurar um único conjunto de dados para três novas instâncias do mongod e então criar um conjunto de réplica. Se você copiar o conjunto de dados para cada instância do mongod e então criar o conjunto de réplica, o MongoDB forçará os segundários a executar uma sincronização inicial. Os procedimentos deste documento descrevem formas corretas e eficientes de implantar um conjunto de réplicas restauradas.
Você também pode utilizar o mongorestore para restaurar arquivos do banco de dados utilizando dados criados com mongodump. Consulte Fazer backup e restaurar uma implantação autogerenciada com ferramentas do MongoDB para obter mais informações.
Restaurar banco de dados em um conjunto de réplicas de nó único
Obter arquivos de backup do Banco de dados MongoDB.
Os arquivos de backup podem vir de um snapshot do sistema de arquivos. O MongoDB Cloud Manager produz arquivos de banco de dados MongoDB para snapshots armazenados e snapshots pontuais. Para o Ops Manager, uma solução local disponível no MongoDB Enterprise Advanced, consulte também a visão geral do Ops Manager Backup.
- Considerações para mecanismos de armazenamento criptografados
- Para mecanismos de armazenamento criptografados que usam
AES256-GCMmodo de criptografia,AES256-GCMexige que cada processo use um valor de bloqueio de contador exclusivo com a chave. Para mecanismo de armazenamento criptografado configurado comAES256-GCMcifra:- Restauração a partir de um hot backup
- A partir da versão 4.2, se você restaurar a partir de arquivos obtidos via backup "quente" (ou seja, o
mongodestá em execução), o MongoDB pode detectar chaves "sujas" na inicialização e rolar automaticamente a chave do banco de dados para evitar a reutilização IV (Initialization Vector).
- Restaurando a partir do Cold Backup
No entanto, se você restaurar a partir de arquivos obtidos via backup "frio" (ou seja, o
mongodnão está em execução), o MongoDB não poderá detectar chaves "sujas" na inicialização, e a reutilização do IV anulará as garantias de confidencialidade e integridade.A partir do 4,2, para evitar a reutilização das chaves após restaurar de um snapshot de sistema de arquivos frio, o MongoDB adiciona uma nova opção de linha de comando
--eseDatabaseKeyRollover. Quando iniciada com a opção--eseDatabaseKeyRollover, a instânciamongodrola as chaves de banco de dados configuradas comAES256-GCMcifra e sai.
Descarte o banco de dados do local se ele existir na cópia de segurança.
Se você estiver restaurando de uma cópia de segurança do sistema de arquivos (ou qualquer cópia de segurança com o banco de dados do local), solte o banco de dados do local.
Inicie um mongod autônomo usando os arquivos de dados da cópia de segurança como o caminho de dados.
Você também deve especificar as mesmas opções de inicialização que foram usadas quando o snapshot foi criado.
mongod --dbpath /data/db <startup options>
Descarte o banco de dados local.
Conecte mongosh à instância mongod e descarte o banco de dados local.
use local db.dropDatabase()
Desligue o standalone.
Inicie outro conjunto de réplicas de nó único.
Inicie uma instância do mongod como um novo conjunto de réplica de nó único. Especifique o caminho para os arquivos de dados da cópia de segurança com a opção --dbpath e o nome do conjunto de réplica com a opção --replSet . Para conjunto de réplica do servidor de configuração (CSRS), inclua a opção --configsvr. Inclua quaisquer outras opções conforme apropriado para sua implantação.
Você também deve especificar as mesmas opções de inicialização que foram usadas quando o snapshot foi criado.
Observação
Se os nós do seu conjunto de réplicas forem executados em hosts diferentes ou se você desejar que os clientes remotos se conectem à sua instância, você deverá especificar a configuração net.bindIp (ou --bind_ip).
Aviso
Antes de vincular a um não localhost (por exemplo, acessível IP ), certifique-se de ter protegido seu cluster contra o acesso não autorizado. Para obter uma lista completa de recomendações de segurança, consulte a Lista de verificação de segurança para implementações autogerenciadas. No mínimo, procure habilitar a autenticação e fortalecer a infraestrutura de rede.
mongod --dbpath /data/db --replSet <replName> <startup options>
Observação
Todas as coleções MongoDB têm UUIDs por padrão. Quando o MongoDB restaura as coleções, as coleções restauradas retêm seus UUIDs originais. Ao restaurar uma coleção onde nenhum UUID estava presente, o MongoDB gera um UUID para a coleção restaurada.
Para mais informações sobre UUIDs de coleção, consulte Coleções.
Conecte o mongosh à instância mongod.
Na mesma máquina em que um dos mongod está sendo executado (neste tutorial, mongodb0.example.net), inicie o mongosh. Para se conectar ao mongod escutando localhost na porta padrão do 27017, basta emitir:
mongosh
Dependendo do seu caminho, você pode precisar especificar o caminho para o binário mongosh.
Se o seu mongod não estiver executando na porta padrão, especifique a opção --port para mongosh.
Inicie o novo conjunto de réplicas.
Use rs.initiate() em um e apenas um membro do conjunto de réplicas:
rs.initiate( { _id : <replName>, members: [ { _id : 0, host : <host:port> } ] })
O MongoDB inicia um conjunto que consiste no membro atual e que utiliza a configuração padrão do conjunto de réplicas.
Adicionar membros ao conjunto de réplicas
O MongoDB oferece duas opções para restaurar membros secundários de um conjunto de réplicas:
Copie manualmente os arquivos do banco de dados para cada diretório de dados.
Permitir sincronização inicial para distribuir dados automaticamente.
Observação
Se o seu banco de dados for grande, a sincronização inicial pode levar muito tempo para ser concluída. Para bancos de dados grandes, pode ser preferível copiar os arquivos do banco de dados em cada host.
Copie os arquivos do banco de dados e reinicie a mongod instância
Use a seguinte sequência de operações para " semear " membros adicionais do conjunto de réplicas com os dados restaurados, copiando os arquivos de dados do MongoDB diretamente.
Encerre a instância mongod que você restaurou.
Utilize --shutdown ou db.shutdownServer() para garantir um desligamento limpo.
Copie o diretório de dados do primário para cada secundário.
Copie o diretório de dados do primário para o dos outros membros do conjunto de réplicas dbPath.
Inicie a instância do mongod que você restaurou.
Adicione os secundários ao conjunto de réplicas.
Em uma sessão do mongosh conectada ao primário, adicione os secundários ao conjunto de réplicas com o método rs.add(). Consulte Implantar um conjunto de réplicas autogerenciado para obter mais informações sobre como implantar um conjunto de réplicas.
Atualizar secundários usando a sincronização inicial
Use a seguinte sequência de operações para "compartilhar" membros adicionais do conjunto de réplicas definido com os dados restaurados usando a operação de sincronização inicial padrão.
Esvazie o diretório de dados para cada possível membro do conjunto de réplica.
Por exemplo, se o membro do conjunto de réplicas tiver uma storage.dbPath ou --dbpath de /data/db, você deverá garantir que o diretório exista e esteja vazio.
Adicione cada membro em potencial ao conjunto de réplicas.
Conecte-se ao primário usando o shell mongo e adicione cada secundário ao conjunto de réplicas usando rs.add().
Quando você adiciona um membro ao conjunto de réplicas, a Sincronização inicial copia os dados do primário para o novo membro.