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

Clique Continuous Backup em e, em seguida, na Overview guia .

Clique no sistema e, em seguida, clique Restore or Download em .

Selecione o ponto de restauração.

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 Em FCV 4.0, não é possível 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.

Clique Download em para restaurar os arquivos manualmente.

Configure o download do snapshot.

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é que expire.
   Restore Link Expiration (in hours)	Selecione o número de horas até o link expirar. 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 Ops Manager solicitará seu código 2FA. Insira seu código 2FA e clique em Finalize Request.

Recupere os snapshots.

O 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, em seguida, em Restore History.

2. Quando o trabalho 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 e usá-lo mais tarde, ou

   • Download para baixar o snapshot imediatamente.

Desmarque o 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.

Para saber mais, consulte instalação.

Mova os arquivos de dados do snapshot para o host de destino.

Antes de mover o Data Federation 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>

Inicie a instância autônomo temporária na porta efêmera.

Inicie o processo mongod no modo standalone 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 você estiver restaurando a partir 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>

Depois que mongosh se conectar a mongod, continue.

Remova as collections relacionadas ao conjunto de réplicas do local banco de dados .

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

Execute os seguintes comandos para remover a configuração do conjunto de réplicas anterior e outras collection relacionadas à replicação que não sejam oplog.

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 ter a seguinte aparência:

> 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 collection system.replset no reconhecimento de data center local. Altere as seguintes variáveis:

• <replaceMeWithTheReplicaSetName> ao nome do seu conjunto de réplicas. Esse 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 ter a seguinte aparência:

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

Insira o carimbo de data/hora válido mínimo.

Emitir o seguinte comando:

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

Uma resposta bem-sucedida deve ter a seguinte aparência:

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

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 carimbo de data/hora 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 do carimbo de data/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 ter a seguinte aparência:

WriteResult({ "nInserted" : 1 })

Pare a instância autônomo 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()"

(Somente restauração pontual) Execute o utilitário de restauração de backup 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.

1. Baixe o utilitário MongoDB Backup Restore para 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 MongoDB Backup Restore não oferece suporte à autenticação, portanto, você não pode iniciar esse reconhecimento de data center temporário com autenticação.

3. Execute o utilitário MongoDB Backup Restore no seu host de destino. Execute-o uma vez para o conjunto de réplicas.

   Importante

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

   O 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 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 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 --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 Ops Manager.
   --apiKey	Obrigatório	Forneça sua chave de API do agente do Ops Manager.
   --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 reconhecimento de data center e/ou collection para as quais você deseja limitar a restauração.
   --blacklist	Opcional	Forneça uma lista de reconhecimento de data center e/ou collection que 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 diferenciado (nome diferenciado) 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 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 Ops Manager. Necessário se --sslServerClientCertificate estiver definido e esse certificado estiver criptografado.
   --sslRequireValidMMSBackupServerCertificate	Opcional	Defina um sinalizador indicando se certificados válidos são necessários ao entrar em contato com o host do 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 Ops Manager. Se esse sinalizador não for fornecido, a Autoridade de certificação do sistema será usada. Se o 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 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()"

(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ônoma 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()"

Repita este procedimento para cada nó no conjunto de réplicas.

Reiniciar todos os nós em um conjunto de réplicas.

Neste ponto, a Data Federation no conjunto de réplicas está 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 Ops Manager.

Na página Deployment , clique em Add, selecione Existing MongoDB Deployment e continue adicionando Automation de volta ao seu cluster.