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

Perguntas frequentes: backup e restauração

Nesta página

Esta sessão de perguntas frequentes aborda perguntas frequentes sobre o Ops Manager e como ele faz backup e restaura reconhecimento de data center e collection.

A introdução do MongoDB Agent e o novo processo de backup para o MongoDB 4.2 com um FCV de 4.2 alteraram algumas dessas respostas. Essas respostas têm advertências explicando o impacto desses novos recursos nas respostas existentes.

Série de lançamentos do Ops Manager
1.6 a 1.8
2.0 a 3.2
3.4
3.6
4.0
4.2
Versão mínima do MongoDB 2.4
2.4.3
2.4.3
2.4.3
2.4.0 [1]
Versão mínima do MongoDB 2.6
2.6.0
2.6.0
2.6.0
2.6.0
2.6.0
2.6.0 [2]
Versão mínima do MongoDB 3.0
3.0.0
3.0.0
3.0.0
3.0.0
3.0.0
3.0.0 [2]
Versão mínima do MongoDB 3.2
3.2.0
3.2.0
3.2.0
3.2.0
3.2.0
Versão mínima do MongoDB 3.4
3.4.0
3.4.0
3.4.0
3.4.0
Versão mínima do MongoDB 3.6
3.6.0
3.6.0
3.6.0
Versão mínima do MongoDB 4.0
4.0.0
4.0.0
Versão mínima do MongoDB 4.2
4.2.0
[1] Somente monitoramento
[2](1, 2) Somente monitoramento e backup

Se você estiver fazendo backup de uma instância do MongoDB que tenha a autenticação habilitada, o MongoDB Agent exigirá o privilégio descritos para a função de backup do MongoDB Agent.

Dica

Veja também:

O Ops Manager usa as seguintes conversões para medir o tamanho do snapshot e para medir a quantidade de dados do oplog que foi processada:

  • 1 MB = 1024 2 bytes (1 MiB)

  • 1 GB = 1024 3 bytes (1 GiB)

  • 1 TB = 1024 4 bytes (1TiB)

  • Para MongoDB 4.2 e posterior, consulte Considerações de backup para bancos de dados.

  • Para qualquer MongoDB com FCV de 4.0 e bancos de dados anteriores, o Backup não oferece suporte a sistemas standalone. O backup tem suporte completo para conjuntos de réplicas e clusters fragmentados.

O Ops Manager copia dados do oplog para fornecer um backup contínuo com recuperação point-in-time. O Ops Manager não oferece suporte ao backup de hosts standalone porque eles não têm um oplog. Para oferecer suporte ao backup com uma única instância mongod , você pode executar um conjunto de réplicas de um membro.

Para saber mais sobre o recurso de backup, consulte Processo de backup.

Observação

Esta resposta se aplica somente a reconhecimento de data center que executam MongoDB com FCV de 4.0 e anteriores

O recurso de backup normalmente tem impacto mínimo nas implantações de produção do MongoDB. Este impacto tem desempenho semelhante ao da adição de um novo secundário a um conjunto de réplicas.

Por padrão, o agente de backup executa sua sincronização inicial, a operação que mais consome recursos para backups, em um membro secundário do conjunto de réplicas para limitar seu impacto. Opcionalmente, você pode configurar o Backup Agent para executar a initial sync com o primary do conjunto de réplicas, embora isso aumente o impacto da operação de initial sync.

A maioria das operações em um conjunto de réplicas é replicada por meio do oplog e, portanto, capturada pelo processo de backup. Algumas operações, no entanto, fazem alterações que não são replicadas: para essas operações, você deve fazer com que o Ops Manager seja ressincronizado a partir do seu conjunto de réplicas atual para incluir as alterações.

As seguintes operações não são replicadas e, portanto, exigem ressincronização:

  • Renomear ou excluir um banco de dados excluindo os arquivos de dados no diretório de dados. Como alternativa, remova bancos de dados usando uma operação que o MongoDB replicará, como db.dropDatabase() de mongosh.

  • Alterar quaisquer dados enquanto a instância está sendo executada como standalone.

  • Compilações de índice contínuo.

  • Usando compact ou repairDatabase para recuperar uma quantidade significativa de espaço.

    A ressincronização não é estritamente necessária após operações decompact ou repairDatabase, mas garantirá que a cópia dos dados do MongoDB Ops Manager seja redimensionada, o que significa restaurações mais rápidas.

A capacidade de backup foi movida para o MongoDB Agent com o Backup ativado. Isso substitui o agente de backup individual. Essas informações abrangem problemas exclusivos do agente de backup legado. Todas essas informações se aplicam a reconhecimento de data center MongoDB que executam FCV de 4.0 ou anterior.

Execute o agente de backup em um host que:

  • É separado de suas instâncias do MongoDB. Isso evita a contenção de recursos do sistema.

  • Pode se conectar às suas instâncias MongoDB. Verifique as configurações de rede para conexões entre o agente e os hosts MongoDB. Para obter uma lista das portas necessárias, consulte as portas abertas para os agentes.

  • Tem pelo menos 2 núcleos de CPU e 3 GB de RAM acima dos requisitos da plataforma. Com cada tarefa de backup executada, o agente de backup impacto ainda mais o desempenho do host.

Não há restrição técnica que impeça o agente de backup e o Monitoring de serem executados em um único sistema ou host. No entanto, ambos os agentes têm requisitos de recursos, e a execução de ambos em um único sistema pode afetar a capacidade desses agentes de oferecer suporte à sua implantação no Ops Manager.

Os recursos exigidos pelo Agente de Backup dependem da taxa e do tamanho das novas entradas de oplog (ou seja, total de gigabyte de oplog/hora produzidos.) Os recursos que o Monitoramento exige dependem do número de instâncias mongod monitoradas e do número total de bancos de dados fornecidos pelo as instâncias do mongod .

Você pode executar vários agentes de backup para alta disponibilidade. Se você fizer isso, os agentes de backup deverão ser executados em hosts diferentes.

Quando você executa vários agentes de backup, apenas um agente por projeto é o agente principal. O agente primary executa os backups. Os agentes restantes estão completamente ociosos, exceto para registrar seu status como standbys e perguntar periodicamente ao Ops Manager se eles devem se tornar o primary.

O agente de backup grava um pequeno token chamado checkpoint no oplog do reconhecimento de data center em um intervalo regular. Esses tokens fornecem uma pulsação para backups e não afetam o sistema de origem. Cada token tem menos de 100 bytes.

Importante

Você pode usar checkpoints em clusters que executam o MongoDB com feature compatibility version do 4.0 ou anterior. Os pontos de controle foram removidos das instâncias do MongoDB com FCV de 4.2 ou posterior.

Dica

Veja também:

O impacto da sincronização do backup inicial deve ser semelhante à sincronização de um novo membro do conjunto de réplicas secundário. O agente de backup não limita sua atividade e tenta realizar a sincronização o mais rápido possível.

Observação

A filtragem de namespace é compatível apenas com as versões 6.0.8 e posteriores do Ops Manager. Seus MongoDB deployments devem ter valores featureCompatibilityVersion de 4.0 e anteriores ou 6.0.1 e posteriores.

O Ops Manager fornece um filtro de namespace que permite especificar quais collection ou reconhecimento de data center fazer backup.

Para editar o filtro, consulte Editar as configurações de um backup. Alterar o filtro de namespaces pode exigir uma ressincronização. Em caso afirmativo, o Ops Manager lida com a ressincronização.

O motivo mais comum pelo qual as tarefa não se vinculam a um Backup Daemon é porque nenhum daemon tem espaço para uma cópia local do conjunto de réplicas de backup.

Para aumentar a capacidade para que a tarefa de backup possa ser vinculada, você pode:

  • adicionar mais um Backup Daemon.

  • aumentar o tamanho do sistema de arquivos que contém o head directory.

  • No FCV 4.0 e versões anteriores, mova os dados head database para um novo volume com mais espaço e crie um symlink ou configure os pontos de montagem do sistema de arquivos para que o daemon possa acessar os dados usando o caminho original.

    O FCV 4.2 e posterior não utilizam bancos de dados principais.

Se você notar erros consistentes nos comandos applyOps em seus registros de backup, isso pode indicar que o daemon ficou sem espaço.

Para aumentar o espaço em um daemon para suportar operações contínuas, você pode:

  • aumentar o tamanho do sistema de arquivos que contém o head directory.

  • Para o FCV 4.0 e versões anteriores, mova os dados head database para um novo volume com mais espaço e crie um symlink ou configure os pontos de montagem do sistema de arquivos para que o daemon possa acessar os dados usando o caminho original.

    O FCV 4.2 e posterior não utilizam bancos de dados principais.

O Ops Manager produz uma cópia do seu Data Federation que você pode usar para semear um novo sistema.

Importante

O Ops Manager 4.2.13 e posterior suporta este recurso com FCV de 4.2 ou posterior.

Quando você trigger a restauração, o Ops Manager cria um link para esse snapshot. Uma vez clicado, o Ops Manager recupera partes do armazenamento de snapshots e os transmite para o host de destino.

O utilitário MongoDB Backup Restore em execução nesse host baixa e aplica as entradas do oplog para atingir o ponto especificado no tempo.

A capacidade do Ops Manager de fornecer uma determinada restauração ponto-in-time depende da política de retenção dos snapshots e da janela ponto-in-time configurada.

Para saber mais sobre a política de retenção e a janela de ponto-in-time, consulte Editar agendamento de snapshots e política de retenção.

Não. O Ops Manager não suporta um agendamento de snapshot mais frequente do que a cada 6 horas. Para obter mais informações, consulte frequência de snapshots e política de retenção.

Sim. Você pode alterar o agendamento por meio da opção de menu Edit Snapshot Schedule para um sistema de backup. Os administradores podem alterar a frequência de snapshots e política de retenção por meio do recurso snapshotSchedule na API.

O Ops Manager transmite todos os backups em um formato compactado do host do Ops Manager para sua infraestrutura.

Além disso, as restaurações point-in-time dependem da quantidade que as entradas de oplog que seu host deve aplicar ao snapshot recebido para avançar para o point-in-time solicitado do backup.

O backup realiza verificações básicas de corrupção e fornece um alerta se algum componente (por exemplo, o agente) estiver inativo ou quebrado, mas não executa validação de dados explícita. Ao detectar a corrupção, o Ops Manager comete um erro por excesso de cautela, invalida o backup atual e envia um alerta.

Você pode solicitar uma restauração por meio do Ops Manager, onde pode escolher qual snapshot restaurar e como deseja que o Ops Manager forneça a restauração. Todas as restaurações exigem autenticação de dois fatores. Se você tiver configurado o SMS, o Ops Manager enviará um código de autorização por SMS. Você deve inserir o código de autorização na interface de backup para iniciar o processo de restauração.

Observação

Da Índia, use o Google Authenticator para autenticação de dois fatores. O Google Authenticator é mais confiável do que a autenticação com mensagens de texto SMS para números de celular da Índia (ou seja, código do país 91).

O Ops Manager fornece restaurações como arquivos tar.gz de Data Federation MongoDB.

Para saber mais sobre restaurações, consulte Restaurar implementações do MongoDB.

Importante

Para sistemas do MongoDB que executam o FCV 4.2 ou posterior, as reversões não afetam os dados de backup no Ops Manager. Do FCV 4.2 em diante, o Ops Manager retém apenas snapshots com registros de data e hora até e incluindo o ponto de confirmação da maioria.

Se o sistema do MongoDB sofrer um rollback, o MongoDB Ops Manager também reverterá os dados de backup.

O MongoDB Ops Manager detecta a reversão quando um cursor de cauda encontra uma incompatibilidade em carimbos de data/hora ou hashes de operações de gravação. MongoDB Ops Manager entra em um estado de rollback e testa três pontos no oplog do primary do seu conjunto de réplicas para localizar um ponto comum no histórico. MongoDB Ops Manager A reversão do difere da MongoDB reversão secundária do porque o ponto comum não precisa necessariamente ser o ponto comum mais recente .

Quando o Ops Manager encontra um ponto comum, o serviço invalida as entradas de oplog e snapshots além desse ponto e reverte para o snapshot mais recente antes do ponto comum. O Ops Manager retoma as operações normais de backup.

Se o Ops Manager não conseguir encontrar um ponto comum, será necessária uma ressincronização .

Importante

Esse recurso é incompatível com o MongoDB 4.2 com FCV de 4.2.

Se o cursor tailing do agente de backup não conseguir acompanhar o oplog do seu sistema, você deverá sincronizar novamente os backups.

Esse cenário pode ocorrer se:

  • Seu aplicativo gera periodicamente muitos dados, reduzindo a oplog window do primary a ponto de os dados serem gravados no oplog mais rápido do que o Ops Manager pode consumi-los.

  • Se o agente de backup estiver sendo executado em uma máquina com provisionamento insuficiente ou usado em excesso e não conseguir acompanhar a atividade de oplog.

  • Se o Backup Agent estiver inativo por um período de tempo maior do que o tamanho do oplog permite. Se você desligar seus agentes, como para manutenção, reinicie-os em tempo hábil. Para obter mais informações sobre o tamanho do oplog, consulte Conjunto de réplicas do Oplog no manual do MongoDB.

  • Se você excluir todos os dados do conjunto de réplicas e implantar um novo conjunto de réplicas com o mesmo nome, o que poderá acontecer em um ambiente de teste em que as implantações são regularmente desativadas e reconstruídas.

  • Se houver uma reversão, o Ops Manager não conseguir encontrar um ponto comum no oplog.

  • Se um evento oplog tentar atualizar um documento que não existe no backup do conjunto de réplicas, como poderá acontecer se sincronizar a partir de um secundário que tenha dados inconsistentes com o primário.

  • Se você criar um índice de forma contínua.

Voltar

Perguntas frequentes: automação