कोई रोलबैक विकल्प नहीं है (मोंगोडीबी संदर्भ में रोलबैक का एक अलग अर्थ है), और सख्ती से बोलना इन दस्तावेज़ों को वापस पाने का कोई समर्थित तरीका नहीं है - आप जो सावधानियां बरत सकते हैं/उन्हें टिप्पणियों में शामिल किया जाना चाहिए। इसके साथ ही, यदि आप एक प्रतिकृति सेट चला रहे हैं, यहां तक कि एक नोड प्रतिकृति सेट भी, तो आपके पास एक oplog है . एक oplog . के साथ जो कवर करता है जब दस्तावेज़ सम्मिलित किए गए थे, तो आप उन्हें पुनर्प्राप्त करने में सक्षम हो सकते हैं।
इसे समझाने का सबसे आसान तरीका एक उदाहरण है। मैं केवल 100 हटाए गए दस्तावेज़ों के साथ एक सरलीकृत उदाहरण का उपयोग करूंगा जिन्हें पुनर्स्थापित करने की आवश्यकता है। इससे आगे जाने के लिए (बड़ी संख्या में दस्तावेज़, या शायद आप केवल चुनिंदा रूप से पुनर्स्थापित करना चाहते हैं आदि) आप या तो कर्सर पर पुनरावृति करने के लिए कोड बदलना चाहेंगे या MongoDB शेल के बाहर अपनी पसंद की भाषा का उपयोग करके इसे लिखना चाहेंगे। मूल तर्क वही रहता है।
सबसे पहले, हम अपना उदाहरण संग्रह foo बनाते हैं डेटाबेस में dropTest . हम name . के बिना 100 दस्तावेज़ सम्मिलित करेंगे एक समान name . के साथ फ़ील्ड और 100 दस्तावेज़ फ़ील्ड ताकि उन्हें बाद में गलती से हटाया जा सके:
use dropTest;
for(i=0; i < 100; i++){db.foo.insert({_id : i})};
for(i=100; i < 200; i++){db.foo.insert({_id : i, name : "some_x_name"})};
अब, हमारे 100 name . के आकस्मिक निष्कासन का अनुकरण करते हैं दस्तावेज़:
> db.foo.remove({ "name" : "some_x_name"})
WriteResult({ "nRemoved" : 100 })
क्योंकि हम एक प्रतिकृति सेट में चल रहे हैं, हमारे पास अभी भी इन दस्तावेज़ों का रिकॉर्ड oplog . में है (सम्मिलित किया जा रहा है) और शुक्र है कि वे सम्मिलन (अभी तक) oplog के अंत तक नहीं गिरे हैं (oplog एक कैप्ड संग्रह याद है)। देखते हैं कि क्या हम उन्हें ढूंढ पाते हैं:
use local;
db.oplog.rs.find({op : "i", ns : "dropTest.foo", "o.name" : "some_x_name"}).count();
100
गिनती सही लग रही है, ऐसा लगता है कि हमारे पास अभी भी हमारे दस्तावेज़ हैं। मैं अनुभव से जानता हूं कि oplog . का एकमात्र टुकड़ा यहां हमें जिस प्रविष्टि की आवश्यकता होगी वह है o फ़ील्ड, तो चलिए केवल उसे वापस करने के लिए एक प्रक्षेपण जोड़ते हैं (संक्षिप्तता के लिए आउटपुट छीन लिया गया है, लेकिन आपको विचार मिलता है):
db.oplog.rs.find({op : "i", ns : "dropTest.foo", "o.name" : "some_x_name"}, {"o" : 1});
{ "o" : { "_id" : 100, "name" : "some_x_name" } }
{ "o" : { "_id" : 101, "name" : "some_x_name" } }
{ "o" : { "_id" : 102, "name" : "some_x_name" } }
{ "o" : { "_id" : 103, "name" : "some_x_name" } }
{ "o" : { "_id" : 104, "name" : "some_x_name" } }
उन दस्तावेज़ों को फिर से सम्मिलित करने के लिए, हम उन्हें केवल एक सरणी में संग्रहीत कर सकते हैं, फिर सरणी पर पुनरावृति कर सकते हैं और संबंधित टुकड़े सम्मिलित कर सकते हैं। सबसे पहले, आइए अपना एरे बनाएं:
var deletedDocs = db.oplog.rs.find({op : "i", ns : "dropTest.foo", "o.name" : "some_x_name"}, {"o" : 1}).toArray();
> deletedDocs.length
100
इसके बाद हम खुद को याद दिलाते हैं कि हमारे पास अभी संग्रह में केवल 100 दस्तावेज़ हैं, फिर 100 प्रविष्टियों पर लूप करें, और अंत में हमारी गणना को फिर से सत्यापित करें:
use dropTest;
db.foo.count();
100
// simple for loop to re-insert the relevant elements
for (var i = 0; i < deletedDocs.length; i++) {
db.foo.insert({_id : deletedDocs[i].o._id, name : deletedDocs[i].o.name});
}
// check total and name counts again
db.foo.count();
200
db.foo.count({name : "some_x_name"})
100
और वहां आपके पास है, कुछ चेतावनियों के साथ:
- यह एक सच्ची बहाली रणनीति नहीं है, बैकअप (एमएमएस, अन्य) को देखें, उसके लिए विलंबित सेकेंडरी, जैसा कि टिप्पणियों में बताया गया है
- एक बड़े व्यस्त सिस्टम पर ओप्लॉग (कोई भी ओप्लॉग क्वेरी एक टेबल स्कैन है) से दस्तावेज़ों को क्वेरी करना विशेष रूप से तेज़ नहीं होगा।
- दस्तावेज किसी भी समय ओप्लॉग से बाहर हो सकते हैं (आप निश्चित रूप से, बाद में उपयोग के लिए आपको अधिक समय देने के लिए ओप्लॉग की एक प्रति बना सकते हैं)
- आपके कार्यभार के आधार पर आपको परिणामों को दोबारा डालने से पहले उन्हें डी-डुप्लिकेट करना पड़ सकता है
- दस्तावेज़ों के बड़े सेट एक सरणी के लिए बहुत बड़े होंगे जैसा कि दिखाया गया है, इसलिए आपको इसके बजाय एक कर्सर पर पुनरावृति करने की आवश्यकता होगी
oplogका प्रारूप आंतरिक माना जाता है और किसी भी समय (बिना सूचना के) बदल सकता है, इसलिए अपने जोखिम पर उपयोग करें
