Restaurar um conjunto de réplicas a partir de um snapshot
Nesta página
Quando você restaura um conjunto de réplicas a partir do backup, o MongoDB Ops Manager fornece um arquivo 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 do 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 aplicativo espera BinData
subtipo 2, você deverá atualizar o código do aplicativo 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.
Pré-requisitos
Para executar restaurações manuais, você deve ter a função de Administrador de Backup no MongoDB Ops Manager.
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
.
Solicitações do cliente 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
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.
Restauração automática
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çã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:59
ou 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.rs
no 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 gerente de operações deve gerenciar o conjunto de réplicas 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.
Restauração manual
Aviso
Considere a restauração automática
Esse procedimento envolve um grande número de etapas. Algumas dessas etapas têm severas implicações de segurança. Se você não precisar restaurar para uma implantação que o MongoDB Ops Manager não gerencia, considere uma restauração automatizada.
Recuperar os snapshots
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:59
ou 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.rs
no seu conjunto de réplicas para encontrar o carimbo de data/hora desejado.Clique em Next.
Configure o download do snapshot.
Configure as seguintes opções de download:
Pull Restore Usage LimitSelecione quantas vezes o link pode ser usado. Se você selecionarNo Limit
, o link poderá ser reutilizado até expirar.Restore Link Expiration (in hours)Selecione o número de horas até que o link expire. O valor padrão é1
. O valor máximo é o número de horas até que o snapshot selecionado expire.Clique em Finalize Request.
Se você usar 2FA, o MongoDB Ops Manager solicitará seu código 2FA. Insira seu código 2FA e clique em Finalize Request.
Retrieve the Snapshots.
O MongoDB Ops Manager cria links para o snapshot. Por padrão, esses links estão disponíveis por uma hora e você pode usá-los apenas uma vez.
Para baixar os snapshots:
Se você fechou o painel de restauração, clique em Continuous Backup e depois em Restore History.
Quando o tarefa de restauração for concluído, clique em (get link) para cada conjunto de réplicas que aparecer.
Clique em:
O botão copiar à direita do link para copiar o link para usá-lo mais tarde, ou
Download para fazer o download do snapshot imediatamente.
Preparar o conjunto de réplicas
Cancele o gerenciamento do conjunto de réplicas de destino.
Antes de tentar restaurar os dados manualmente, remova o conjunto de réplicas da automação.
Escolha a opção Unmanage this item in Ops Managers but continue to monitor .
Pare o conjunto de réplicas de destino.
Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh
. Executar:
mongosh --port <port> \ --eval "db.getSiblingDB('admin').shutdownServer()"
Verifique os requisitos de hardware e software no conjunto de réplicas de destino.
Capacidade de armazenamento | O hardware do host de destino precisa ter espaço de armazenamento livre suficiente para armazenar os dados restaurados. Se você quiser manter todos os dados do cluster existentes nesse host, verifique se o host tem espaço livre suficiente para os dados do cluster e os dados restaurados. |
Versão do MongoDB | O host de destino no qual você está restaurando e o host de origem do qual você está restaurando devem executar a mesma versão do MongoDB Server . Para verificar a versão MongoDB , execute o mongod
--version a partir de um terminal ou shell. |
Para saber mais, consulte instalação.
Mova os arquivos de dados de snapshot para o host de destino.
Antes de mover os arquivos de dados do snapshot para o host de destino, verifique se o host de destino contém algum arquivo existente e exclua todos os arquivos, exceto o arquivo automation-mongod.conf
.
Descompacte os arquivos de snapshot e mova-os para o host de destino da seguinte maneira:
tar -xvf <backupSnapshot>.tar.gz mv <backupSnapshot> </path/to/datafiles>
Inicializar e configurar instâncias
Inicie a Instância Standalone Temporária na Porta Efêmera.
Inicie o processo mongod
no modo autônomo como uma medida temporária. Isso permite adicionar novos parâmetros de configuração à collection system.replset
nas etapas subsequentes.
Use o <ephemeralPort>
para o processo mongod
autônomo temporário em todas as etapas deste procedimento em que ele for mencionado. Essa porta deve ser diferente das portas do host de origem e destino.
Execute o processo do mongod
da seguinte maneira. Dependendo do seu caminho, talvez seja necessário especificar o caminho para o binário mongod
.
mongod --dbpath </path/to/datafiles> \ --port <ephemeralPort> \
Se estiver restaurando de um snapshot filtrado por namespace, use a opção --restore
.
mongod --dbpath </path/to/datafiles> \ --port <ephemeralPort> \ --restore
Depois que o processo mongod
começar a aceitar conexões, continue.
Conecte-se à Instância Autônomo Temporária com mongosh
.
A partir do host que executa este processo mongod
, inicie mongosh
. Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh
.
Para se conectar ao mongod
escutando localhost no mesmo <ephemeralPort>
especificado na etapa anterior, execute:
mongosh --port <ephemeralPort>
Remova as collections relacionadas ao conjunto de réplicas do local
banco de dados.
Para executar restaurações manuais, você deve ter a função de Administrador de Backup no MongoDB Ops Manager.
Execute os seguintes comandos para remover a configuração anterior do conjunto de réplicas e outras collections não oplog relacionadas à replicação.
db.getSiblingDB("local").replset.minvalid.drop() db.getSiblingDB("local").replset.oplogTruncateAfterPoint.drop() db.getSiblingDB("local").replset.election.drop() db.getSiblingDB("local").system.replset.remove({})
Uma resposta bem-sucedida deve ser assim:
> db.getSiblingDB("local").replset.minvalid.drop() true > db.getSiblingDB("local").replset.oplogTruncateAfterPoint.drop() true > db.getSiblingDB("local").replset.election.drop() true > db.getSiblingDB("local").system.replset.remove({}) WriteResult({ "nRemoved" : 1 })
Adicione uma nova configuração de conjunto de réplicas.
Insira o seguinte documento na coleção system.replset
no banco de dados de dados local
. Altere as seguintes variáveis:
<replaceMeWithTheReplicaSetName>
ao nome do seu conjunto de réplicas. Este nome não precisa ser igual ao nome antigo.<host>
para o host que atende a esse membro do conjunto de réplicas.<finalPortNewReplicaSet>
para a porta final do novo conjunto de réplicas. Para uma restauração automatizada, você deve especificar uma porta diferente do<ephemeralPort>
especificado anteriormente.
Certifique-se de incluir e configurar todos os membros do novo conjunto de réplicas na array members
.
1 db.getSiblingDB("local").system.replset.insertOne({ 2 "_id" : "<replaceMeWithTheReplicaSetName>", 3 "version" : NumberInt(1), 4 "protocolVersion" : NumberInt(1), 5 "members" : [ 6 { 7 "_id" : NumberInt(0), 8 "host" : "<host>:<finalPortNewReplicaSet>" 9 }, 10 { 11 . . . 12 }, 13 . . . 14 ], 15 "settings" : { 16 17 } 18 })
Uma resposta bem-sucedida deve ser assim:
{ "acknowledged" : true, "insertedId" : "<yourReplicaSetName>" }
Defina o ponto de restauração para os valores em Restore Timestamp
de restoreInfo.txt
.
Defina o documento oplogTruncateAfterPoint
para os valores fornecidos no campo Restore Timestamp
do arquivo restoreInfo.txt .
O campo Restore Timestamp
nesse arquivo contém dois valores. No exemplo a seguir , o primeiro valor é o timestamp e o segundo valor é o incremento.
1 ... 2 Restore timestamp: (1609947369, 2) 3 Last Oplog Applied: Wed Jan 06 15:36:09 GMT 2021 (1609947369, 1) 4 MongoDB Version: 4.2.11 5 ...
O código de exemplo a seguir usa o valor de registro de data e hora e o valor de incremento do exemplo anterior.
truncateAfterPoint = Timestamp(1609947369,2) db.getSiblingDB("local").replset.oplogTruncateAfterPoint.insertOne({ "_id": "oplogTruncateAfterPoint", "oplogTruncateAfterPoint": truncateAfterPoint })
Uma resposta bem-sucedida deve ser assim:
WriteResult({ "nInserted" : 1 })
Observação
Restaurando o MongoDB 4.2 Snapshots usando MongoDB 4.4
Se você tentar restaurar um snapshot do MongoDB 4.2 com um mongod
executando o MongoDB 4.4, seu oplog poderá conter documentos desnecessários.
Para resolver esse problema, você pode:
Diminua o carimbo de data/hora em 1.
Restaure usando MongoDB 4.2.
Faça com que o MongoDB Ops Manager execute uma restauração automatizada.
Esse problema não se aplica ao MongoDB 4.4 ou a snapshots posteriores.
Gerenciar instâncias
Pare a instância independente temporária.
Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh
. Executar:
mongosh --port <ephemeralPort> \ --eval "db.getSiblingDB('admin').shutdownServer()"
Reinicie a Instância como um Nó de Conjunto de Réplicas Efêmero.
Inicie o mongod
utilizando o seguinte comando. Esta ação reconcilia o estado mongod
com o oplog até o Restore
timestamp
. Dependendo do seu caminho, talvez seja necessário especificar o caminho para o binário mongod
.
mongod --dbpath </path/to/datafiles> \ --port <ephemeralPort> \ --replSet <replaceMeWithTheReplicaSetName>
Pare a instância temporária na porta efêmera.
Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh
. Executar:
mongosh --port <ephemeralPort> \ --eval "db.getSiblingDB('admin').shutdownServer()"
Restaurar snapshots point-in-time
(Somente restauração point-in-time) Execute o utilitário de restauração de backup do MongoDB .
Esta etapa é condicional. Execute-o se precisar de restauração point-in-time.
Nesta etapa, você baixa e executa o Utilitário de Restauração de Backup MongoDB na instância de destino do conjunto de réplicas e, em seguida, interrompe a instância.
Baixe o utilitário de restauração de backup do MongoDB para o seu host.
Se você fechou o painel de restauração, clique em Continuous Backup in Deployment, More e depois em Download MongoDB Backup Restore Utility.
Inicie uma instância do
mongod
sem autenticação habilitada utilizando o diretório de captura instantânea extraído como o diretório de dados. Dependendo do seu caminho, talvez seja necessário especificar o caminho para o bináriomongod
.mongod --port <ephemeralPort> \ --dbpath </path/to/datafiles> \ --setParameter ttlMonitorEnabled=false \ --bind_ip <hostname_or_IP> Aviso
O Utilitário de Restauração de Backup MongoDB não oferece suporte a autenticação, portanto, você não pode iniciar esse banco de banco de dados temporário com autenticação.
Execute o utilitário MongoDB Backup Restore no host de destino. Execute-o uma vez para o conjunto de réplicas.
Importante
Comando mongodb-backup-restore-util pré-configurado
O MongoDB Ops Manager fornece ao
mongodb-backup-restore-util
as opções apropriadas para sua restauração no painel de restauração em Run Binary with PIT Options.Você deve copiar o comando
mongodb-backup-restore-util
fornecido no aplicativo MongoDB Ops Manager ../mongodb-backup-restore-util --https --host <targetHost> \ --port <ephemeralPort> \ --opStart <opLogStartTimeStamp> \ --opEnd <opLogEndTimeStamp> \ --logFile <logPath> \ --oplogSourceAddr <oplogSourceAddr> \ --apiKey <apiKey> \ --groupId <groupId> \ --rsId <rsId> \ --whitelist <database1.collection1, database2, etc.> \ --blacklist <database1.collection1, database2, etc.> \ --seedReplSetMember \ --oplogSizeMB <size> \ --seedTargetPort <port> \ --ssl \ --sslCAFile </path/to/ca.pem> \ --sslPEMKeyFile </path/to/pemkey.pem> --sslClientCertificateSubject <distinguishedName> \ --sslRequireValidServerCertificates <true|false> \ --sslServerClientCertificate </path/to/client.pem> \ --sslServerClientCertificatePassword <password> \ --sslRequireValidMMSBackupServerCertificate <true|false> \ --sslTrustedMMSBackupServerCertificate </path/to/mms-certs.pem> \ --httpProxy <proxyURL> O comando
mongodb-backup-restore-util
utiliza as seguintes opções:OpçãonecessidadeDescrição--host
Obrigatório--port
Obrigatório--opStart
Obrigatório--opEnd
Obrigatório--logFile
OpcionalForneça um caminho, incluindo o nome do arquivo, onde o log MBRU é gravado.--oplogSourceAddr
ObrigatórioForneça a URL do endpoint do recurso MongoDB Ops Manager .--apiKey
ObrigatórioForneça sua MongoDB Ops Manager API chave dedo agente .--groupId
ObrigatórioForneça o ID do grupo .--rsId
ObrigatórioForneça a ID do conjunto de réplicas .--whitelist
OpcionalForneça uma lista de bancos de dados e/ou collections aos quais você deseja limitar a restauração.--blacklist
OpcionalForneça uma lista de bancos de dados e/ou collections para os quais você deseja excluir da restauração.--seedReplSetMember
OpcionalUse se você precisar de um membro do conjunto de réplicas para recriar a coleção de oplog e semeá-la com o registro de data e hora correto.
Exige
--oplogSizeMB
e--seedTargetPort
.--oplogSizeMB
CondicionalForneça o tamanho do oplog em MB.
Obrigatório se
--seedReplSetMember
estiver definido.--seedTargetPort
CondicionalForneça a porta para o primário do conjunto de réplicas . Isso pode ser diferente da porta efêmera usado.
Obrigatório se
--seedReplSetMember
estiver definido.--ssl
Opcional--sslCAFile
CondicionalForneça o caminho para o arquivo da Autoridade de Certificação.
Obrigatório se
--ssl
estiver definido.--sslPEMKeyFile
CondicionalForneça o caminho para o arquivo de certificado PEM .
Obrigatório se
--ssl
estiver definido.--sslPEMKeyFilePwd
CondicionalForneça a senha do arquivo de certificado PEM especificado em
--sslPEMKeyFile
.Obrigatório se
--ssl
estiver definido e esse arquivo de chave PEM estiver criptografado.--sslClientCertificateSubject
OpcionalForneça o Assunto do Certificado do Cliente ou Nome Distinto (DN) para o processo MongoDB de destino.
Obrigatório se
--ssl
estiver definido.--sslRequireValidServerCertificates
OpcionalDefina um sinalizador indicando se a ferramenta deve validar os certificados que o processo MongoDB de destino apresenta.--sslServerClientCertificate
OpcionalForneça o caminho absoluto para o arquivo de certificado do cliente a ser usado para se conectar ao host do MongoDB Ops Manager .--sslServerClientCertificatePassword
CondicionalForneça o caminho absoluto para a senha do arquivo de Certificado do Cliente a ser usado para se conectar ao host do MongoDB Ops Manager .
Necessário se
--sslServerClientCertificate
estiver definido e esse certificado for criptografado.--sslRequireValidMMSBackupServerCertificate
OpcionalDefina um sinalizador indicando se certificados válidos são necessários ao entrar em contato com o host do MongoDB Ops Manager . O valor padrão étrue
.--sslTrustedMMSBackupServerCertificate
OpcionalForneça o caminho absoluto para os certificados confiáveis da Autoridade de Certificação no formato PEM para o host do MongoDB Ops Manager . Se esse sinalizador não for fornecido, a Autoridade de certificação do sistema será usada.
Se o MongoDB Ops Manager estiver usando um certificado SSL autoassinado, essa configuração será necessária.
--httpProxy
OpcionalForneça a URL de um servidor proxy HTTP que a ferramenta pode usar.significa que, se você copiou o comando
mongodb-backup-restore-util
fornecido no aplicativo MongoDB Ops Manager , esse campo será pré-configurado.Pare o
mongod
na instância. Dependendo do seu caminho, talvez seja necessário especificar o caminho paramongosh
. Executar:mongosh --port <ephemeralPort> \ --eval "db.getSiblingDB('admin').shutdownServer()"
(Somente restauração point-in-time) Reinicie a instância para recuperar o oplog.
Inicie o mongod
usando o seguinte comando, especificando estes parâmetros:
<bind_ip>
para o host que atende a esse membro do conjunto de réplicas que você especificou na configuração do conjunto de réplicas.<port>
ao <ephemeralPort> que você especificou quando iniciou a instância autônomo temporária.
Essa ação reproduz o oplog até a entrada mais recente, incluindo aquelas inseridas quando você executou o Utilitário de Restauração de Backup MongoDB.
mongod --dbpath </path/to/datafiles> \ --port <ephemeralPort> \ --bind_ip <host-serving-this-replica-set-member> --setParameter recoverFromOplogAsStandalone=true --setParameter takeUnstableCheckpointOnShutdown=true --setParameter startupRecoveryForRestore=true
Depois de concluir esta etapa, o processo de restauração real será concluído.
(Somente restauração point-in-time) Pare a instância independente.
Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh
. Executar:
mongosh --port <port> \ --eval "db.getSiblingDB('admin').shutdownServer()"
Retomar automação
Reiniciar todos os nós em um conjunto de réplicas.
Neste ponto, os arquivos de dados no conjunto de réplicas estão em um estado consistente, mas a configuração do conjunto de réplicas precisa ser atualizada para que cada nó esteja ciente uns dos outros.
Execute o seguinte comando:
sudo -u mongod <path/to/target_mongod_binary> -f /path/to/datafiles/automation-mongod.conf
O exemplo a seguir reinicia todos os nós com a versão 4.4.12 enterprise com o caminho de dados /data6/node3
:
sudo -u mongod /var/lib/mongodb-mms-automation/mongodb-linux-x86_64-4.4.12-ent/bin/mongod -f /data6/node3/automation-mongod.conf
Reimportar o conjunto de réplicas.
Para gerenciar o conjunto de réplicas com automação novamente, importe o conjunto de réplicas de volta para o MongoDB Ops Manager.
Na página Deployment , clique em Add, selecione Existing MongoDB Deployment e continue adicionando Automation de volta ao seu cluster.