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

Question

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

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

    

Answer 1

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

Para garantir que seu nó backup MongoDB não se torne mestre, defina seu parâmetro priority para 0 , por exemplo

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

OBSERVAÇÃO : se você não puder ter tempo de inatividade, você DEVE ter pelo menos dois nós primários do MongoDB no ReplicaSet, veja

    

Answer 2

Uma estratégia a considerar é usar a opção "oculto" no nó de backup em seu replicaset. Do blog do MongoDB:

Hidden servers won’t appear in isMaster() results. This also means that they will not be used if a driver automatically distributes reads to slaves. A hidden server must have a priority of 0 (you can’t have a hidden primary). To add a hidden member, run:

rs.add({"_id" : num, "host" : hostname, "priority" : 0, "hidden" : true})

    

Answer 3

Os conjuntos de réplicas são geralmente preferidos, mas também neste caso, simplesmente devido à sua funcionalidade de recuperação automática e ressincronização automática. O método de backup que você está descrevendo soa perfeitamente razoável e foi usado antes com outros bancos de dados também.

O único problema potencial que vejo é que sob certas circunstâncias o seu secundário pode ser promovido para o seu primário e você a) precisa tirar o seu backup do novo secundário, ou b) tornar o seu script de backup suficientemente inteligente para dizer essa instância do MongoDB para renunciar.

A boa notícia é que deve ser bem trivial

1. Consulte sua origem de backup para descobrir qual instância é principal e qual é secundária ( db.isMaster() )
2. Convença a instância de backup a sair usando os comandos rs.freeze() e rs.stepDown() ou reconectando-se ao secundário