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

Restaurar um conjunto de réplicas a partir de um snapshot

Nesta página

  • Considerações
  • Pré-requisitos
  • Restaurar um snapshot

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.

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.

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.

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

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 .

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.

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.

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, 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.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 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.

  1. Clique em Restore.

    O Ops Manager observa quanto espaço de armazenamento a restauração exige.

5

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.

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, 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.rs no seu conjunto de réplicas para encontrar o carimbo de data/hora desejado.

  2. Clique em Next.

4
5
  1. Configure as seguintes opções de download:

    Pull Restore Usage Limit
    Selecione quantas vezes o link pode ser usado. Se você selecionar No 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.
  2. Clique em Finalize Request.

  3. Se você usar 2FA, o MongoDB Ops Manager solicitará seu código 2FA. Insira seu código 2FA e clique em Finalize Request.

6

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:

  1. Se você fechou o painel de restauração, clique em Continuous Backup e depois em Restore History.

  2. Quando o tarefa de restauração for concluído, clique em (get link) para cada conjunto de réplicas que aparecer.

  3. 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.

1

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 .

2

Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh. Executar:

mongosh --port <port> \
--eval "db.getSiblingDB('admin').shutdownServer()"
3
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.

4

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>
1

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.

2

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>

Depois que mongosh se conectar a mongod, continue.

3

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 })
4

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 .

1db.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>" }
5

Emitir o seguinte comando:

db.getSiblingDB("local").replset.minvalid.insertOne({
"_id" : ObjectId(),
"t" : NumberLong(-1),
"ts" : Timestamp(0,1)
})

Uma resposta bem-sucedida deve ser assim:

{ "acknowledged" : true, "insertedId" : ObjectId("<yourObjectId>") }
6

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...
2Restore timestamp: (1609947369, 2)
3Last Oplog Applied: Wed Jan 06 15:36:09 GMT 2021 (1609947369, 1)
4MongoDB 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.

1

Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh. Executar:

mongosh --port <ephemeralPort> \
--eval "db.getSiblingDB('admin').shutdownServer()"
2

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>
3

Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh. Executar:

mongosh --port <ephemeralPort> \
--eval "db.getSiblingDB('admin').shutdownServer()"
1

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.

  1. 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.

  2. 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ário mongod .

    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.

  3. 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ção
    necessidade
    Descrição
    --host
    Obrigatório
    Forneça o nome do host, FQDN, endereço IPv4 ou endereço IPv6 do host que atende ao mongod ao qual o oplog deve ser aplicado. Se você copiou o comando mongodb-backup-restore-util fornecido no Aplicativo MongoDB Ops Manager , este campo será pré-configurado.
    --port
    Obrigatório
    Forneça a porta efêmera para o host que atende ao mongod ao qual o oplog deve ser aplicado.
    --opStart
    Obrigatório

    Forneça o carimbo de data/ hora BSON para a primeira entrada de oplog que você deseja incluir na restauração. Essas informações aparecem na entrada "Last oplog Applied" no arquivo restoreInfo.txt fornecido com o snapshot baixado.

    Este valor deve ser menor ou igual ao valor de --opEnd .

    --opEnd
    Obrigatório

    Forneça o carimbo de data/ hora BSON para a última entrada de oplog que você deseja incluir na restauração.

    Esse valor não pode ser maior que o final do oplog.

    --logFile
    Opcional
    Forneça um caminho, incluindo o nome do arquivo, onde o log MBRU é gravado.
    --oplogSourceAddr
    Obrigatório
    Forneça a URL do endpoint do recurso MongoDB Ops Manager .
    --apiKey
    Obrigatório
    Forneça sua MongoDB Ops Manager API chave dedo agente .
    --groupId
    Obrigatório
    Forneça o ID do grupo .
    --rsId
    Obrigatório
    Forneça a ID do conjunto de réplicas .
    --whitelist
    Opcional
    Forneça uma lista de bancos de dados e/ou collections aos quais você deseja limitar a restauração.
    --blacklist
    Opcional
    Forneça uma lista de bancos de dados e/ou collections para os quais você deseja excluir da restauração.
    --seedReplSetMember
    Opcional

    Use 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
    Condicional

    Forneça o tamanho do oplog em MB.

    Obrigatório se --seedReplSetMember estiver definido.

    --seedTargetPort
    Condicional

    Forneç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

    Use se precisar de TLS/SSL para aplicar o oplog ao mongod.

    Exige --sslCAFile e --sslPEMKeyFile.

    --sslCAFile
    Condicional

    Forneça o caminho para o arquivo da Autoridade de Certificação.

    Obrigatório se --ssl estiver definido.

    --sslPEMKeyFile
    Condicional

    Forneça o caminho para o arquivo de certificado PEM .

    Obrigatório se --ssl estiver definido.

    --sslPEMKeyFilePwd
    Condicional

    Forneç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
    Opcional

    Forneça o Assunto do Certificado do Cliente ou Nome Distinto (DN) para o processo MongoDB de destino.

    Obrigatório se --ssl estiver definido.

    --sslRequireValidServerCertificates
    Opcional
    Defina um sinalizador indicando se a ferramenta deve validar os certificados que o processo MongoDB de destino apresenta.
    --sslServerClientCertificate
    Opcional
    Forneça o caminho absoluto para o arquivo de certificado do cliente a ser usado para se conectar ao host do MongoDB Ops Manager .
    --sslServerClientCertificatePassword
    Condicional

    Forneç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
    Opcional
    Defina 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
    Opcional

    Forneç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
    Opcional
    Forneç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.

  4. Pare o mongod na instância. Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh. Executar:

    mongosh --port <ephemeralPort> \
    --eval "db.getSiblingDB('admin').shutdownServer()"
2

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.

3

Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh. Executar:

mongosh --port <port> \
--eval "db.getSiblingDB('admin').shutdownServer()"
4
1

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
2

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.

Voltar

Cluster fragmentado