Modifier et de relecture MongoDB oplog

Est-il possible de modifier la MongoDB oplog et de les relire?

Un bug causé une mise à jour soit appliquée à plus de documents qu'il était censé être, l'écrasement des données. Des données ont été récupérées à partir de la sauvegarde et de se réinsérer, de sorte que rien n'était perdu, mais je me demandais si il y avait un moyen de modifier les oplog de supprimer ou de modifier la délinquance de la mise à jour et de les relire.

Je n'ai pas connaissance de la profondeur de MongoDB internes, tellement instructif réponses le long des lignes de, "vous ne comprenez pas comment ça marche, c'est comme ça" sera également prise en considération.

  • techniquement, il est plafonnée à collection au sein de la local base de données donc, techniquement, vous pouvez simplement modifier les lignes et de les relire, je pense
  • vous ne pouvez pas faire beaucoup de choses à concurrence du plafond de la collection que vous pourriez faire à une collecte régulière - par exemple, vous ne pouvez pas supprimer des enregistrements à mettre à jour de manière à ce que les changements de leur taille. Il existe des utilitaires pour rejouer la oplog bien.
InformationsquelleAutor michaeltwofish | 2013-03-16
  1. 96

    Un des gros problèmes dans l'application ou d'une erreur humaine de la corruption de données, c'est que la délinquance écrire au primaire sera immédiatement répliqué pour le secondaire.

    C'est une des raisons pour lesquelles les utilisateurs à profiter de "slaveDelay" - une option pour exécuter l'un de vos noeuds secondaires avec un délai fixe (bien que seulement vous aide si vous découvrez une erreur ou un bug lors de la période de temps qui est plus courte que le retard que secondaire).

    Dans le cas où vous n'avez pas de set-up, vous devez compter sur une sauvegarde de recréer l'état des dossiers que vous avez besoin de restaurer à leur pré-correction d'un bug de l'état.

    Effectuer toutes les opérations sur un autre stand-alone copie de vos données uniquement après avoir vérifié que tout était bien recréé devrait vous déplacez ensuite le corrigé de données dans votre système de production.

    Ce qui est nécessaire pour être en mesure de le faire c'est une copie récente de la sauvegarde (disons que la sauvegarde est X heures) et le oplog sur votre cluster doit détenir plus de X heures de données. Je n'ai pas spécifié de quel nœud du oplog parce que (a) tous les membres du jeu de réplicas a le même contenu dans le oplog et (b) il est possible que votre oplog la taille est différente sur les différents membres de noeud, dans le cas où vous voulez vérifier le "plus grand" un.

    Donc, disons que votre dernière sauvegarde est de 52 heures, mais heureusement, vous avez un oplog qui détient 75 heures de données (yay).

    Vous déjà rendu compte que l'ensemble de vos noeuds (primaires et secondaires) ont le "mauvais" des données, donc ce que vous devriez faire est de restaurer cette sauvegarde plus récente dans une nouvelle mongod. C'est l'endroit où vous restaurer ces enregistrements à ce qu'ils étaient juste avant la mise à jour de la délinquance - et alors vous pouvez simplement déplacer dans le primaire courant de l'endroit où ils vont se reproduire à tous les secondaires.

    Lors de la restauration de votre sauvegarde, créer un mongodump de votre oplog collection via cette commande:

    mongodump -d local -c oplog.rs -o oplogD

    Déplacer le oplog dans son propre répertoire de la renommer en oplog.bfils:

    mkdir oplogR
mv oplogD/local/oplog.rs.bson oplogR/oplog.bson

    Maintenant, vous devez trouver le "fautif" de l'opération. Vous pouvez vider les oplog de forme lisible par l'homme, à l'aide de la bsondump commande sur oplogR/oplog.bfils fichier (et ensuite utiliser grep ou qu'est-ce-pas à trouver le "mauvais" mise à jour). Vous pouvez interroger l'origine oplog dans le jeu de réplicas via use local et db.oplog.rs.find() commandes dans le shell.

    Votre but est de trouver cette entrée et de noter ses ts champ.

    Il pourrait ressembler à ceci:

    "ts" : Timestamp( 1361497305, 2789 )

    Noter que le mongorestore commande a deux options, l'une appelée --oplogReplay et l'autre appelé oplogLimit. Vous allez maintenant relire cette oplog sur la restauration d'un serveur autonome, MAIS vous allez arrêter avant que cette délinquance opération de mise à jour.

    La commande (l'hôte et le port sont où votre nouvellement restauré la sauvegarde est):

    mongorestore -h host --port NNNN --oplogReplay --oplogLimit 1361497305:2789 oplogR

    Cela permettra de restaurer chaque opération de la oplog.bfils fichier dans oplogR répertoire s'arrêtant juste avant l'entrée avec ts valeur d'Horodatage(1361497305, 2789).

    Rappeler que la raison pour laquelle vous avez été faire sur une instance distincte est de sorte que vous pouvez vérifier la restauration et de relecture créé de rectification des données - une fois que vous avez vérifié, alors vous pouvez écrire la restauration des enregistrements à l'endroit approprié dans le primaire réelle (et permettre la réplication de propager les enregistrements corrigés pour les secondaires).

    • Merci, c'est exactement ce que je cherchais. La situation est tout comme vous le décrivez, avec un retard de noeud qui avait déjà répliqué la mauvaise mise à jour.
    • Salut. Je suis nouveau sur Mongo, donc je me demandais si cette base de données locale des magasins oplog des bases de données et des collections? Que faire si j'ai besoin de restaurer la base de données unique ou d'une collection, comment pourrais-je filtre les entrées oplog ?
    • il y a un seul oplog par mongod processus.
    • Réponse utile. Trivia astuce: cette réponse est référencé comme une ressource utile dans un des devoirs de l'élément de MongoDB Cours à l'Université M202, les Devoirs 2.5.
    InformationsquelleAutor Asya Kamsky