Houve alguma confusão considerável sobre a recuperação de espaço no MongoDB, e algumas práticas recomendadas são absolutamente perigosas em certos tipos de implantação. Mais detalhes abaixo:
O TL; DR repairDatabase tenta recuperar dados de uma implantação independente do MongoDB que está tentando se recuperar de uma corrupção de disco. Se recuperar espaço, é puramente um efeito colateral . Recuperar espaço nunca deve ser a principal consideração da execução repairDatabase.
Recuperar espaço em um nó independente
WiredTiger: para um nó independente com o WiredTiger, a execução compactliberará espaço para o sistema operacional, com uma ressalva: O compactcomando no WiredTiger no MongoDB 3.0.x foi afetado por este bug: SERVER-21833, que foi corrigido no MongoDB 3.2.3. Antes desta versão,compact WiredTiger podia falhar silenciosamente.
MMAPv1: devido à maneira como o MMAPv1 funciona, não há método seguro e suportado para recuperar espaço usando o mecanismo de armazenamento MMAPv1. compactno MMAPv1, desfragmentará os arquivos de dados, potencialmente disponibilizando mais espaço para novos documentos, mas não liberará espaço de volta para o sistema operacional.
Você poderá executar repairDatabasese entender completamente as conseqüências desse comando potencialmente perigoso (veja abaixo), pois repairDatabaseessencialmente reescreve todo o banco de dados descartando documentos corrompidos. Como efeito colateral, isso criará novos arquivos de dados MMAPv1 sem nenhuma fragmentação e liberará espaço de volta ao sistema operacional.
Para um método menos aventureiro, executar mongodumpe também mongorestorepode ser possível em uma implantação do MMAPv1, sujeita ao tamanho da sua implantação.
Recuperar espaço em um conjunto de réplicas
Para configurações de conjunto de réplicas, o melhor e o mais seguro método para recuperar espaço é executar uma sincronização inicial , tanto para o WiredTiger quanto para o MMAPv1.
Se você precisar recuperar espaço de todos os nós no conjunto, poderá executar uma sincronização inicial contínua. Ou seja, execute a sincronização inicial em cada um dos secundários, antes de finalmente deixar o primário e executar a sincronização inicial nele. A rolagem do método de sincronização inicial é o método mais seguro para executar a manutenção do conjunto de réplicas e também não envolve tempo de inatividade como bônus.
Observe que a viabilidade de fazer uma sincronização inicial contínua também depende do tamanho da sua implantação. Para implantações extremamente grandes, pode não ser viável fazer uma sincronização inicial e, portanto, suas opções são um pouco mais limitadas. Se o WiredTiger for usado, você poderá tirar um secundário do conjunto, iniciá-lo como um autônomo, executá compact-lo e juntá-lo novamente ao conjunto.
A respeito de repairDatabase
Por favor, não execute repairDatabaseem nós de conjunto de réplicas . Isso é muito perigoso, conforme mencionado na página repairDatabase e descrito em mais detalhes abaixo.
O nome repairDatabaseé um pouco enganador, pois o comando não tenta reparar nada. O comando foi projetado para ser usado quando houver corrupção de disco em um nó autônomo , o que pode levar a documentos corrompidos.
O repairDatabasecomando pode ser descrito com mais precisão como "banco de dados de recuperação". Ou seja, ele recria os bancos de dados descartando documentos corrompidos na tentativa de colocar o banco de dados em um estado em que você possa iniciá-lo e recuperar documentos intactos.
Nas implantações do MMAPv1, essa reconstrução dos arquivos do banco de dados libera espaço para o sistema operacional como efeito colateral . Liberar espaço para o sistema operacional nunca foi o objetivo.
Consequências de repairDatabaseum conjunto de réplicas
Em um conjunto de réplicas, o MongoDB espera que todos os nós no conjunto contenham dados idênticos. Se você executar repairDatabaseem um nó de conjunto de réplicas, é possível que o nó contenha corrupção não detectada e repairDatabaseremoverá os documentos corrompidos para você.
Previsivelmente, isso faz com que o nó contenha um conjunto de dados diferente do restante do conjunto. Se uma atualização atingir esse único documento, todo o conjunto poderá falhar.
Para piorar a situação, é perfeitamente possível que essa situação permaneça adormecida por um longo tempo, apenas para atacar repentinamente sem motivo aparente.
