Disaster Prep do MongoDB na AWS

Question

Estou procurando conselhos sobre práticas recomendadas que abordem a recuperação de desastres do MongoDB em um ambiente hospedado da AWS.

Nossa configuração é bastante padrão neste ponto, conjunto de réplicas de 3 servidores (1 primário, 1 secundário e 1 árbitro), os volumes mongo no primário e secundário são suportados pelo EBS. Tudo em uma única região, espalhada por várias disponibilidades zonas. Eventualmente, precisaremos abranger as regiões, mas isso é uma discussão para outro dia.

Os conselhos de backup que vi na documentação do Mongo falam sobre os instantâneos do EBS (que são fáceis de automatizar). No entanto, caso o desastre aconteça, eles não nos levarão de volta ao tempo do fracasso.

• Preciso gravar oplogs e usá-los em conjunto para restaurar depois de uma falha?
• Eu deveria criar outra instância dentro do conjunto de réplicas especificamente para backups e snapshots vs. vs. tirar fotos de primário e secundário? Se assim for, estamos de volta ao problema do oplog, não estamos?
• Devo capturar instantaneamente cada volume de réplica e confiar no conjunto de réplicas completamente para cobrir o tempo entre a falha e o último instantâneo?

Estou procurando a estratégia mais robusta disponível. Até a segunda proteção de dados e a velocidade de restauração do sistema após uma falha são mais altas do que o preço. Podemos otimizar o preço mais tarde.

Agradecemos antecipadamente por todas as sugestões ...

    

Answer 1

Primeiro, se você tirar uma foto, ela incluirá o oplog - o oplog é apenas uma coleção limitada que está no banco de dados local. Os instantâneos retornarão a um ponto no tempo e, supondo que você tenha o registro em diário ativado (ele está ativado por padrão), não será necessário fazer nada de especial para que o instantâneo funcione como um backup.

O único requisito absoluto é que o instantâneo do EBS tenha que ser recente o suficiente para estar dentro do seu > oplog - que é a última operação (mais recente) registrada no oplog de backup de captura instantânea também deve estar no oplog do primário atual para que eles possam encontrar um ponto comum. Se for esse o caso, funcionará algo assim:

1. Você restaura um secundário de um backup de snapshot do EBS
2. O mongod inicia, procura (e aplica) todos os arquivos de diário relevantes
3. Em seguida, o secundário se conecta ao primário e encontra um ponto comum nos dois oplogs
4. Quaisquer operações subsequentes do primário são aplicadas na RECUPERAÇÃO secundária
5. Quando o secundário se aproxima o suficiente, ele se move para o estado SECONDARY e o backup é concluído

Se o instantâneo não é recente o suficiente, então ele pode ser descartado - sem um ponto comum no oplog, o secundário terá que resync do zero de qualquer maneira.

Para responder às suas perguntas específicas:

Do I need to record oplogs and use those in conjunction to restore after a failure?

Como explicado acima, se você instantâneo, você já está fazendo o backup do oplog

Should I spin up another instance within the replica set specifically for backups and snapshot that vs. taking snapshots of primary and secondary? If so, we're back to the oplog issue aren't we?

Não há problemas de oplog além do ponto / janela comum que eu mencionei acima. Algumas pessoas optam por ter um secundário (geralmente oculto ) este propósito para evitar adicionar carga a um nó normal. Nota: até mesmo um membro oculto recebe um voto, por isso, se você adicionou um para fins de backup, você pode remover o árbitro da sua configuração, você ainda teria 3 membros votantes.

Should I snapshot each replica volume and rely on on the replica set completely to cover the time between failure and the last snapshot?

Todos os membros de um conjunto de réplicas devem ser idênticos - os dados são os mesmos, qualquer secundário pode se tornar primário etc. - eles não são escravos, cada membro do conjunto de réplicas contém o oplog completo e todos os dados.

Assim, tirar vários instantâneos (supondo que você confie no processo) será redundante (é claro que você pode querer essa redundância). E sim, toda a intenção da funcionalidade do conjunto de réplicas é garantir que você não precise tomar medidas extraordinárias para usar um secundário dessa maneira (com as advertências acima em mente, é claro).