आवेदन या मानव त्रुटि डेटा भ्रष्टाचार में एक बड़ा मुद्दा यह है कि प्राथमिक को आपत्तिजनक लेखन तुरंत माध्यमिक में दोहराया जाएगा।
यह एक कारण है कि उपयोगकर्ता "स्लेवडेले" का लाभ उठाते हैं - एक निश्चित समय की देरी के साथ आपके माध्यमिक नोड्स में से एक को चलाने का विकल्प (निश्चित रूप से यह केवल तभी आपकी मदद करता है जब आप उस समय अवधि के दौरान त्रुटि या बग की खोज करते हैं जो इससे कम है उस माध्यमिक पर देरी)।
यदि आपके पास ऐसा कोई सेट-अप नहीं है, तो आपको उन अभिलेखों की स्थिति को फिर से बनाने के लिए बैकअप पर निर्भर रहना होगा जिनकी आपको उनकी पूर्व-बग स्थिति में पुनर्स्थापित करने की आवश्यकता है।
अपने डेटा की एक अलग स्टैंड-अलोन कॉपी पर सभी ऑपरेशन करें - यह सत्यापित करने के बाद ही कि सब कुछ ठीक से बनाया गया था, क्या आप सही डेटा को अपने उत्पादन सिस्टम में ले जाना चाहिए।
ऐसा करने में सक्षम होने के लिए बैकअप की हाल की प्रति की आवश्यकता होती है (मान लें कि बैकअप X घंटे पुराना है) और आपके क्लस्टर के ओप्लॉग में X घंटे से अधिक का डेटा होना चाहिए। मैंने यह निर्दिष्ट नहीं किया कि किस नोड का ओप्लॉग है क्योंकि (ए) प्रतिकृति सेट के प्रत्येक सदस्य के पास ओप्लॉग में समान सामग्री है और (बी) यह है संभव है कि आपके ओप्लॉग का आकार अलग-अलग नोड सदस्यों पर अलग हो, इस स्थिति में आप "सबसे बड़े" वाले को देखना चाहते हैं।
तो मान लें कि आपका सबसे हाल का बैकअप 52 घंटे पुराना है, लेकिन सौभाग्य से आपके पास एक ओप्लॉग है जिसमें 75 घंटे का डेटा (याय) है।
आप पहले ही महसूस कर चुके हैं कि आपके सभी नोड्स (प्राथमिक और सेकेंडरी) में "खराब" डेटा है, इसलिए आप जो करेंगे वह इस सबसे हालिया बैकअप को एक नए मोंगॉड में पुनर्स्थापित करेगा। यह वह जगह है जहां आप इन रिकॉर्ड्स को उस स्थिति में पुनर्स्थापित करेंगे जो वे आपत्तिजनक अपडेट से ठीक पहले थे - और फिर आप उन्हें केवल वर्तमान प्राथमिक में स्थानांतरित कर सकते हैं, जहां से वे सभी सेकेंडरी में दोहराए जाएंगे।
अपने बैकअप को पुनर्स्थापित करते समय, इस आदेश के माध्यम से अपने oplog संग्रह का एक mongodump बनाएं:
mongodump -d local -c oplog.rs -o oplogD
oplog को oplog.bson नाम देते हुए उसकी अपनी निर्देशिका में ले जाएँ:
mkdir oplogR
mv oplogD/local/oplog.rs.bson oplogR/oplog.bson
अब आपको "अपमानजनक" ऑपरेशन खोजने की जरूरत है। आप bsondump . का उपयोग करके ओप्लॉग को मानव पठनीय रूप में डंप कर सकते हैं oplogR/oplog.bson फ़ाइल पर कमांड (और फिर "खराब" अपडेट खोजने के लिए grep या what-not का उपयोग करें)। वैकल्पिक रूप से आप use local . के माध्यम से प्रतिकृति सेट में मूल oplog के विरुद्ध क्वेरी कर सकते हैं और db.oplog.rs.find() शेल में कमांड।
आपका लक्ष्य इस प्रविष्टि को ढूंढना है और इसके ts . को नोट करना है फ़ील्ड.
यह ऐसा दिखाई दे सकता है:
"ts" : Timestamp( 1361497305, 2789 )
ध्यान दें कि mongorestore कमांड के दो विकल्प होते हैं, एक को --oplogReplay . कहा जाता है और दूसरे को oplogLimit . कहा जाता है . अब आप इस ऑप्लॉग को पुनर्स्थापित स्टैंड-अलोन सर्वर पर फिर से चलाएंगे लेकिन आप इस अपमानजनक अद्यतन कार्रवाई से पहले रुक जाएंगे।
कमांड होगा (होस्ट और पोर्ट वह जगह है जहां आपका नया पुनर्स्थापित बैकअप है):
mongorestore -h host --port NNNN --oplogReplay --oplogLimit 1361497305:2789 oplogR
यह ts मान टाइमस्टैम्प (1361497305, 2789) के साथ प्रविष्टि से ठीक पहले oplogR निर्देशिका में oplog.bson फ़ाइल से प्रत्येक ऑपरेशन को पुनर्स्थापित करेगा।
याद रखें कि आप इसे एक अलग उदाहरण पर कर रहे थे, इसलिए आप बनाए गए सही डेटा को पुनर्स्थापित और रीप्ले को सत्यापित कर सकते हैं - एक बार जब आप इसे सत्यापित कर लेते हैं तो आप वास्तविक प्राथमिक में उचित स्थान पर पुनर्स्थापित रिकॉर्ड लिख सकते हैं (और प्रतिकृति प्रचार की अनुमति दें सेकेंडरी के लिए सही रिकॉर्ड)।
