Auto compact l'espace supprimé en mongodb?

j'ai une autre solution qui pourrait fonctionner mieux que faire db.repairDatabase () si vous n'avez pas les moyens de verrouiller le système, ou si vous n'avez pas le double du stockage.

vous devez utiliser une réplique.

ma pensée est une fois que vous avez enlevé toutes les données en excès qui engloutissent votre disque, arrêter une réplique secondaire, effacer son répertoire de données, le démarrer et le laisser resynchroniser avec le maître.

le processus est le temps la consommation, mais il ne devrait coûter que quelques secondes de temps d'arrêt, lorsque vous faites de la rs.stepDown ().

Aussi, cela ne peut pas être automatisé. Eh bien, ça pourrait, mais je ne pense pas que je suis prêt à essayer.

db en cours d'Exécution.repairDatabase () exigera que vous ayez l'espace égal à la taille actuelle de la base de données disponible sur le système de fichiers. Cela peut être gênant quand vous savez que les collections ou les données que vous devez conserver dans la base de données utiliseraient actuellement beaucoup moins d'espace que ce qui est alloué et vous n'avez pas assez d'espace pour faire la réparation.

comme alternative si vous avez peu de collections que vous avez réellement besoin de conserver ou seulement un sous-ensemble de la données, puis vous pouvez déplacer les données dont vous avez besoin pour garder dans une nouvelle base de données et laisser tomber l'ancienne. Si vous avez besoin du même nom de base de données, vous pouvez alors les déplacer de nouveau dans un db frais par le même nom. Assurez-vous simplement de recréer les index.

use cleanup_database
db.dropDatabase();

use oversize_database

db.collection.find({},{}).forEach(function(doc){
    db = db.getSiblingDB("cleanup_database");
    db.collection_subset.insert(doc);
});

use oversize_database
db.dropDatabase();

use cleanup_database

db.collection_subset.find({},{}).forEach(function(doc){
    db = db.getSiblingDB("oversize_database");
    db.collection.insert(doc);
});

use oversize_database

<add indexes>
db.collection.ensureIndex({field:1});

use cleanup_database
db.dropDatabase();

une opération export/drop/import pour des bases de données avec de nombreuses collections atteindrait probablement le même résultat mais je n'ai pas testé.

aussi comme une politique, vous pouvez garder les collections permanentes dans un base de données à partir de vos données transitoires/de traitement et il suffit de laisser tomber la base de données de traitement une fois vos travaux terminés. Étant donné que MongoDB est sans schéma, rien d'autre que des index serait perdu et votre base de données et vos collections seront recréées lorsque les inserts pour les processus s'exécuteront ensuite. Assurez-vous juste que vos travaux comprennent la création de n'importe quels index nessecary à un moment approprié.

si vous utilisez replica sets , qui n'étaient pas disponibles lorsque cette question a été écrite à l'origine, alors vous pouvez configurer un processus pour récupérer automatiquement de l'espace sans encourir de perturbations importantes ou des problèmes de performance.

pour ce faire, vous profitez des capacités de synchronisation initiale automatique d'un secondaire dans un jeu de répliques. Pour expliquer: si vous fermez un secondaire, essuyez ses fichiers de données et le redémarrez, le secondaire va re-sync from scratch from one of the other nodes in the set (par défaut, il choisit le noeud le plus proche en regardant les temps de réponse ping). Lorsque cette resync se produit, toutes les données sont réécrites à partir de zéro (y compris les index), effectivement faire la même chose qu'une réparation, et l'espace disque qu'il a récupéré.

en exécutant ceci sur secondaries (puis en retirant la Primaire et en répétant le processus) vous pouvez récupérer efficacement l'espace disque sur l'ensemble de l'ensemble avec un minimum de perturbation. Vous avez besoin d'être prudent si vous lisez des secondaires, car cela prendra un secondaire hors de rotation pour un temps potentiellement long. Vous voulez également vous assurer que votre fenêtre oplog est suffisante pour effectuer une resync réussie, mais c'est généralement quelque chose que vous voudriez vous assurer si vous faites ceci ou non.

pour automatiser ce processus, vous auriez simplement besoin d'un script lancé pour effectuer cette action sur des jours séparés (ou similaire) pour chaque membre de votre ensemble, de préférence pendant votre temps calme ou la fenêtre d'entretien. Une version très naïve de ce script ressemblerait à ceci dans bash :

NOTE: IL S'AGIT ESSENTIELLEMENT D'UN PSEUDO - CODE-À TITRE INDICATIF SEULEMENT - NE PAS UTILISER POUR LES SYSTÈMES DE PRODUCTION SANS MODIFICATIONS IMPORTANTES

#!/bin/bash 

# First arg is host MongoDB is running on, second arg is the MongoDB port

MONGO=/path/to/mongo
MONGOHOST=
MONGOPORT=
DBPATH = /path/to/dbpath

# make sure the node we are connecting to is not the primary
while (`$MONGO --quiet --host $MONGOHOST --port $MONGOPORT --eval 'db.isMaster().ismaster'`)
do
    `$MONGO --quiet --host $MONGOHOST --port $MONGOPORT --eval 'rs.stepDown()'`
    sleep 2
done    
echo "Node is no longer primary!\n"

# Now shut down that server 
# something like (assuming user is set up for key based auth and has password-less sudo access a la ec2-user in EC2)
ssh -t user@$MONGOHOST sudo service mongodb stop

# Wipe the data files for that server

ssh -t user@$MONGOHOST sudo rm -rf $DBPATH
ssh -t user@$MONGOHOST sudo mkdir $DBPATH
ssh -t user@$MONGOHOST sudo chown mongodb:mongodb $DBPATH

# Start up server again
# similar to shutdown something like 
ssh -t user@$MONGOHOST sudo service mongodb start