Menu Docs
Página inicial do Docs
/
MongoDB Cloud 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 de um backup, o Cloud 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 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

  • mongod opções de inicialização usadas no banco de dados quando o snapshot foi tirado

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

Para realizar restaurações manuais, você deve ter a função de Administrador de backup no Cloud Manager.

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 Cloud Manager restaure automaticamente o snapshot:

1
  1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

  2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

  3. Clique em Continuous Backup na barra lateral.

    A página Backup contínuo é exibida.

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

5
  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 Cloud Manager 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 Cloud Manager observa quanto espaço de armazenamento a restauração exige.

6

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 Cloud Manager não gerencie, considere uma restauração automatizada.

1
  1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

  2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

  3. Clique em Continuous Backup na barra lateral.

    A página Backup contínuo é exibida.

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

5
6
  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 Cloud Manager solicitará seu código 2FA. Insira seu código 2FA e clique em Finalize Request.

7
  1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

  2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

  3. Clique em Continuous Backup na barra lateral.

    A página Backup contínuo é exibida.

8

O Cloud 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. Clique 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.

9

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 .

10

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

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

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.

12

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

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.

14

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.

15

Para realizar restaurações manuais, você deve ter a função de Administrador de backup no Cloud 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 })
16

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.

  • <ephemeralPortNewReplicaSet> para a porta efêmera do novo conjunto de réplicas. Esta deve ser uma porta diferente da <ephemeralPort> que você especificou na etapa 11 deste procedimento.

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>:<ephemeralPortNewReplicaSet>"
9 }
10 ],
11 "settings" : {
12
13 }
14})

Uma resposta bem-sucedida deve ser assim:

{ "acknowledged" : true, "insertedId" : "<yourReplicaSetName>" }
17

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>") }
18

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 Cloud Manager execute uma restauração automatizada.

Esse problema não se aplica ao MongoDB 4.4 ou a snapshots posteriores.

19

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

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

Inicie o mongod usando o seguinte comando, especificando estes parâmetros:

  • <bind_ip> ao host que atende a esse membro do conjunto de réplicas que você especificou na etapa 14 deste procedimento.

  • <port> à <ephemeralPort> que você especificou na etapa 11 deste procedimento.

O mongod repete o oplog até o Restore timestamp.

mongod --dbpath </path/to/datafiles> \
--port <ephemeralPort> \
--bind_ip <host-serving-this-replica-set-member> \
--replSet <replaceMeWithTheReplicaSetName>
21

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

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

Esta etapa é opcional. Execute-o se precisar de restauração point-in-time. Se você precisar desta etapa, conclua-a e execute as etapas 21 e 22. Se você não precisar desta etapa, vá para a etapa 23. 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

    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 Cloud 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 Cloud Manager.

    ./mongodb-backup-restore-util --https --host <targetHost> \
    --port <targetPort> \
    --opStart <opLogStartTimeStamp> \
    --opEnd <opLogEndTimeStamp> \
    --logFile <logPath> \
    --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 Cloud Manager, este campo será pré-configurado.

    --port

    Obrigatório

    Forneça a porta do 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 para o endpoint do recurso Cloud Manager .

    --apiKey

    Obrigatório

    Forneça sua chave APIdo Cloud Manager Agent.

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

    Condicional

    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

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

    --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 Cloud 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 Cloud 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 Cloud 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 Cloud Manager . Se esse sinalizador não for fornecido, a Autoridade de certificação do sistema será usada.

    --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 Cloud 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()"
23

Esta etapa é necessária somente se você executou a etapa 20. Se você não precisou executar a etapa 20, vá para a etapa 23. Inicie o mongod utilizando o seguinte comando. O mongod repete 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>

Depois de concluir esta etapa, o processo de restauração real será concluído. Nas etapas a seguir, você restaura a configuração do conjunto de réplicas e a reimporta.

24

Esta etapa é necessária somente se você executou a etapa 20. Se você não precisou executar a etapa 20, vá para a etapa 23.

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

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

Inicie o processo mongod como uma instância autônomo usando o seguinte comando. Para <port>, use a porta real na qual esse nó no conjunto de réplicas deve ser executado. Dependendo do seu caminho, talvez seja necessário especificar o caminho para o binário mongod .

mongod --dbpath </path/to/datafiles> \
--port <port>

Depois que o processo mongod começar a aceitar conexões, continue.

26

Execute o seguinte comando:

mongosh --port <port> \
--eval db.getSiblingDB("local").system.replset.remove({})
27

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

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

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
30

Faça login em um dos nós e execute os seguintes comandos:

rs.initiate()
rs.add( { host: "<host2>:<port>" } )
rs.add( { host: "<host3>:<port>" } )
31
  1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

  2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

  3. Se a página Deployment ainda não estiver exibida, clique em Deployment na barra lateral.

    A página Sistema é exibida.

32

Para gerenciar o conjunto de réplicas com automação novamente, importe o conjunto de réplicas de volta para o Cloud Manager.

Clique em Add, selecione Existing MongoDB Deployment e continue adicionando Automation de volta ao seu cluster.

Para que o Cloud Manager restaure automaticamente o snapshot:

1
  1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

  2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

  3. Clique em Continuous Backup na barra lateral.

    A página Backup contínuo é exibida.

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

Para localizar a entrada de oplog mais recente, execute a seguinte query em mongosh:

db.getSiblingDB('local').oplog.rs.find().sort({$natural:-1}).limit(1).pretty()

Um resultado bem-sucedido deve ficar assim:

{
"ts": Timestamp(1537559320, 1),
"h": NumberLong("-2447431566377702740"),
"v": 2,
"op": "n",
"ns": "",
"wall": ISODate("2018-09-21T19:48:40.708Z"),
"o": {
"msg": "initiating set"
}
}

As partes do valor ts correspondem aos valores que você precisa para as caixas Timestamp e Increment .

Observação

Para traduzir a época em um carimbo de data/hora legível por humanos, tente usar uma ferramenta como o Epoch Converter

O MongoDB não endossa este serviço. Sua referência é apenas informativa.

5
  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 Cloud Manager 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 Cloud Manager observa quanto espaço de armazenamento a restauração exige.

6
1
  1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

  2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

  3. Clique em Continuous Backup na barra lateral.

    A página Backup contínuo é exibida.

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

Para localizar a entrada de oplog mais recente, execute a seguinte query em mongosh:

db.getSiblingDB('local').oplog.rs.find().sort({$natural:-1}).limit(1).pretty()

Um resultado bem-sucedido deve ficar assim:

{
"ts": Timestamp(1537559320, 1),
"h": NumberLong("-2447431566377702740"),
"v": 2,
"op": "n",
"ns": "",
"wall": ISODate("2018-09-21T19:48:40.708Z"),
"o": {
"msg": "initiating set"
}
}

As partes do valor ts correspondem aos valores que você precisa para as caixas Timestamp e Increment .

Observação

Para traduzir a época em um carimbo de data/hora legível por humanos, tente usar uma ferramenta como o Epoch Converter

O MongoDB não endossa este serviço. Sua referência é apenas informativa.

5
6
  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 Cloud Manager solicitará seu código 2FA. Insira seu código 2FA e clique em Finalize Request.

7
  1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

  2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

  3. Clique em Continuous Backup na barra lateral.

    A página Backup contínuo é exibida.

8

O Cloud Manager cria links para o snapshot. Por padrão, esses links estão disponíveis por uma hora e podem ser usados apenas uma vez.

Para baixar os snapshots:

  1. Clique em Restore History.

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

  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.

Importante

Etapa extra para restaurações point-in-time

Para restaurações point-in-time e de registro de data e hora do oplog, instruções adicionais são exibidas. A etapa final mostra o comando completo que você deve executar usando o MBRU. Ele inclui todas as opções necessárias para garantir uma restauração completa.

Selecione e copie o comando mongodb-backup-restore-util fornecido em Run Binary with PIT Options.

9

Exemplo

tar -xvf <backupSnapshot>.tar.gz
mv <backupSnapshot> <temp-database-path>
10
  1. Baixe o utilitário de restauração de backup do MongoDB para o seu host.

    Observação

    Se você fechou o painel de restauração:

    1. No MongoDB Cloud Manager, Go a página Continuous Backup do seu projeto.

      1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

      2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

      3. Clique em Continuous Backup na barra lateral.

      A página Backup contínuo é exibida.

    2. Clique em 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.

    Exemplo

    mongod --port <port number> \
    --dbpath <temp-database-path> \
    --setParameter ttlMonitorEnabled=false

    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 de restauração de backup do MongoDB no host de destino. Execute-o uma vez para o conjunto de réplicas.

    Importante

    Comando mongodb-backup-restore-util pré-configurado

    O Cloud 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 Cloud Manager.

    ./mongodb-backup-restore-util --https --host <targetHost> \
    --port <targetPort> \
    --opStart <opLogStartTimeStamp> \
    --opEnd <opLogEndTimeStamp> \
    --logFile <logPath> \
    --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 Cloud Manager, este campo será pré-configurado.

    --port

    Obrigatório

    Forneça a porta do 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 para o endpoint do recurso Cloud Manager .

    --apiKey

    Obrigatório

    Forneça sua chave APIdo Cloud Manager Agent.

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

    Condicional

    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

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

    --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 Cloud 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 Cloud 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 Cloud 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 Cloud Manager . Se esse sinalizador não for fornecido, a Autoridade de certificação do sistema será usada.

    --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 Cloud Manager, esse campo será pré-configurado.

11

Antes de tentar restaurar os dados manualmente, remova o conjunto de réplicas da automação.

12

Siga o tutorial do Manual MongoDB para restaurar o conjunto de réplicas.

13

Para gerenciar o conjunto de réplicas com automação novamente, importe o conjunto de réplicas de volta para o Cloud Manager.

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.

Voltar

Restaurar cluster fragmentado