Modifier et relire le fichier oplog de MongoDB

Est-il possible de modifier l’oplog MongoDB et de le rejouer?

Un bogue entraînait l’application d’une mise à jour à plus de documents qu’elle n’était censée être, écrasant certaines données. Les données ont été récupérées à partir de la sauvegarde et réintégrées, donc rien n’a été réellement perdu, mais je me demandais s’il était possible de modifier l’oplog pour supprimer ou modifier la mise à jour incriminée et la relire.

Je n’ai pas une connaissance approfondie des éléments internes de MongoDB, donc des réponses informatives du type «vous ne comprenez pas comment cela fonctionne, c’est comme ça» seront également sockets en compte pour l’acceptation.

Un des gros problèmes de corruption des données d’application ou d’erreur humaine est que l’écriture fautive sur le primaire sera immédiatement répliquée sur le secondaire.

C’est l’une des raisons pour lesquelles les utilisateurs profitent de “slaveDelay” – une option pour exécuter un de vos nœuds secondaires avec un délai fixe (bien sûr, cela ne vous aide que si vous découvrez l’erreur ou le bogue pendant la période inférieure à le retard sur ce secondaire).

Si vous ne disposez pas d’une telle configuration, vous devez compter sur une sauvegarde pour recréer l’état des enregistrements à restaurer dans leur état antérieur au bogue.

Effectuez toutes les opérations sur une copie autonome distincte de vos données – uniquement après avoir vérifié que tout a été correctement recréé si vous transférez ensuite les données corrigées dans votre système de production.

Pour ce faire, une copie récente de la sauvegarde (disons que la sauvegarde a X heures) est requirejse, et le contenu de votre cluster doit contenir plus de X heures de données. Je n’ai pas spécifié l’oplog du noeud car (a) tous les membres du jeu de réplicas ont le même contenu dans le journal des opérations et (b) il est possible que la taille de votre journal soit différente sur les différents membres du noeud. le “plus grand”.

Donc, disons que votre sauvegarde la plus récente a 52 heures, mais heureusement, vous avez un journal qui contient 75 heures de données (yay).

Vous vous êtes déjà rendu compte que tous vos nœuds (principaux et secondaires) possèdent les “mauvaises” données. Vous devez donc restaurer cette dernière sauvegarde dans un nouveau mongod. C’est ici que vous restaurerez ces enregistrements en fonction de ce qu’ils étaient juste avant la mise à jour incriminée – et vous pourrez ensuite les déplacer dans le primaire actuel à partir duquel ils seront répliqués sur tous les secondaires.

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

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

Déplacez l’oplog dans son propre répertoire en le renommant oplog.bson:

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

Maintenant, vous devez trouver l’opération “offensante”. Vous pouvez extraire l’oplog au format lisible par l’homme, en utilisant la commande bsondump sur le fichier oplogR / oplog.bson (puis utiliser grep ou what-not pour trouver la “mauvaise” mise à jour). Vous pouvez également interroger l’oplog d’origine dans le jeu de réplicas via les commandes use local et db.oplog.rs.find() du shell.

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

Cela pourrait ressembler à ceci:

"ts" : Timestamp( 1361497305, 2789 )

Notez que la commande mongorestore a deux options, l’une appelée --oplogReplay et l’autre appelée oplogLimit . Vous allez maintenant relire cette oplog sur le serveur autonome restauré, mais vous vous arrêterez avant cette opération de mise à jour incriminée.

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

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

Cela restaure chaque opération à partir du fichier oplog.bson dans le répertoire oplogR qui s’arrête juste avant l’entrée avec la valeur ts Timestamp (1361497305, 2789).

Rappelez-vous que la raison pour laquelle vous faisiez cela sur une instance distincte est que vous pouvez vérifier que la restauration et la relecture ont créé les données correctes – une fois que vous les avez vérifiées, vous pouvez écrire les enregistrements restaurés au bon endroit les enregistrements corrigés aux secondaires).