MongoDB में प्रतिकृति में प्राथमिक और द्वितीयक सदस्यों की वास्तुकला वाले सदस्यों द्वारा प्रतिकृति सेट शामिल होते हैं, लेकिन कभी-कभी एक गैर डेटा असर सदस्य के साथ जिसे मध्यस्थ कहा जाता है। प्रतिकृति प्रक्रिया यह है कि, जब भी डेटा प्राथमिक नोड को लिखा गया है, तो परिवर्तन एक ओप्लॉग फ़ाइल पर दर्ज किए जाते हैं, जिससे द्वितीयक सदस्य समान परिवर्तन लागू करते हैं। रीड ऑपरेशंस किसी भी डेटा असर सदस्य से किया जा सकता है इसलिए एक ऐसा परिदृश्य तैयार करना जिसे आमतौर पर उच्च उपलब्धता के रूप में जाना जाता है।
हालांकि, कुछ मामलों में माध्यमिक सदस्य परिवर्तन करने में प्राथमिक के साथ पकड़ने में विफल हो सकते हैं और यदि इन परिवर्तनों को लागू करने से पहले प्राथमिक नोड विफल हो जाता है, तो किसी को पूरे क्लस्टर को फिर से सिंक करने के लिए मजबूर किया जाएगा। ताकि वे एक ही डेटा स्थिति में हो सकें।
रोलबैक क्या है?
यह MongoDB में एक स्वचालित विफलता सुविधा है, जहां प्रतिकृति सेट में प्राथमिक नोड परिवर्तन करते समय विफल हो सकता है, जो दुर्भाग्य से ओप्लॉग से समय पर द्वितीयक सदस्यों को दिखाई नहीं देता है, इसलिए इसे वापस करने की आवश्यकता है परिवर्तन किए जाने से पहले प्राथमिक से एक की स्थिति।
इसलिए रोलबैक केवल तभी आवश्यक हैं जब प्राथमिक ने उन कार्यों को लिखना स्वीकार कर लिया है जिन्हें प्राथमिक चरण से पहले द्वितीयक सदस्यों को दोहराया नहीं गया है, जैसे कि नेटवर्क विभाजन के कारण। यदि लिखने के संचालन को सदस्यों में से एक में दोहराने का प्रबंधन किया जाता है जो कि प्रतिकृति सेट के बहुमत के लिए उपलब्ध और पहुंच योग्य है, तो रोलबैक नहीं होगा।
मोंगोडीबी में रोलबैक के पीछे मुख्य कारण सभी सदस्यों के लिए डेटा स्थिरता बनाए रखना है और इसलिए, जब प्राथमिक प्रतिकृति सेट से जुड़ता है, यदि इसके परिवर्तन द्वितीयक सदस्यों पर लागू नहीं किए गए हैं, तो इसे वापस कर दिया जाएगा विफलता से पहले राज्य के लिए।
हालांकि, MongoDB में रोलबैक दुर्लभ होना चाहिए या इससे बचना चाहिए क्योंकि उनके परिणामस्वरूप बहुत अधिक डेटा हानि हो सकती है और परिणामस्वरूप डेटाबेस से जुड़े अनुप्रयोगों के संचालन को प्रभावित कर सकता है।
MongoDB रोलबैक प्रक्रिया
आइए, तीन सदस्यीय प्रतिकृति सेट पर विचार करें जिसमें A को प्राथमिक, B और C को द्वितीयक सदस्य के रूप में सेट किया गया है। हम डेटा को ए में पॉप्युलेट करेंगे और साथ ही कुछ नेटवर्क विभाजन को बी और सी में ट्रिगर करेंगे। हम इस परीक्षण में मोंगोडीबी संस्करण 4.2 और एटलस का उपयोग करेंगे।
सबसे पहले हम मोंगो शेल पर rs.status() कमांड चलाकर प्रतिकृति सेट की स्थिति प्राप्त करेंगे
MongoDB Enterprise Cluster0-shard-0:PRIMARY> rs.status()सदस्य विशेषता को देखकर आप कुछ इस तरह देख सकते हैं
"members" : [
{
"_id" : 0,
"name" : "cluster0-shard-00-00-sc27x.mongodb.net:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1891079,
"optime" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDurable" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDate" : ISODate("2020-07-15T15:25:11Z"),
"optimeDurableDate" : ISODate("2020-07-15T15:25:11Z"),
"lastHeartbeat" : ISODate("2020-07-15T15:25:19.509Z"),
"lastHeartbeatRecv" : ISODate("2020-07-15T15:25:18.532Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncingTo" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"syncSourceHost" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"syncSourceId" : 2,
"infoMessage" : "",
"configVersion" : 4
},
{
"_id" : 1,
"name" : "cluster0-shard-00-01-sc27x.mongodb.net:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1891055,
"optime" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDurable" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDate" : ISODate("2020-07-15T15:25:11Z"),
"optimeDurableDate" : ISODate("2020-07-15T15:25:11Z"),
"lastHeartbeat" : ISODate("2020-07-15T15:25:17.914Z"),
"lastHeartbeatRecv" : ISODate("2020-07-15T15:25:19.403Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncingTo" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"syncSourceHost" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"syncSourceId" : 2,
"infoMessage" : "",
"configVersion" : 4
},
{
"_id" : 2,
"name" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 1891089,
"optime" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDate" : ISODate("2020-07-15T15:25:11Z"),
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "",
"electionTime" : Timestamp(1592935644, 1),
"electionDate" : ISODate("2020-06-23T18:07:24Z"),
"configVersion" : 4,
"self" : true,
"lastHeartbeatMessage" : ""
}
],यह आपको आपके प्रतिकृति सेट के प्रत्येक सदस्य की स्थिति दिखाएगा। अब हमने नोड ए के लिए एक नया टर्मिनल खोला और इसे 20000 रिकॉर्ड के साथ भर दिया:
MongoDB Enterprise Cluster0-shard-0:PRIMARY> for (var y = 20000; y >= 0; y--) {
db.mytest.insert( { record : y } )
}
WriteResult({ "nInserted" : 1 })
MongoDB Enterprise Cluster0-shard-0:PRIMARY> db.mytest 2020-07-15T21:28:40.436+2128 I NETWORK [thread1] trying reconnect to 127.0.0.1:3001 (127.0.0.1) failed
2020-07-15T21:28:41.436+2128 I
NETWORK [thread1] reconnect 127.0.0.1:3001 (127.0.0.1) ok
MongoDB Enterprise Cluster0-shard-0:SECONDARY> rs.slaveOk()
MongoDB Enterprise Cluster0-shard-0:SECONDARY> db.mytest.count()
20000नेटवर्क विभाजन के दौरान, A डाउन हो जाएगा, जिससे यह B और C के लिए अनुपलब्ध हो जाएगा और इसलिए हमारे मामले में B को प्राथमिक चुना गया। जब A फिर से जुड़ता है तो इसे सेकेंडरी के रूप में जोड़ा जाएगा और आप rs.status() कमांड का उपयोग करके इसे देख सकते हैं। हालांकि, नेटवर्क विभाजन से पहले कुछ रिकॉर्ड सदस्य बी को दोहराने में कामयाब रहे जैसा कि नीचे देखा गया है:(याद रखें इस मामले में बी अब प्राथमिक है)
MongoDB Enterprise Cluster0-shard-0:PRIMARY> db.mytest.find({}).count()
12480 संख्या उन दस्तावेज़ों की संख्या है जिन्हें A के नीचे जाने से पहले B में दोहराया जा सकता था।
यदि हम B को कुछ डेटा लिखते हैं और A को नेटवर्क से जुड़ने की अनुमति देते हैं, तो हम A में कुछ परिवर्तन देख सकते हैं
connecting to: 127.0.0.1:3001/admin
MongoDB Enterprise Cluster0-shard-0:ROLLBACK>
MongoDB Enterprise Cluster0-shard-0:RECOVERING>
MongoDB Enterprise Cluster0-shard-0:SECONDARY>
MongoDB Enterprise Cluster0-shard-0:SECONDARY>
MongoDB Enterprise Cluster0-shard-0:PRIMARY>एक oplogFetcher का उपयोग करके द्वितीयक सदस्य अपने सिंक स्रोत से oplog प्रविष्टियों को सिंक करते हैं। oplogFetcher स्रोत oplog के लिए एक खोज विधि को ट्रिगर करता है जिसके बाद getMores कर्सर श्रृंखला की एक श्रृंखला होती है। जब A द्वितीयक के रूप में फिर से जुड़ता है तो वही दृष्टिकोण लागू होता है और विधेय टाइमस्टैम्प से बड़ा दस्तावेज़ वापस किया जाता है। यदि बी में पहला दस्तावेज़ ए के ऑप्लॉग की अंतिम प्रविष्टि से मेल नहीं खाता है, तो ए को रोलबैक के लिए मजबूर किया जाएगा।
MongoDB में रोलबैक डेटा पुनर्प्राप्त करना
मोंगडीबी में रोलबैक कोई बुरी चीज नहीं है, लेकिन यह सुनिश्चित करने के लिए जितना संभव हो उतना प्रयास करना चाहिए कि वे अक्सर नहीं होते हैं। यह एक प्रतिकृति सेट के सदस्यों के बीच डेटा स्थिरता सुनिश्चित करने का एक सुरक्षा ऑटो उपाय है। रोलबैक होने की स्थिति में, स्थिति से निपटने के लिए यहां कुछ चरण दिए गए हैं:
रोलबैक डेटा संग्रह
आपको रोलबैक के संबंध में सदस्य डेटा एकत्र करने की आवश्यकता है। यह सुनिश्चित करने के द्वारा किया जाता है कि रोलबैक फाइलें बनाई जाती हैं (केवल MongoDB संस्करण 4.0 के साथ उपलब्ध) createRollbackDataFiles को सक्षम करके। डिफ़ॉल्ट रूप से यह विकल्प सत्य पर सेट होता है इसलिए रोलबैक फ़ाइलें हमेशा बनाई जाएंगी।
रोलबैक फ़ाइलें
रोलबैक फ़ाइलें डेटा को एक अलग डेटाबेस या सर्वर में लोड करना
Mongorestore MongoDB का एक महत्वपूर्ण पहलू है जो रोलबैक डेटा फ़ाइलों की पुनर्प्राप्ति को सक्षम करने में सहायता कर सकता है। पहली बात यह है कि रोलबैक फ़ाइलों को एक नए सर्वर में कॉपी करना है और फिर mongorestore का उपयोग करके फ़ाइलों को अपने सर्वर में लोड करना है। mongorestore कमांड नीचे दिखाया गया है।
mongorestore -u <> -p <> -h 127.0.0.1 -d <rollbackrestoretestdb> -c <rollbackrestoretestc> <path to the .bson file> --authenticationDatabase=<database of user>जिस डेटा की आवश्यकता नहीं है उसे साफ करना और डेटा के माध्यम से स्थानांतरित करना
रोलबैक फ़ाइलों से रखे जाने वाले डेटा और फेंके जाने वाले डेटा के बीच चयन करने के लिए इस चरण में विवेक का उपयोग करने की आवश्यकता है। सभी रोलबैक फ़ाइलों के डेटा को आयात करने की सलाह दी जाती है, यह निर्णय बिंदु इस चरण को डेटा पुनर्प्राप्ति में सबसे कठिन चरण बनाता है।
डेटा आयात करने के लिए प्राथमिक को क्लस्टर के रूप में उपयोग करना
मोंगोरेस्टोर और मोंगोडम्प के उपयोग के माध्यम से साफ किए गए डेटा को डाउनलोड करके अंतिम चरण शुरू करें, डेटा को मूल उत्पादन क्लस्टर में फिर से आयात करके इसका पालन करें।
MongoDB रोलबैक को रोकना
MongoDB का उपयोग करते समय डेटा के रोलबैक को होने से रोकने के लिए कोई निम्न कार्य कर सकता है।
सभी वोटिंग सदस्यों को 'MaJORITY' चलाना
यह w:बहुमत लिखने की चिंता का उपयोग करके किया जा सकता है जिसमें विकल्प अनुरोध पावती की शक्ति है जो मोंगोड उदाहरणों के विशिष्ट टैग के लिए लेखन संचालन को सक्षम करेगा। इसे w विकल्प और उसके बाद
उपयोगकर्ता संचालन
MongoDB का अपडेटेड वर्जन, यानी वर्जन 4.2 में रोलबैक के मामले में चल रहे सभी ऑपरेशन को बंद करने की क्षमता है।
सूचकांक बनाता है
MongoDB फीचर कम्पैटिबिलिटी वर्जन (fcv) "4.2" का वर्जन 4.2 उन सभी इन-प्रोग्रेस इंडेक्स की प्रतीक्षा करने में सक्षम है जो रोलबैक से पहले बनाए और समाप्त किए जा रहे हैं। जगह। हालांकि, संस्करण 4.0 निरंतर प्रगति की प्रतीक्षा करता है और पृष्ठभूमि अनुक्रमणिका बनाता है इस प्रकार रोलबैक की संभावना अधिक होती है।
आकार और सीमाएं
MongoDB के संस्करण 4.0 में दिए गए डेटा की कोई सूचीबद्ध सीमा नहीं है, जिसे इन-प्रोग्रेस बैकग्राउंड इंडेक्स बनने पर वापस रोल किया जा सकता है।
निष्कर्ष
MongoDB रोलबैक उन लोगों के लिए एक सामान्य घटना है जो MongoDB का उपयोग करने वालों के लिए बिना यह जाने कि इसे कैसे रोका जाए। यदि कोई मोंगोडीबी में कुछ सुरक्षित प्रथाओं और रोलबैक से बचने के तरीकों का पालन करता है और उनका पालन करता है तो रोलबैक रोका जा सकता है। कुल मिलाकर, हमेशा मोंगोडीबी के नवीनतम संस्करण में अपग्रेड करने की सलाह दी जाती है ताकि कुछ रोकी जा सकने वाली हिचकी से बचा जा सके।
