Essa é uma estratégia de backup válida para o MongoDB?

11

Eu tenho um único servidor dedicado com um banco de dados MongoDB de cerca de 10 GB. Preciso fazer backups diários, mas não posso ter tempo de inatividade com o banco de dados. É possível usar uma réplica definida em um único disco (com 2 instâncias do mongod em portas diferentes) e simplesmente colocar a secundária offline e fazer backup dos arquivos de dados em um armazenamento externo como o S3 (o diário está ativado)? Ou o uso de mestre / escravo seria melhor que um conjunto de réplicas?

Isso é viável? Em caso afirmativo, que problemas em potencial eu poderia ter? Se não, como conceituo isso para funcionar?

backup database-backup mongodb

— James Simpson
fonte

6

ReplicaSet funcionará neste cenário. No entanto, não sei se é recomendável ter duas instâncias do MongoDB no mesmo servidor - isso depende do hardware / software e da carga do servidor.

Para garantir que seu backupnó MongoDB não se torne mestre, configure seu priorityparâmetro como 0, por exemplo,

rs.add({_id: 1, host: "localhost:<port>", priority: 0})

NOTA : se você não pode ter tempo de inatividade, DEVE ter pelo menos 2 nós principais do MongoDB no ReplicaSet, consulte o artigo

— Alexander Azarov
fonte

2

Uma estratégia a considerar é usar a opção "oculto" no nó de backup no seu conjunto de réplicas. No blog do MongoDB:

Servidores ocultos não aparecerão nos resultados isMaster (). Isso também significa que eles não serão usados se um driver distribuir automaticamente as leituras para os escravos. Um servidor oculto deve ter uma prioridade 0 (você não pode ter um primário oculto). Para adicionar um membro oculto, execute:

rs.add ({"_ id": num, "host": nome do host, "prioridade": 0, "oculto": true})

— Travis Dunn
fonte

1

Os conjuntos de réplicas são preferidos em geral, mas também neste caso, simplesmente por causa de suas funcionalidades de recuperação automática e ressincronização automática. O método de backup que você está descrevendo parece perfeitamente razoável e já foi usado anteriormente com outros bancos de dados.

O único problema em potencial que vejo é que, em determinadas circunstâncias, seu secundário pode ser promovido ao primário e você: a) precisa fazer o backup do novo secundário; ou b) torna seu script de backup inteligente o suficiente para dizer a instância de MongoDB para renunciar.

A boa notícia é que deve ser bastante trivial

Consulte sua fonte de backup para descobrir qual instância é primária e qual é secundária ( db.isMaster())
Convença a instância de backup a renunciar usando os comandos rs.freeze()e ou reconecte-se ao secundáriors.stepDown()

— Charles Hooper
fonte

Não é uma opção definir a prioridade como 0, como Alexander sugere, para que o secundário nunca se torne o primário?

— James Simpson

Você precisaria fazer alguns testes, mas não tenho certeza se o secundário permanecerá em espera se, por algum motivo, o processo principal for interrompido. Eu sempre quis que meus secundários assumissem o controle;)

— Charles Hooper

1

>> seu secundário pode ser promovido ao primário - Como mencionado, definir o secundário como prioridade 0 impedirá que ele mude para o mestre.

— Jonesome Reinstate Monica

Você pode conectar-se a qualquer um dos pares da sua lista de nós de mesmo nível (pode ser qualquer nó primário, secundário, árbitro ou oculto), perguntar ao ponto quem são os secundários ( rs.status()e fazer o loop result["members"]) e conectar-se a um dos secundários para executar o backup.

— yfeldblum