Mongo RepairDatabase a échoué sur Dupliquer

Question

Mystérieusement après une copie hors connexion de mes données vers un autre serveur, bomgar.1 (un fichier de données) était manquant sur tous les serveurs. J'ai environ 850 Go de données dans le magasin de fichiers de la grille dans cette base de données. Tous les outils de réparation ont échoué en raison du fichier manquant. J'ai essayé de copier dans un "faux" bomgar.1 d'un autre serveur (même nom de base de données, même taille de fichier), et cela a permis aux outils de réparation de vider les données, mais quand ils sont allés insérer les docs valides , je suis la sortie suivante:

> use bomgar 
switched to db bomgar 
> db.repairDatabase() 
{ 
     "ok" : 0, 
     "errmsg" : "E11000 duplicate key error index: bomgar.fs.chunks.$files_id_1_n_1 dup key: { : null, : null }", 
     "code" : 11000 
} 

Je ne fais pas beaucoup dans la coquille Mongo. Je ne suis pas intéressé à conserver des données en double. Le fichier "faux" est seulement 128 Mo, donc perdre cette tranche de mes données est beaucoup mieux que de perdre l'ensemble de 850 Go. Nous sommes en train de déplacer ces données vers un jeu de réplicas, et il semble qu'aucun des serveurs n'affiche la collection fs.files, donnant l'erreur bad offset:0 accessing file: /data/grid/bomgar.0. See http://dochub.mongodb.org/core/data-recovery, mais je peux voir fs.chunks et system.indexes.

En résumé: Comment puis-je sauvegarder mes données même si une partie est manquante?

Answer 1

Finalement, j'ai fini par utiliser mongodump et mongorestore car ils étaient capables d'ignorer les doublons, où db.repairDatabase() a échoué lorsqu'il a frappé un doublon. Je ne suis pas vraiment sûr de savoir pourquoi je suis passé de 800 Go de données à 2,2 To de données, mais je ne peux pas exclure l'ajout de données alors que le serveur était prêt à être réparé, cela n'a aucun sens. énorme. Je ne peux pas savoir avec certitude combien de données ont été conservées, mais il semble que la "fausse" tranche que j'ai ajoutée pour arrêter les erreurs n'a pas inséré de documents étranges, et a semblé rendre les outils de réparation heureux. Heureusement, j'avais beaucoup plus d'espace disque disponible pour la réparation que ce à quoi je m'attendais.

Morale de l'histoire est d'obéir aux docs et ne pas mettre les données de production sur une seule instance à moins que vous êtes prêt à le perdre! Je souhaite qu'ils suggéreraient d'utiliser dump/restore au lieu de repairDatabase puisque j'ai perdu beaucoup de temps là-dessus.