Qual é a maneira recomendada de fazer backup de grandes conjuntos de dados no MongoDB? Digamos que tenhamos um tamanho de dados da ordem de 10 TB - como você apoiaria isso?
Estamos considerando um nó oculto, possivelmente atrasado, do conjunto de réplicas. O atraso nos protegeria de quedas acidentais de todo o banco de dados. Essa é uma solução viável e que outras opções você recomendaria investigar?
Obrigado!
Respostas:
Com a necessidade de backup de 10 TB, isso fica um pouco complicado.
Embora os membros atrasados do conjunto de réplicas possam fornecer uma maneira relativamente fácil de ajudá-lo com operações acidentais, não há substitutos para os backups adequados, assim como o RAID não substitui os backups baseados no sistema de arquivos.
Isso depende muito da aparência da sua configuração.
Com 10 TB, presumo que você tenha algum tipo de SAN conectado. A maneira mais fácil de fazer backup do MongoDB nesses ambientes é garantir que o registro no diário esteja ativado no sistema de arquivos e no MongoDB e simplesmente tirar uma foto do volume da SAN de um dos secundários, provavelmente um oculto, para garantir que suas operações não ocorram. seja interrompido. Isso geralmente leva apenas alguns segundos, mas certifique-se de que sua janela de replicação oplog seja suficiente. Caso contrário, pode ser necessário ressincronizar o secundário.
Eu tenho que discordar de RolandoMySQLDBA sobre o uso do mongodump. Antes de tudo, impõe bloqueios no servidor. Embora sejam levantados relativamente rápido, o número de bloqueios shere pode aumentar e interferir em suas operações, a menos que seja executado em um nó oculto ou quando não houver preferência de leitura atingindo os secundários. Além disso, não é exatamente rápido. Eu esperaria que ele durasse horas, pelo menos, provavelmente demorando mais que a janela de backup. Nota lateral: Sempre execute o mongodump com a --oplogopção. Lembre-se também de que o mongodump não faz backup de índices, mas as operações para criar índices. Esses índices precisam ser recriados durante uma restauração, o que pode aumentar enormemente o tempo necessário. Pela minha experiência, se você precisar restaurar um banco de dados, deseja tê-lo o mais rápido possível. Outro ponto por que o mongodump não é adequado para fazer backup de 10 TB.
Você pode fazer uma captura instantânea do LVM em uma instância do mongod em execução, desde que o registro no diário esteja ativado no mongod (e, pela minha experiência, não custa machucá-lo também no nível FS). No entanto, os instantâneos do LVM têm algumas implicações. Primeiro, você obviamente precisa ter espaço em disco suficiente para fazer as alterações durante as operações de backup. Deixe-me esclarecer isso.
Vamos supor que você tenha uma taxa de alteração horária de 500 GB. E que você deseja que seu backup seja bloqueado antes de ser carregado em algum armazenamento. Mesmo ao usar o bzip2 paralelo , a compactação de 10 TB precisaria de algumas horas para terminar, simplesmente porque o fato de que provavelmente você produz um throughput de armazenamento em massa se tornaria seu fator limitante. Vamos supor que levaria 2 horas para compactar os dados para 2 TB. Portanto, a essa altura, precisaríamos de 2 TB + 2 * 500 GB de espaço livre em disco total, 1 TB necessário para o instantâneo do LVM. Isso criaria a necessidade de provisionar em excesso seu sistema de arquivos por pelo menos30% Caso você deseje ter uma margem de segurança adequada, isso poderá facilmente aumentar para 60-70% (20% para um fator de utilização de 0,8 para o sistema de arquivos original, o mesmo para o tamanho da captura instantânea mais o espaço necessário para o próprio backup compactado em bzip ) Na maioria dos ambientes de produção, isso seria inaceitável, uma vez que o provisionamento em excesso seria estático (você não gostaria que um script de backup alternasse dinamicamente com seu LVM, não é?).
Embora o backup do MMS tenha alguns recursos impressionantes (backup contínuo, recuperação fácil no tempo), ele traz algumas sérias desvantagens: o preço do preço para implantações grandes pode facilmente chegar aos milhares. Com uma taxa de alteração horária assumida de 500 GB nesses 10 TB, seria uma soma média de seis dígitos para backups na nuvem . Por mês.
Minha sugestão é que ele faça uma assinatura corporativa para seus servidores para ter uma instância local do MMS, incluindo backup.
Aqui estão as opções que eu escolheria em ordem decrescente de preferência.
Existem duas opções
Se você não se importa com o tempo de inatividade, a coisa mais simples a fazer é
service mongod stopFaça um instantâneo LVM ou uma força bruta cpda pasta de dados Mongo para outro disco
service mongod startObviamente, você não quer tempo de inatividade se os 10 TB de dados estiverem em uma máquina autônoma.
Se você tiver um conjunto de réplicas com três nós, use um dos nós para backups
{
"_id" : "myreplica",
"version" : 1,
"members" : [
{
"_id" : 1,
"host" : "10.20.30.40:27017",
"priority" : 2
},
{
"_id" : 2,
"host" : "10.20.30.41:27017"
},
{
"_id" : 3,
"host" : "10.20.30.42:27017",
"priority" : 0,
"slaveDelay" : 3600
}
]
}Use o nó com "_id' : 3todos os seus backups físicos. Portanto, sem tempo de inatividade. Para obter um instantâneo da meia-noite, você pode iniciar o backup às 01:00, já que o nó oculto está 1 hora atrás.
Obviamente, a desvantagem é ter mais dois servidores com 10 TB cada e a sanidade do administrador de sistemas em risco.
Você poderia usar o mongodump na máquina autônoma, mas deve esperar uma degradação do desempenho, pois o mongodump é um programa cliente que usa uma conexão como qualquer outra conexão.
Se você deseja fazer backup point-in-time, use
mongodump --oplog O backup lógico do BSON será menor (especialmente compactado ou compactado) do que o backup físico.
O mongodump --oplogmelhor seria usar o nó oculto. Dessa forma, não há desempenho atingido no Master.
Eu sou relativamente novo no MongoDB (MongoDBA acidental / acidental). Espero que minha resposta ajude.