Preciso testar a restauração com o Ops Manager. Para isso, "clonei" o cluster fragmentado de produção. Crio VMs com o mesmo tamanho de produção e faço mongodump/mongorestore(Ops Manager Deployment). Meu teste (para restauração) não precisa ser uma cópia consistente, para mim não há problema se faltar cerca de 5 GB.
DATA SIZE: 573.6 GB
shard0
142.6 GB
shard1
145.94 GB
shard2
142.55 GB
shard3
142.52 GB
Por motivos de simplicidade, desejo pegar um mongodump e canalizá-lo para o mongorestore no arquivo mongos.
Encontrei um documento antigo (v3.0) Faça backup de um pequeno cluster fragmentado com mongodump . Esta documentação não existe mais nas novas versões do MongoDB.
Se o seu cluster fragmentado contém um pequeno conjunto de dados, você pode se conectar a um mongos usando o mongodump.
o que é um pequeno conjunto de dados em GB? Veja acima para minha implantação.
Se você usar o mongodump sem especificar um banco de dados ou uma coleção, o mongodump capturará os dados da coleção e os metadados do cluster dos servidores de configuração.
Eu não preciso fazer backup explicitamente config RS?
Ao restaurar dados para o cluster fragmentado, você deve implantar e configurar a fragmentação antes de restaurar os dados do backup. Consulte Implantar um cluster fragmentado para obter mais informações.
Significa em inglês claro que preciso definir o shard key (and enable sharding)antes da restauração?
Perco alguma etapa/coisa importante?
Não é um pequeno cluster fragmentado.
O Mongodump levará cerca de 5 horas para 600 GB e a restauração levaria mais de 5 horas com base nos índices em vigor em sua coleção.
Minha melhor sugestão é:
Se você já tiver um backup feito pelo Mongo Ops-Manager, use-o e restaure no novo ambiente.
Se o tempo não for realmente um problema no seu caso, use o método de despejo e restauração.
O método Mongodump e restauração pode lidar com bancos de dados enormes, se você deseja restaurar algumas coleções, use a opção de exportação e importação.
Nota: Uma pequena dica que posso dar aqui para tornar o processo mais rápido é:
O Mongodump fará um backup do db e coletará em 2 arquivos para cada um, um é bson e outro é json. Bson terá os índices e json terá os dados.
Portanto, o processo Mongorestore restaurará o arquivo json primeiro e, em seguida, iniciará a restauração do arquivo bson e aplicará os índices.
Para tornar esse processo mais rápido, primeiro faça um mongodump e obtenha todos os índices de todos os dbs e coleções e aplique os índices primeiro manualmente e depois restaure os dados com o mongorestore, esse processo economizará pelo menos 30-40% do seu tempo.
Este procedimento serve apenas para fazer backup dos dados de um cluster fragmentado pequeno e não abrange a recriação do ambiente fragmentado ou a captura de um backup pontual. Como você notou, não há menção ao backup dos dados do servidor de configuração ou outras etapas essenciais que seriam necessárias para um ambiente fragmentado (por exemplo, interromper o balanceador). Esse procedimento talvez seja adequado para fazer backup de dados de um ambiente de desenvolvimento ou de preparação, mas não é recomendável para um ambiente de produção típico.
Para obter um procedimento de backup fragmentado mais completo usando
mongodump, consulte: Fazer backup de um cluster fragmentado com dumps de banco de dados . Certifique-se de que a versão da documentação que você está referenciando corresponde à sua série de lançamentos do MongoDB, pois pode haver diferenças notáveis.No entanto, você mencionou o uso do MongoDB Ops Manager, que inclui um recurso específico para fazer backup de clusters fragmentados. Se você escolher a opção de restauração manual , o Ops Manager fornecerá arquivos compactados para restaurar os servidores de configuração e os fragmentos. Como o licenciamento do Ops Manager faz parte de uma assinatura do MongoDB Enterprise, eu recomendaria abrir um caso de suporte comercial com o MongoDB se você precisar de recomendações ou esclarecimentos sobre qualquer um dos procedimentos ou seus requisitos.
Não existe um número absoluto. Os fatores gerais incluem desafios de recursos, como o tamanho de seus dados em relação à RAM, largura de banda de rede disponível e a rapidez com que seus dados mudam. Normalmente, se você tiver dados ou carga de trabalho suficientes para garantir a fragmentação, também terá superado
mongodumpa abordagem de backup.mongodumpvai ler todos os dados na memória, o que terá um impacto significativo nos conjuntos de trabalho para shards se seus dados forem muito maiores que a RAM disponível. Você também precisa ter espaço em disco suficiente para salvar um backup completo (ou backup compactado para MongoDB 3.2+) dos dados despejados por meio de um únicomongos, largura de banda de rede suficiente para lidar com o aumento do tráfego etc.Para seu caso de uso específico
mongodumpdefinitivamente não é uma estratégia recomendável por vários motivos fortes: