Erlang 21 - 7. Mnesia System Information

7 मेन्सिया प्रणाली की जानकारी




erlang

7 मेन्सिया प्रणाली की जानकारी

निम्नलिखित विषयों में शामिल हैं:

  • डेटाबेस कॉन्फ़िगरेशन डेटा
  • कोर डंप
  • डंपिंग टेबल
  • चौकियों
  • स्टार्टअप फाइलें, लॉग फाइल और डेटा फाइलें
  • स्टार्टअप पर टेबल लोड हो रहा है
  • संचार विफलता से पुनर्प्राप्ति
  • लेन-देन की वसूली
  • बैकअप, रिस्टोर, फॉलबैक और डिजास्टर रिकवरी

7.1 डेटाबेस कॉन्फ़िगरेशन डेटा

सिस्टम जानकारी को पुनः प्राप्त करने के लिए निम्नलिखित दो कार्यों का उपयोग किया जा सकता है। विवरण के लिए, संदर्भ मैनुअल देखें।

7.2 कोर डंप

Mnesia malfunctions, सिस्टम जानकारी को MnesiaCore.Node.When फ़ाइल करने के लिए डंप किया MnesiaCore.Node.When । इस फ़ाइल में निहित सिस्टम जानकारी का प्रकार फ़ंक्शन mnesia_lib:coredump() साथ भी उत्पन्न हो सकता है। यदि एक Mnesia प्रणाली अजीब व्यवहार करती है, तो यह सिफारिश की जाती है कि बग रिपोर्ट में एक Mnesia कोर डंप फ़ाइल शामिल हो।

7.3 डंपिंग टेबल्स

प्रकार की तालिकाएँ ram_copies केवल स्मृति में संग्रहीत परिभाषा द्वारा ram_copies हैं। हालांकि, इन तालिकाओं को डिस्क में डंप किया जा सकता है, या तो नियमित अंतराल पर या सिस्टम बंद होने से पहले। फंक्शन mnesia:dump_tables(TabList) डिस्क के लिए रैम तालिकाओं के एक सेट के सभी प्रतिकृतियों को mnesia:dump_tables(TabList) । डिस्क पर डंप होने के दौरान टेबल तक पहुँचा जा सकता है। डिस्क पर तालिकाओं को डंप करने के लिए, सभी प्रतिकृतियों में भंडारण प्रकार ram_copies होना चाहिए।

टेबल सामग्री को डिस्क पर एक .DCD फ़ाइल में रखा गया है। जब Mnesia सिस्टम शुरू किया जाता है, तो RAM तालिका प्रारंभ में .DCD फ़ाइल के डेटा से भरी .DCD है।

7.4 चौकी

एक चेकपॉइंट एक लेनदेन सुसंगत राज्य है जो एक या अधिक तालिकाओं पर फैला हुआ है। जब एक चेकपॉइंट सक्रिय होता है, तो सिस्टम तालिकाओं के सेट की वर्तमान सामग्री को याद रखता है। चेकपॉइंट तालिकाओं की एक सुसंगत स्थिति को बनाए रखता है, जिससे चेकपॉइंट सक्रिय होने के दौरान तालिकाओं को पढ़ने और अद्यतन करने की अनुमति मिलती है। एक चेकपॉइंट आमतौर पर बाहरी मीडिया के लिए तालिकाओं का उपयोग करने के लिए उपयोग किया जाता है, लेकिन उन्हें अन्य प्रयोजनों के लिए Mnesia में आंतरिक रूप से भी उपयोग किया जाता है। प्रत्येक चौकी स्वतंत्र है और एक मेज एक साथ कई चौकियों में शामिल हो सकती है।

प्रत्येक तालिका एक चेकपॉइंट अनुचर में अपनी पुरानी सामग्री को बरकरार रखती है। प्रदर्शन महत्वपूर्ण अनुप्रयोगों के लिए, चौकियों के साथ जुड़े प्रसंस्करण ओवरहेड को महसूस करना महत्वपूर्ण हो सकता है। सबसे खराब स्थिति में, चेकपॉइंट अनुचर मेज से अधिक मेमोरी का उपभोग करता है। इसके अलावा, प्रत्येक अपडेट उन नोड्स पर थोड़ा धीमा हो जाता है जहां चेकपॉइंट रिटेनर्स टेबल से जुड़े होते हैं।

प्रत्येक तालिका के लिए, यह चुनना संभव है कि क्या तालिका के सभी प्रतिकृतियों से जुड़ा एक चेकपॉइंट अनुचर होना है, या यदि केवल एक चेकपॉइंट अनुचर एक एकल प्रतिकृति से जुड़ा होना पर्याप्त है। प्रति तालिका में एकल चेकपॉइंट अनुचर के साथ, चेकपॉइंट कम मेमोरी खाता है, लेकिन यह नोड क्रैश के लिए कमजोर है। कई निरर्थक चेकपॉइंट रिटेनर्स के साथ, चेकपॉइंट तब तक जीवित रहता है जब तक कि प्रत्येक टेबल पर कम से कम एक सक्रिय चेकपॉइंट अनुचर संलग्न न हो।

चेकपॉइंट्स को स्पष्ट रूप से फ़ंक्शन mnesia:deactivate_checkpoint(Name) साथ निष्क्रिय किया जा सकता है mnesia:deactivate_checkpoint(Name) , जहां Name एक सक्रिय चेकपॉइंट का Name है। यदि सफल या {error, Reason} ok तो यह फ़ंक्शन ok । एक चेकपॉइंट की सभी तालिकाएँ कम से कम एक चेकपॉइंट अनुचर से जुड़ी होनी चाहिए। Mnesia स्वचालित रूप से Mnesia द्वारा निष्क्रिय कर दिया जाता है, जब किसी भी तालिका में चेकपॉइंट अनुचर की कमी होती है। यह तब हो सकता है जब एक नोड नीचे जाता है या जब एक प्रतिकृति हटा दी जाती है। चेकपॉइंट रिटेनर अतिरेक की डिग्री को नियंत्रित करने के लिए तर्कों और max (निम्नलिखित सूची में वर्णित) का उपयोग करें।

चेकपॉइंट फंक्शन mnesia:activate_checkpoint(Args) साथ सक्रिय होते हैं mnesia:activate_checkpoint(Args) , जहाँ Args निम्नलिखित ट्यूपल्स की एक सूची है:

  • {name,Name} , जहां Name चौकी का अस्थायी नाम निर्दिष्ट करता है। चेकपॉइंट को निष्क्रिय करने के बाद नाम का पुन: उपयोग किया जा सकता है। यदि कोई नाम निर्दिष्ट नहीं है, तो एक नाम स्वतः उत्पन्न होता है।
  • {max,MaxTabs} , जहां MaxTabs उन टेबल की एक सूची है जिन्हें चेकपॉइंट में शामिल किया जाना है। डिफ़ॉल्ट [] (खाली सूची) है। इन तालिकाओं के लिए, अतिरेक को अधिकतम किया जाता है। जब मुख्य तालिका अनुप्रयोगों द्वारा अद्यतन की जाती है, तो तालिका की पुरानी सामग्री को चेकपॉइंट अनुचर में बनाए रखा जाता है। यदि टेबल पर कई प्रतिकृतियां हैं, तो चौकी अधिक सहिष्णु है। जब स्कीमा जोड़तोड़ समारोह mnesia:add_table_copy/3 द्वारा नई प्रतिकृतियां जोड़ी जाती हैं mnesia:add_table_copy/3 यह एक स्थानीय चेकपॉइंट अनुचर भी संलग्न करता है।
  • {min,MinTabs} , जहां MinTabs उन टेबल की एक सूची है, जिन्हें चेकपॉइंट में शामिल किया जाना है। डिफ़ॉल्ट [] । इन तालिकाओं के लिए अतिरेक को कम से कम किया जाता है, और स्थानीय नोड पर अधिमानतः प्रति तालिका एकल चेकपॉइंट अनुचर होना चाहिए।
  • {allow_remote,Bool} , जहां false अर्थ है कि सभी चेकपॉइंट अनुचर स्थानीय होना चाहिए। यदि कोई तालिका स्थानीय रूप से नहीं रहती है, तो चेकपॉइंट सक्रिय नहीं किया जा सकता है। true किसी भी नोड पर चौकी के रखवालों को आवंटित करने की अनुमति देता है। डिफ़ॉल्ट true
  • {ram_overrides_dump,Bool} । यह तर्क केवल प्रकार के तालिकाओं पर लागू होता है ram_copies Bool निर्दिष्ट करता है कि डिस्क में तालिका स्थिति रैम में ओवरराइड है या नहीं। true अर्थ है कि रैम में नवीनतम प्रतिबद्ध रिकॉर्ड चेकपॉइंट अनुचर में शामिल हैं। ये रिकॉर्ड हैं जो एप्लिकेशन एक्सेस करते हैं। false मतलब है कि डिस्क .DAT फ़ाइल पर रिकॉर्ड चेकपॉइंट अनुचर में शामिल हैं। ये रिकॉर्ड स्टार्टअप पर लदे हुए हैं। डिफ़ॉल्ट false

फ़ंक्शन mnesia:activate_checkpoint(Args) निम्न में से एक मान लौटाता है:

  • {ok, Name, Nodes}
  • {error, Reason}

Name चौकी का नाम है। Nodes वे Nodes हैं जहां चेकपॉइंट ज्ञात है।

निम्नलिखित कार्यों के साथ सक्रिय चौकियों की एक सूची प्राप्त की जा सकती है:

7.5 स्टार्टअप फाइलें, लॉग फाइल और डेटा फाइलें

यह खंड उन आंतरिक फ़ाइलों का वर्णन करता है, जो Mnesia प्रणाली द्वारा बनाई और रखी जाती हैं। विशेष रूप से, Mnesia लॉग के कामकाज का वर्णन किया गया है।

स्टार्टअप फाइलें

Start Mnesia निम्नलिखित पूर्वापेक्षाएँ Mnesia :

  • Erlang सत्र शुरू किया जाना चाहिए और डेटाबेस के लिए Mnesia निर्देशिका निर्दिष्ट की जानी चाहिए।
  • फंक्शन mnesia:create_schema/1 का उपयोग करके एक डेटाबेस स्कीमा शुरू किया जाना चाहिए mnesia:create_schema/1

निम्न उदाहरण दिखाता है कि ये कार्य कैसे किए जाते हैं:

चरण 1: एक Mnesia सत्र शुरू करें और डेटाबेस के लिए एक Mnesia निर्देशिका निर्दिष्ट करें:

% erl -sname klacke -mnesia dir '"/ldisc/scratch/klacke"'
Erlang (BEAM) emulator version 4.9
 
Eshell V4.9  (abort with ^G)
([email protected])1> mnesia:create_schema([node()]).
ok
([email protected])2> 
^Z
Suspended

चरण 2: आप Mnesia निर्देशिका का निरीक्षण कर सकते हैं कि क्या फाइलें बनाई गई हैं:

% ls -l /ldisc/scratch/klacke
-rw-rw-r--   1 klacke   staff       247 Aug 12 15:06 FALLBACK.BUP

प्रतिक्रिया से पता चलता है कि फ़ाइल FALLBACK.BUP बनाई गई है। इसे एक बैकअप फ़ाइल कहा जाता है, और इसमें एक प्रारंभिक स्कीमा होता है। यदि फ़ंक्शन mnesia:create_schema/1 में एक से अधिक नोड mnesia:create_schema/1 निर्दिष्ट किया गया था, तो सभी नोड्स पर समान बैकअप फ़ाइलें बनाई गई होंगी।

चरण 3: प्रारंभ Mnesia :

([email protected])3>mnesia:start( ).
ok

चरण 4: आप Mnesia निर्देशिका में निम्नलिखित लिस्टिंग देख सकते हैं:

-rw-rw-r--   1 klacke   staff         86 May 26 19:03 LATEST.LOG
-rw-rw-r--   1 klacke   staff      34507 May 26 19:03 schema.DAT

बैकअप फ़ाइल schema.DAT में स्कीमा का उपयोग फ़ाइल स्कीमा बनाने के लिए किया गया है। schema.DAT । चूंकि स्कीमा की तुलना में कोई अन्य डिस्क निवासी तालिकाएं नहीं हैं, इसलिए कोई अन्य डेटा फ़ाइलें नहीं बनाई गई थीं। फ़ाइल FALLBACK.BUP को सफल "बहाली" के बाद हटा दिया गया था। आप कुछ फाइलें भी देखते हैं जो Mnesia द्वारा आंतरिक उपयोग के लिए हैं।

चरण 5: एक तालिका बनाएँ:

([email protected])4> mnesia:create_table(foo,[{disc_copies, [node()]}]).
{atomic,ok}

चरण 6: आप Mnesia निर्देशिका में निम्नलिखित लिस्टिंग देख सकते हैं:

% ls -l /ldisc/scratch/klacke
-rw-rw-r-- 1 klacke staff    86 May 26 19:07 LATEST.LOG
-rw-rw-r-- 1 klacke staff    94 May 26 19:07 foo.DCD
-rw-rw-r-- 1 klacke staff  6679 May 26 19:07 schema.DAT

फ़ाइल foo.DCD बनाई गई है। यह फ़ाइल अंततः सभी डेटा को संग्रहीत करेगी जिसे foo तालिका में लिखा गया है।

लॉग फ़ाइल

Mnesia शुरू करते Mnesia , .LOG नामक एक .LOG फाइल डेटाबेस डायरेक्टरी में बनाई और रखी जाती है। इस फाइल का उपयोग Mnesia द्वारा डिस्क-आधारित लेनदेन लॉग करने के लिए किया जाता है। इसमें सभी लेनदेन शामिल हैं जो एक तालिका में कम से कम एक रिकॉर्ड लिखते हैं जो भंडारण प्रकार के हैं disc_copies या disc_only_copies । फ़ाइल में सभी ऑपरेशन भी शामिल हैं जो स्कीमा को हेरफेर करते हैं, जैसे कि नई टेबल बनाना। लॉग प्रारूप Mnesia विभिन्न कार्यान्वयनों के साथ भिन्न हो सकते हैं। Mnesia लॉग वर्तमान में Kernel में मानक पुस्तकालय मॉड्यूल disk_log में लागू किया गया है।

लॉग फ़ाइल लगातार बढ़ती है और नियमित अंतराल पर डंप होनी चाहिए। "लॉग फ़ाइल को Mnesia " का अर्थ है कि Mnesia लॉग में सूचीबद्ध सभी ऑपरेशन करता है और रिकॉर्ड को संबंधित .DAT , .DCD और .DCL डेटा फ़ाइलों में .DCD । उदाहरण के लिए, यदि ऑपरेशन "रिकॉर्ड रिकॉर्ड {foo, 4, elvis, 6} " लॉग में सूचीबद्ध है, तो Mnesia फ़ाइल foo.DCL में ऑपरेशन सम्मिलित करता है। बाद में, जब Mnesia लगता है कि .DCL फ़ाइल बहुत बड़ी है, तो डेटा को .DCD फ़ाइल में ले जाया जाता है। यदि लॉग बड़ा है, तो डंपिंग ऑपरेशन में समय लग सकता है। ध्यान दें कि लॉग्स डंप के दौरान Mnesia प्रणाली का संचालन जारी है।

डिफ़ॉल्ट रूप से Mnesia या तो लॉग को डंप करता है जब भी लॉग में 100 रिकॉर्ड लिखे गए हैं या जब तीन मिनट बीत चुके हैं। यह दो एप्लिकेशन पैरामीटर -mnesia dump_log_write_threshold WriteOperations और -mnesia dump_log_time_threshold MilliSecs द्वारा नियंत्रित किया -mnesia dump_log_time_threshold MilliSecs

लॉग डंप होने से पहले, फ़ाइल LATEST.LOG का नाम बदलकर PREVIOUS.LOG दिया जाता है, और एक नई LATEST.LOG फ़ाइल बनाई जाती है। एक बार लॉग सफलतापूर्वक डंप हो जाने के बाद, PREVIOUS.LOG फ़ाइल हटा दी जाती है।

लॉग को स्टार्टअप पर भी डंप किया जाता है और जब भी स्कीमा ऑपरेशन किया जाता है।

डेटा की फ़ाइलें

निर्देशिका लिस्टिंग में एक .DAT फ़ाइल भी होती है, जिसमें स्कीमा स्वयं होती है, जो स्कीमा में शामिल schema.DAT है। schema.DAT फ़ाइल। DAT फाइलें अनुक्रमित फाइलें हैं, और इन फ़ाइलों में एक विशिष्ट कुंजी के साथ रिकॉर्ड डालने और खोजने के लिए कुशल है। .DAT फाइलें स्कीमा के लिए और disc_only_copies टेबल के लिए उपयोग की disc_only_copies Mnesia डेटा फाइलें वर्तमान में dets में मानक लाइब्रेरी मॉड्यूल dets में STDLIB

सभी ऑपरेशन जो dets files पर dets जा सकते हैं, वे Mnesia डेटा फ़ाइलों पर भी किए जा सकते हैं। उदाहरण के लिए, dets में फ़ंक्शन dets:traverse/2 , जिसका उपयोग Mnesia फ़ाइल की सामग्री को देखने के लिए किया जा सकता है। हालांकि, यह केवल तब किया जा सकता है जब Mnesia नहीं चल रहा हो। इसलिए, स्कीमा फ़ाइल देखने के लिए, निम्नानुसार करें;

{ok, N} = dets:open_file(schema, [{file, "./schema.DAT"},{repair,false}, 
{keypos, 2}]),
F = fun(X) -> io:format("~p~n", [X]), continue end,
dets:traverse(N, F),
dets:close(N).
चेतावनी

DAT फाइलें हमेशा विकल्प {repair, false} साथ खोली जानी चाहिए। यह सुनिश्चित करता है कि इन फ़ाइलों की स्वचालित रूप से मरम्मत नहीं की जाती है। इस विकल्प के बिना, डेटाबेस असंगत हो सकता है, क्योंकि Mnesia यह मान सकता है कि फाइलें ठीक से बंद थीं। कॉन्फ़िगरेशन पैरामीटर auto_repair बारे में जानकारी के लिए, संदर्भ मैनुअल देखें।

चेतावनी

यह अनुशंसा की जाती है कि Mnesia के चलने के दौरान डेटा फ़ाइलों के साथ छेड़छाड़ नहीं की Mnesia है। निषिद्ध नहीं है, लेकिन Mnesia का व्यवहार अप्रत्याशित है।

disc_copies टेबल को .DCL और .DCD फ़ाइलों के साथ डिस्क पर संग्रहीत किया जाता है, जो मानक disk_log फाइलें हैं।

7.6 स्टार्टअप पर लोड हो रहा टेबल्स

स्टार्टअप पर, Mnesia तालिकाओं को अपने अनुप्रयोगों के लिए सुलभ बनाने के लिए लोड करता है। कभी-कभी Mnesia स्थानीय रूप से रहने वाले सभी तालिकाओं को लोड करने का निर्णय लेता है, और कभी-कभी तालिकाओं तक पहुंच नहीं होती है जब तक Mnesia किसी अन्य नोड से तालिका की प्रतिलिपि नहीं लाता है।

स्टार्टअप पर Mnesia के व्यवहार को समझने के लिए, यह समझना आवश्यक है कि Mnesia किसी अन्य नोड पर Mnesia साथ संपर्क खो Mnesia पर कैसे प्रतिक्रिया करता है। इस स्तर पर, Mnesia एक संचार विफलता और "सामान्य" नोड-डाउन के बीच अंतर नहीं कर सकता है। जब ऐसा होता है, Mnesia मानता है कि दूसरा नोड अब नहीं चल रहा है, जबकि, वास्तव में, नोड्स के बीच संचार विफल हो गया है।

इस स्थिति को दूर करने के लिए, विफल नोड पर तालिकाओं तक पहुँचने वाले चल रहे लेनदेन को पुनः आरंभ करने का प्रयास करें, और लॉग फ़ाइल में mnesia_down प्रविष्टि लिखें।

स्टार्टअप पर, ध्यान दें कि mnesia_down प्रविष्टि के बिना नोड पर रहने वाले सभी तालिकाओं में नए सिरे से प्रतिकृतियां हो सकती हैं। वर्तमान नोड पर Mnesia की समाप्ति के बाद उनके प्रतिकृतियों को अद्यतन किया जा सकता है। नवीनतम अपडेट के साथ पकड़ने के लिए, इन अन्य "ताज़ा" नोड्स में से एक से तालिका की एक प्रति स्थानांतरित करें। यदि आप अशुभ हैं, तो अन्य नोड्स नीचे हो सकते हैं और तालिका की एक नई प्रतिलिपि प्राप्त करने से पहले आपको इनमें से किसी एक नोड पर लोड होने की प्रतीक्षा करनी चाहिए।

इससे पहले कि कोई एप्लिकेशन किसी तालिका पर अपनी पहली पहुंच बना ले, mnesia:wait_for_tables(TabList, Timeout) को यह सुनिश्चित करने के लिए निष्पादित किया जाना चाहिए कि तालिका स्थानीय नोड से सुलभ है। यदि कार्य समय समाप्त हो जाता है, तो एप्लिकेशन स्थानीय प्रतिकृति के लोड को mnesia:force_load_table(Tab) साथ मजबूर करने का विकल्प चुन सकता है mnesia:force_load_table(Tab) और जानबूझकर उन सभी अद्यतनों को खो देते हैं जो स्थानीय नोड के डाउन होने पर अन्य नोड्स पर किए जा सकते हैं। यदि Mnesia ने पहले से ही किसी अन्य नोड पर तालिका लोड की है, या ऐसा करने का इरादा रखता है, तो अनावश्यक असंगति से बचने के लिए उस नोड से तालिका को कॉपी करें।

चेतावनी

केवल एक टेबल को mnesia:force_load_table(Tab) द्वारा लोड किया mnesia:force_load_table(Tab) । चूंकि प्रतिबद्ध लेनदेन में कई तालिकाओं में अपडेट हो सकते हैं, इसलिए मजबूर भार के कारण तालिका असंगत हो सकती है।

किसी तालिका के अनुमत AccessMode को read_only या read_write रूप में परिभाषित किया जा सकता है। यह समारोह के साथ टॉगल किया जा सकता है mnesia:change_table_access_mode(Tab, AccessMode) रनटाइम में mnesia:change_table_access_mode(Tab, AccessMode) read_only तालिकाओं और local_content तालिकाओं को हमेशा स्थानीय रूप से लोड किया जाता है, क्योंकि तालिका को अन्य नोड्स से कॉपी करने की कोई आवश्यकता नहीं है। अन्य तालिकाओं को मुख्य रूप से अन्य नोड्स पर सक्रिय प्रतिकृतियों से दूर से लोड किया जाता है यदि तालिका पहले से ही वहां लोड की गई है, या यदि रनिंग Mnesia ने पहले से ही वहां तालिका लोड करने का फैसला किया है।

स्टार्टअप में, Mnesia मानता है कि इसकी स्थानीय प्रतिकृति सबसे हालिया संस्करण है और डिस्क को तालिका से लोड करता है यदि निम्न में से किसी एक का पता लगाया जाता है:

  • mnesia_down को अन्य सभी नोड्स से लौटाया गया है जो टेबल के डिस्क रेजिडेंट प्रतिकृति को पकड़ते हैं।
  • सभी प्रतिकृतियां ram_copies

यह सामान्य रूप से एक बुद्धिमान निर्णय है, लेकिन यह तब विनाशकारी हो सकता है जब संचार की विफलता के कारण नोड्स को काट दिया गया हो, क्योंकि Mnesia सामान्य टेबल लोड तंत्र संचार विफलताओं का सामना नहीं करता है।

जब Mnesia कई तालिकाओं को लोड करता है, तो डिफ़ॉल्ट लोड ऑर्डर का उपयोग किया जाता है। हालाँकि, लोड क्रम को प्रभावित किया जा सकता है, टेबल के लिए स्पष्ट रूप से संपत्ति load_order को बदलकर, फ़ंक्शन mnesia:change_table_load_order(Tab, LoadOrder) LoadOrder सभी तालिकाओं के लिए डिफ़ॉल्ट 0 , लेकिन इसे किसी भी पूर्णांक पर सेट किया जा सकता है। उच्चतम load_order वाली तालिका को पहले लोड किया गया है। लोड ऑर्डर बदलना उन अनुप्रयोगों के लिए विशेष रूप से उपयोगी है जिन्हें मौलिक तालिकाओं की शीघ्र उपलब्धता सुनिश्चित करने की आवश्यकता है। बड़े परिधीय तालिकाओं में कम लोड ऑर्डर मूल्य होता है, शायद 0 से कम

7.7 संचार विफलता से पुनर्प्राप्ति

ऐसे कई अवसर हैं जब Mnesia यह पता लगा सकता है कि संचार विफलता के कारण नेटवर्क का विभाजन हुआ है, उदाहरण के लिए:

  • Mnesia पहले से ही चालू है और Mnesia नोड्स फिर से संपर्क प्राप्त करते हैं। तब Mnesia दूसरे नोड पर Mnesia से संपर्क करने की कोशिश करता है यह देखने के लिए कि क्या यह भी सोचता है कि नेटवर्क को कुछ समय के लिए विभाजित किया गया है। यदि दोनों नोड्स पर Mnesia ने एक-दूसरे से mnesia_down प्रविष्टियाँ दर्ज की हैं, Mnesia एक सिस्टम ईवेंट बनाता है, जिसे {inconsistent_database, running_partitioned_network, Node} कहा जाता है, जो Mnesia इवेंट हैंडलर और अन्य संभावित ग्राहकों को भेजा जाता है। डिफ़ॉल्ट ईवेंट हैंडलर त्रुटि लकड़हारे को एक त्रुटि रिपोर्ट करता है।
  • यदि Mnesia स्टार्टअप पर पता लगाता है कि दोनों स्थानीय नोड और अन्य नोड को एक-दूसरे से mnesia_down प्राप्त हुआ है, Mnesia एक {inconsistent_database, starting_partitioned_network, Node} Mnesia {inconsistent_database, starting_partitioned_network, Node} सिस्टम ईवेंट उत्पन्न करता है और पिछले आइटम में वर्णित कार्य करता है।

यदि एप्लिकेशन यह पता लगाता है कि संचार विफलता हुई है जो असंगत डेटाबेस का कारण बन सकती है, तो यह फ़ंक्शन mnesia:set_master_nodes(Tab, Nodes) का उपयोग करके mnesia:set_master_nodes(Tab, Nodes) कर सकता है जिसमें से प्रत्येक तालिका को नोड्स लोड किया जा सकता है।

स्टार्टअप पर, Mnesia सामान्य टेबल लोड एल्गोरिथ्म को दरकिनार किया जाता है और तालिका में तालिका के लिए परिभाषित एक मास्टर नोड से लोड किया जाता है, लॉग में संभावित mnesia_down प्रविष्टियों की परवाह किए बिना। Nodes केवल Nodes हो सकते हैं जहां तालिका में एक प्रतिकृति है। यदि Nodes खाली है, तो विशेष तालिका के लिए मास्टर नोड रिकवरी तंत्र को रीसेट किया जाता है और अगले पुनः आरंभ में सामान्य लोड तंत्र का उपयोग किया जाता है।

फ़ंक्शन mnesia:set_master_nodes(Nodes) सभी तालिकाओं के लिए मास्टर नोड सेट करता है। प्रत्येक तालिका के लिए यह अपनी प्रतिकृति नोड्स निर्धारित करता है और mnesia:set_master_nodes(Tab, TabNodes) शुरू mnesia:set_master_nodes(Tab, TabNodes) उन प्रतिकृति नोड्स के साथ, जो Nodes सूची में शामिल हैं (अर्थात, TabNodes तालिका के Nodes और प्रतिकृति नोड्स का चौराहा है)। यदि चौराहा खाली है, तो विशेष तालिका के लिए मास्टर नोड रिकवरी तंत्र को रीसेट किया जाता है और अगले पुनः आरंभ में सामान्य लोड तंत्र का उपयोग किया जाता है।

फ़ंक्शंस mnesia:system_info(master_node_tables) और mnesia:table_info(Tab, master_nodes) का उपयोग संभावित मास्टर नोड्स के बारे में जानकारी प्राप्त करने के लिए किया जा सकता है।

यह निर्धारित करना कि संचार विफलता के बाद कौन सा डेटा रखना है, Mnesia के दायरे से बाहर है। एक दृष्टिकोण यह निर्धारित करना है कि किस "द्वीप" में अधिकांश नोड हैं। महत्वपूर्ण तालिकाओं के लिए विकल्प {majority,true} का उपयोग करना यह सुनिश्चित करने का एक तरीका हो सकता है कि नोड्स जो "बहुमत द्वीप" का हिस्सा नहीं हैं, वे इन तालिकाओं को अपडेट नहीं कर सकते। ध्यान दें कि यह अल्पसंख्यक नोड्स पर सेवा में कमी का गठन करता है। यह उच्च स्थिरता की गारंटी के पक्ष में एक व्यापार होगा।

फंक्शन mnesia:force_load_table(Tab) का उपयोग टेबल को लोड करने के लिए किया जा सकता है, भले ही टेबल लोड तंत्र सक्रिय हो।

7.8 लेन-देन की वसूली

एक Mnesia तालिका एक या अधिक नोड्स पर निवास कर सकती है। जब एक तालिका अपडेट की जाती है, तो Mnesia सुनिश्चित करता है कि अपडेट उन सभी नोड्स पर दोहराए जाएं जहां तालिका निवास करती है। यदि एक प्रतिकृति अप्राप्य है (उदाहरण के लिए, एक अस्थायी नोड-डाउन के कारण), Mnesia प्रतिकृति बाद में करता है।

नोड पर जहां आवेदन शुरू किया जाता है, वहां एक लेनदेन समन्वयक प्रक्रिया होती है। यदि लेन-देन वितरित किया जाता है, तो अन्य सभी नोड्स पर एक लेनदेन भागीदार प्रक्रिया भी होती है, जहां प्रतिबद्ध कार्य करने की आवश्यकता होती है।

आंतरिक रूप से Mnesia कई प्रतिबद्ध प्रोटोकॉल का उपयोग करता है। चयनित प्रोटोकॉल उस तालिका पर निर्भर करता है जिसे लेनदेन में अपडेट किया गया है। यदि सभी शामिल तालिकाओं को सममित रूप से दोहराया गया है (अर्थात, उनके पास समान ram_nodes , disc_nodes , और disc_only_nodes वर्तमान में समन्वयक नोड से सुलभ हैं), एक हल्का लेनदेन प्रतिबद्ध प्रोटोकॉल का उपयोग किया जाता है।

लेन-देन समन्वयक और उसके प्रतिभागियों को विनिमय करने के लिए आवश्यक संदेशों की संख्या कम है, क्योंकि Mnesia टेबल लोड तंत्र लेनदेन वसूली का ख्याल रखता है यदि प्रतिबद्ध प्रोटोकॉल बाधित हो जाता है। चूंकि सभी शामिल तालिकाओं को सममित रूप से दोहराया गया है, इसलिए असफल नोड के स्टार्टअप पर उसी नोड से शामिल तालिकाओं को लोड करके लेनदेन स्वचालित रूप से पुनर्प्राप्त किया जाता है। इससे कोई फर्क नहीं पड़ता कि जब तक एसीआईडी ​​संपत्तियों को सुनिश्चित किया जा सकता है तब तक लेनदेन किया गया था या समाप्त किया गया था। लाइटवेट कमिट प्रोटोकॉल गैर-अवरोधक है, अर्थात, जीवित प्रतिभागी और उनके समन्वयक लेन-देन को समाप्त करते हैं, भले ही कोई नोड प्रतिबद्ध प्रोटोकॉल के बीच में दुर्घटनाग्रस्त हो।

यदि एक गंदा ऑपरेशन के बीच में एक नोड नीचे जाता है, तो टेबल लोड तंत्र यह सुनिश्चित करता है कि अद्यतन सभी प्रतिकृतियों पर किया जाता है, या कोई भी नहीं। दोनों अतुल्यकालिक गंदे अपडेट और तुल्यकालिक गंदे अपडेट हल्के रिकवरी के रूप में एक ही रिकवरी सिद्धांत का उपयोग करते हैं।

यदि लेन-देन में विषम रूप से प्रतिकृति तालिकाओं या स्कीमा तालिका के अपडेट शामिल होते हैं, तो एक हेवीवेट प्रतिबद्ध प्रोटोकॉल का उपयोग किया जाता है। यह प्रोटोकॉल लेन-देन को समाप्त कर सकता है, भले ही तालिकाओं को कैसे दोहराया जाए। हेवीवेट लेन-देन का विशिष्ट उपयोग तब होता है जब एक प्रतिकृति को एक नोड से दूसरे में ले जाना होता है। फिर सुनिश्चित करें कि प्रतिकृति या तो पूरी तरह से स्थानांतरित हो गई है या इसे छोड़ दिया गया है। दोनों नोड्स पर प्रतिकृतियों के साथ या बिना नोड पर किसी भी स्थिति में कभी भी समाप्त न करें। भले ही एक नोड प्रतिबद्ध प्रोटोकॉल के बीच में दुर्घटनाग्रस्त हो जाता है, लेनदेन को परमाणु होने की गारंटी दी जानी चाहिए। हेवीवेट कमिट प्रोटोकॉल में लेन-देन समन्वयक और उसके प्रतिभागियों के बीच हल्के प्रोटोकॉल की तुलना में अधिक संदेश शामिल हैं, और यह स्टार्टअप पर पुनर्प्राप्ति कार्य को समाप्त करने या काम करने के लिए करता है।

हेवीवेट कमिट प्रोटोकॉल भी नॉन-ब्लॉकिंग है, जो जीवित प्रतिभागियों और उनके समन्वयक को लेनदेन को समाप्त करने की अनुमति देता है (भले ही एक नोड प्रतिबद्ध प्रोटोकॉल के बीच में दुर्घटनाग्रस्त हो जाए)। जब स्टार्टअप पर एक नोड विफल हो जाता है, Mnesia लेनदेन के परिणाम को निर्धारित करता है और इसे ठीक करता है। लाइटवेट प्रोटोकॉल, हेवीवेट प्रोटोकॉल और गंदे अपडेट, सही हेवीवेट लेनदेन रिकवरी निर्णय लेने के लिए अन्य नोड्स पर निर्भर होते हैं।

यदि Mnesia कुछ ऐसे नोड्स पर शुरू नहीं हुआ है जो लेनदेन में शामिल हैं और न तो स्थानीय नोड और न ही पहले से चल रहे नोड्स में से कोई भी लेन-देन के परिणाम को जानता है, Mnesia डिफ़ॉल्ट रूप से प्रतीक्षा करता है। सबसे खराब स्थिति में, अन्य सभी शामिल नोड्स शुरू होना चाहिए इससे पहले कि Mnesia लेनदेन के बारे में सही निर्णय ले सके और अपने स्टार्टअप को खत्म कर सके।

इस प्रकार, Mnesia (एक नोड पर) एक डबल फॉल्ट होने पर लटका सकती है, अर्थात, जब दो नोड एक साथ दुर्घटनाग्रस्त हो जाते हैं और एक शुरू करने का प्रयास करता है जब दूसरा शुरू करने से इनकार करता है, उदाहरण के लिए, एक हार्डवेयर त्रुटि के कारण।

एक लेनदेन वसूली निर्णय के साथ प्रतिक्रिया करने के लिए Mnesia अन्य नोड्स के लिए इंतजार कर रहा है कि अधिकतम समय निर्दिष्ट किया जा सकता है। कॉन्फ़िगरेशन पैरामीटर max_wait_for_decision infinity लिए चूक करता है, जो पहले बताए अनुसार अनिश्चित रूप से लटका हुआ हो सकता है। हालांकि, यदि पैरामीटर एक निश्चित समय अवधि (उदाहरण के लिए, तीन मिनट) पर सेट किया गया है, तो Mnesia तब लेनदेन वसूली निर्णय लागू करता है, यदि आवश्यक हो, तो Mnesia को अपनी स्टार्टअप प्रक्रिया के साथ जारी रखने की अनुमति देता है।

लागू लेन-देन पुनर्प्राप्ति निर्णय का नकारात्मक पक्ष यह है कि निर्णय गलत हो सकता है, क्योंकि अन्य नोड्स से पुनर्प्राप्ति निर्णयों के बारे में अपर्याप्त जानकारी है। यह एक असंगत डेटाबेस में परिणाम हो सकता है जहां Mnesia ने कुछ नोड्स पर लेनदेन किया है, लेकिन इसे दूसरों पर समाप्त कर दिया है।

सौभाग्यशाली मामलों में, असंगति केवल एक विशिष्ट अनुप्रयोग से संबंधित तालिकाओं में दिखाई देती है। हालांकि, यदि लागू लेनदेन वसूली निर्णय के कारण एक स्कीमा लेनदेन असंगत रूप से पुनर्प्राप्त किया जाता है, तो असंगति के प्रभाव घातक हो सकते हैं। हालांकि, यदि उच्च प्राथमिकता स्थिरता के बजाय उपलब्धता है, तो यह जोखिम के लायक हो सकता है।

यदि Mnesia एक असंगत लेनदेन निर्णय का पता लगाता है, तो एक {inconsistent_database, bad_decision, Node} को हल करने के लिए एप्लिकेशन को फॉलबैक या अन्य उपयुक्त उपायों को स्थापित करने का मौका देने के लिए एक {inconsistent_database, bad_decision, Node} सिस्टम ईवेंट उत्पन्न होता है। Mnesia ईवेंट हैंडलर का डिफ़ॉल्ट व्यवहार वैसा ही है जैसे कि विभाजन नेटवर्क के परिणामस्वरूप डेटाबेस असंगत हो गया (जैसा कि पहले वर्णित है)।

7.9 बैकअप, रिस्टोर, फॉलबैक और डिजास्टर रिकवरी

निम्न कार्यों का उपयोग डेटा का बैकअप लेने के लिए, बैकबैक के रूप में, और डिजास्टर रिकवरी के लिए किया जाता है:

  • mnesia:backup_checkpoint(Name, Opaque, [Mod]) चेकपॉइंट में शामिल तालिकाओं का एक बैकअप करता है।
  • mnesia:backup(Opaque, [Mod]) एक नया चेकपॉइंट सक्रिय करता है जो सभी Mnesia टेबल को कवर करता है और एक बैकअप करता है। यह अतिरेक की अधिकतम डिग्री के साथ किया जाता है (फ़ंक्शन mnesia:activate_checkpoint(Args) भी देखें mnesia:activate_checkpoint(Args) , {max, MaxTabs} and {min, MinTabs})
  • mnesia:traverse_backup(Source, [SourceMod,] Target, [TargetMod,] Fun, Acc) का उपयोग किसी मौजूदा बैकअप को पढ़ने, मौजूदा एक से बैकअप बनाने, या एक प्रकार के मीडिया से दूसरे में बैकअप की प्रतिलिपि बनाने के लिए किया जा सकता है।
  • mnesia:uninstall_fallback() पहले से स्थापित फालबैक फ़ाइलों को हटा देता है।
  • mnesia:restore(Opaque, Args) पिछले बैकअप से तालिकाओं के एक सेट को पुनर्स्थापित करता है।
  • mnesia:install_fallback(Opaque, [Mod]) को Mnesia और पुनः लोड करने के लिए कॉन्फ़िगर किया जा सकता है डेटा टेबल, और संभवतः एक मौजूदा बैकअप से स्कीमा टेबल। यह फ़ंक्शन आमतौर पर आपदा वसूली उद्देश्यों के लिए उपयोग किया जाता है, जब डेटा या स्कीमा टेबल दूषित होते हैं।

इन कार्यों को निम्नलिखित वर्गों में समझाया गया है। mnesia:activate_checkpoint(Args) भी देखें, जो mnesia:activate_checkpoint(Args) को सक्रिय और निष्क्रिय करने के लिए उपयोग किए जाने वाले दो कार्यों का वर्णन करता है।

बैकअप

बैकअप संचालन निम्न कार्यों के साथ किया जाता है:

डिफ़ॉल्ट रूप से, बैकअप मीडिया के लिए वास्तविक पहुंच मॉड्यूल mnesia_backup माध्यम से पढ़ी और लिखी जाती है। वर्तमान में mnesia_backup को मानक लाइब्रेरी मॉड्यूल disc_log साथ लागू किया गया है। हालाँकि, आप अपने स्वयं के मॉड्यूल को mnesia_backup के समान इंटरफ़ेस के साथ mnesia_backup और mnesia_backup को कॉन्फ़िगर कर Mnesia ताकि वैकल्पिक मॉड्यूल बैकअप मीडिया के लिए वास्तविक पहुंच का प्रदर्शन करे। उपयोगकर्ता इसलिए मीडिया पर बैकअप डाल सकता है कि Mnesia बारे में नहीं जानता है, संभवतः मेजबानों पर जहां Mnesia नहीं चल रहा है। इस उद्देश्य के लिए कॉन्फ़िगरेशन पैरामीटर -mnesia backup_module <module> उपयोग करें।

बैकअप के लिए स्रोत एक सक्रिय चेकपॉइंट है। बैकअप फ़ंक्शन mnesia:backup_checkpoint(Name, Opaque,[Mod]) का सबसे अधिक उपयोग किया जाता है और ok या {error,Reason} । इसके निम्न तर्क हैं:

  • Name एक सक्रिय चेकपॉइंट का Name है। चौकियों में तालिका के नामों को शामिल करने के तरीके के विवरण के लिए, फ़ंक्शन mnesia:activate_checkpoint(ArgList) देखें mnesia:activate_checkpoint(ArgList) mnesia:activate_checkpoint(Args) में mnesia:activate_checkpoint(ArgList)
  • Opaque Mnesia इस तर्क की व्याख्या नहीं करता है, लेकिन इसे बैकअप मॉड्यूल में भेज दिया जाता है। Mnesia डिफ़ॉल्ट बैकअप मॉड्यूल mnesia_backup स्थानीय फ़ाइल नाम के रूप में इस तर्क की व्याख्या करता है।
  • Mod एक वैकल्पिक बैकअप मॉड्यूल का नाम है।

फ़ंक्शन mnesia:backup(Opaque [,Mod]) एक नया चेकपॉइंट सक्रिय करता है जो सभी Mnesia तालिकाओं को अतिरेक की अधिकतम डिग्री के साथ कवर करता है और बैकअप करता है। अधिकतम अतिरेक का मतलब है कि प्रत्येक तालिका प्रतिकृति में एक चेकपॉइंट अनुचर है। प्रॉपर्टी local_contents साथ टेबल्स का बैकअप लिया जाता है क्योंकि वे वर्तमान नोड पर दिखते हैं।

आप एक बैकअप पर पुनरावृति कर सकते हैं, या तो इसे एक नए बैकअप में बदल सकते हैं, या केवल इसे पढ़ सकते हैं। फ़ंक्शन mnesia:traverse_backup(Source, [SourceMod,] Target, [TargetMod,] Fun, Acc) , जो सामान्य रूप से {ok, LastAcc} , इन दोनों उद्देश्यों के लिए उपयोग किया जाता है।

ट्रैवर्सल शुरू होने से पहले, स्रोत बैकअप मीडिया को SourceMod:open_read(Source) साथ खोला जाता है, और लक्ष्य बैकअप मीडिया को TargetMod:open_write(Target) साथ खोला जाता है। तर्क इस प्रकार हैं:

  • SourceMod और SourceMod मॉड्यूल नाम हैं।
  • Source और Target अपारदर्शी डेटा होते हैं जो विशेष रूप से मॉड्यूल द्वारा उपयोग किए जाते हैं SourceMod और SourceMod बैकअप medias को आरंभ करने के लिए।
  • Acc एक प्रारंभिक संचायक मान है।
  • Fun(BackupItems, Acc) बैकअप में प्रत्येक आइटम पर लागू होता है। फन को एक टपल {ValGoodBackupItems, NewAcc} वापस करना चाहिए, जहां ValidBackupItems वैध बैकअप आइटमों की एक सूची है। NewAcc एक नया संचायक मान है। ValidBackupItems को फ़ंक्शन के साथ लक्ष्य बैकअप के लिए लिखा जाता है ValidBackupItems TargetMod:write/2
  • LastAcc अंतिम संचायक मान है, अर्थात अंतिम NewAcc मान जो Fun द्वारा वापस किया गया था।

इसके अलावा, स्रोत बैकअप का केवल-पढ़ने योग्य एक लक्ष्य बैकअप अद्यतन किए बिना किया जा सकता है। यदि TargetMod==read_only , कोई लक्ष्य बैकअप एक्सेस नहीं है।

SourceMod और SourceMod को अलग-अलग मॉड्यूल में सेट करके, एक बैकअप को एक बैकअप मीडिया से दूसरे में कॉपी किया जा सकता है।

मान्य BackupItems निम्नलिखित tuples हैं:

  • {schema, Tab} हटाए जाने वाली तालिका निर्दिष्ट करता है।
  • {schema, Tab, CreateList} एक तालिका बनाने के लिए निर्दिष्ट करता है। CreateList बारे में अधिक जानकारी के लिए, mnesia:create_table/2 देखें mnesia:create_table/2
  • {Tab, Key} हटाए जाने के लिए रिकॉर्ड की पूरी पहचान निर्दिष्ट करता है।
  • {Record} डाला जाने वाला रिकॉर्ड निर्दिष्ट करता है। यह पहली फील्ड के रूप में Tab साथ टपल हो सकता है। ध्यान दें कि रिकॉर्ड नाम टेबल के नाम पर सेट है, भले ही record_name किस पर सेट हो।

बैकअप डेटा को दो खंडों में विभाजित किया गया है। पहले खंड में स्कीमा से संबंधित जानकारी है। सभी स्कीमा-संबंधित आइटम ट्यूपल्स हैं जहां पहला फ़ील्ड परमाणु स्कीमा के बराबर होता है। दूसरा खंड रिकॉर्ड सेक्शन है। स्कीमा रिकॉर्ड को अन्य रिकॉर्ड के साथ नहीं मिलाया जा सकता है और सभी स्कीमा रिकॉर्ड को पहले बैकअप में स्थित होना चाहिए।

स्कीमा स्वयं एक तालिका है और संभवतः बैकअप में शामिल है। प्रत्येक नोड जहां स्कीमा टेबल रहता है उसे db_node माना जाता है।

निम्न उदाहरण से पता चलता है कि कैसे mnesia:traverse_backup एक बैकअप फ़ाइल में db_node का नाम बदलने के लिए mnesia:traverse_backup का उपयोग किया जा सकता है:

change_node_name(Mod, From, To, Source, Target) ->
    Switch =
        fun(Node) when Node == From -> To;
           (Node) when Node == To -> throw({error, already_exists});
           (Node) -> Node
        end,
    Convert =
        fun({schema, db_nodes, Nodes}, Acc) ->
                {[{schema, db_nodes, lists:map(Switch,Nodes)}], Acc};
           ({schema, version, Version}, Acc) ->
                {[{schema, version, Version}], Acc};
           ({schema, cookie, Cookie}, Acc) ->
                {[{schema, cookie, Cookie}], Acc};
           ({schema, Tab, CreateList}, Acc) ->
                Keys = [ram_copies, disc_copies, disc_only_copies],
                OptSwitch =
                    fun({Key, Val}) ->
                            case lists:member(Key, Keys) of
                                true -> {Key, lists:map(Switch, Val)};
                                false-> {Key, Val}
                            end
                    end,
                {[{schema, Tab, lists:map(OptSwitch, CreateList)}], Acc};
           (Other, Acc) ->
                {[Other], Acc}
        end,
    mnesia:traverse_backup(Source, Mod, Target, Mod, Convert, switched).

view(Source, Mod) ->
    View = fun(Item, Acc) ->
                   io:format("~p.~n",[Item]),
                   {[Item], Acc + 1}
           end,
    mnesia:traverse_backup(Source, Mod, dummy, read_only, View, 0).

पुनर्स्थापित

Mnesia को फिर से शुरू किए बिना एक बैकअप से तालिकाओं को ऑनलाइन बहाल किया जा सकता है। एक पुनर्स्थापना समारोह mnesia:restore(Opaque, Args) साथ किया जाता है mnesia:restore(Opaque, Args) , जहां Args में निम्नलिखित Args हो सकते हैं:

  • {module,Mod} । बैकअप मीडिया को एक्सेस करने के लिए बैकअप मॉड्यूल Mod का उपयोग किया जाता है। यदि छोड़ा गया है, तो डिफ़ॉल्ट बैकअप मॉड्यूल का उपयोग किया जाता है।
  • {skip_tables, TableList} , जहां TableList टेबल की एक सूची है, जिसे बैकअप से पढ़ा नहीं जाना है।
  • {clear_tables, TableList} , जहां TableList तालिकाओं की एक सूची है, जिसे बैकअप से रिकॉर्ड डालने से पहले साफ किया जाना है। यही है, तालिकाओं को पुनर्स्थापित करने से पहले तालिकाओं में सभी रिकॉर्ड हटा दिए जाते हैं। तालिकाओं के बारे में स्कीमा जानकारी बैकअप से साफ़ या पढ़ी नहीं गई है।
  • {keep_tables, TableList} , जहां TableList तालिकाओं की एक सूची है, जिसे बैकअप से रिकॉर्ड डालने से पहले साफ नहीं किया जाना है। यही है, बैकअप में रिकॉर्ड तालिका में रिकॉर्ड में जोड़े जाते हैं। तालिकाओं के बारे में स्कीमा जानकारी बैकअप से साफ़ या पढ़ी नहीं गई है।
  • {recreate_tables, TableList} तालिका सूची {recreate_tables, TableList} , जहां तालिका सूची तालिका की एक सूची है, जिसे बैकअप से रिकॉर्ड किए जाने से पहले फिर से बनाया जाना है। तालिकाओं को पहले हटा दिया जाता है और फिर बैकअप से स्कीमा जानकारी के साथ बनाया जाता है। बैकअप में सभी नोड्स को चालू करने की आवश्यकता है।
  • {default_op, Operation} , जहाँ Operation एक है, skip_tables , clear_tables , keep_tables , या recreate_tables keep_tables clear_tables Operation से एक है। डिफ़ॉल्ट ऑपरेशन निर्दिष्ट करता है कि कौन से ऑपरेशन को उन बैकअप से तालिकाओं पर उपयोग किया जाना है जो पिछली सूचियों में से किसी में निर्दिष्ट नहीं हैं। यदि छोड़ा गया है, तो ऑपरेशन clear_tables का उपयोग किया जाता है।

तर्क Opaque बैकअप मॉड्यूल के लिए भेजा जाता है। यह सफल होने पर {atomic, TabList} वापस लौटता है या कोई त्रुटि होने पर {atomic, TabList} {aborted, Reason} देता है। TabList बहाल तालिकाओं की एक सूची है। बहाल किए गए टेबल्स पुनर्स्थापना कार्रवाई के दौरान राइट-लॉक हैं। हालांकि, इसके कारण होने वाले किसी भी लॉक संघर्ष की परवाह किए बिना, एप्लिकेशन पुनर्स्थापना कार्रवाई के दौरान अपना काम जारी रख सकते हैं।

पुनर्स्थापना एकल लेनदेन के रूप में की जाती है। यदि डेटाबेस बड़ा है, तो इसे हमेशा ऑनलाइन बहाल नहीं किया जा सकता है। पुराने डेटाबेस को फ़ॉलबैक स्थापित करके पुनर्स्थापित किया जाना चाहिए, इसके बाद पुनः आरंभ करें।

मैदान छोड़ना

फ़ंक्शन mnesia:install_fallback(Opaque, [Mod]) बैकबैक के रूप में बैकअप स्थापित करता है। यह Mod बैकअप मीडिया का उपयोग करने के लिए बैकअप मॉड्यूल , या डिफ़ॉल्ट बैकअप मॉड्यूल का उपयोग करता है। ok यदि सफल होता है, या {error, Reason} कोई त्रुटि होती है , तो फ़ंक्शन लौटता है।

फॉलबैक स्थापित करना एक वितरित ऑपरेशन है, जो केवल सभी पर किया जाता है db_nodes । अगली बार सिस्टम शुरू होने पर फ़ॉलबैक डेटाबेस को पुनर्स्थापित करता है। यदि एक Mnesia फॉलबैक के साथ एक नोड स्थापित करता है कि Mnesia दूसरे नोड पर मृत्यु हो गई है, तो यह बिना शर्त के ही समाप्त हो जाता है।

जब सिस्टम अपग्रेड किया जाता है, तो फ़ॉलबैक का उपयोग आमतौर पर किया जाता है। एक प्रणाली में आम तौर पर नए सॉफ़्टवेयर संस्करणों की स्थापना शामिल होती है, और Mnesia टेबल अक्सर नए लेआउट में बदल जाते हैं। यदि सिस्टम अपग्रेड के दौरान क्रैश हो जाता है, तो यह अत्यधिक संभावना है कि पुराने एप्लिकेशन को फिर से इंस्टॉल करना आवश्यक है, और डेटाबेस को इसकी पिछली स्थिति में बहाल करना। यह तब किया जा सकता है जब सिस्टम अपग्रेड शुरू होने से पहले बैकअप को एक बैकअप के रूप में प्रदर्शित और स्थापित किया जाता है।

यदि सिस्टम अपग्रेड विफल रहता है, तो पुराने डेटाबेस को पुनर्स्थापित करने के लिए Mnesia सभी db_nodes को फिर से शुरू करना होगा । सफल स्टार्टअप के बाद फ़ॉलबैक स्वचालित रूप से हटा दिया जाता है। mnesia:uninstall_fallback() एक सफल सिस्टम अपग्रेड के बाद फॉलबैक को हटाने के लिए फ़ंक्शन का उपयोग किया जा सकता है। फिर से, यह एक वितरित ऑपरेशन है जो या तो सभी db_nodes या किसी पर नहीं किया जाता है। फालबैक की स्थापना और विस्थापन दोनों के लिए एर्लैंग को सभी पर सक्रिय होना आवश्यक है db_nodes , लेकिन इससे कोई फर्क नहीं पड़ता कि Mnesia क्या चल रहा है या नहीं।

आपदा बहाली

बिजली की विफलता के परिणामस्वरूप प्रणाली असंगत हो सकती है। UNIX सुविधा fsck संभवतः फ़ाइल सिस्टम की मरम्मत कर सकती है, लेकिन इस बात की कोई गारंटी नहीं है कि फ़ाइल सामग्री सुसंगत है।

यदि Mnesia पता चलता है कि किसी फ़ाइल को ठीक से बंद नहीं किया गया है, संभवतः एक बिजली की विफलता के परिणामस्वरूप, यह खराब फ़ाइल को समान तरीके से ठीक करने की कोशिश करता है। डेटा खो सकता है, लेकिन Mnesia डेटा असंगत होने पर भी पुनः आरंभ किया जा सकता है। कॉन्फ़िगरेशन पैरामीटर -mnesia auto_repair <bool> का उपयोग Mnesia स्टार्टअप पर व्यवहार को नियंत्रित करने के लिए किया जा सकता है । यदि <bool> मान है true , Mnesia तो फ़ाइल को सुधारने का प्रयास करता है। यदि <bool> मान है false , Mnesia तो यह संदिग्ध फ़ाइल का पता लगाने पर पुनरारंभ नहीं करता है। यह कॉन्फ़िगरेशन पैरामीटर लॉग फ़ाइलों, DAT फ़ाइलों और डिफ़ॉल्ट बैकअप मीडिया की मरम्मत व्यवहार को प्रभावित करता है ।

कॉन्फ़िगरेशन पैरामीटर -mnesia dump_log_update_in_place <bool> फ़ंक्शन के सुरक्षा स्तर को नियंत्रित करता है mnesia:dump_log() डिफ़ॉल्ट रूप से, फ़ाइलों Mnesia में लेनदेन लॉग को सीधे डंप DAT करता है। यदि डंप के दौरान बिजली की विफलता होती है, तो यह बेतरतीब ढंग से एक्सेस की गई DAT फ़ाइलों के भ्रष्ट होने का कारण बन सकता है। यदि पैरामीटर सेट है false , Mnesia तो DAT फ़ाइलों को कॉपी करें और डंप को नई अस्थायी फ़ाइलों को लक्षित करें। यदि डंप सफल होता है, तो अस्थायी फ़ाइलों का नाम बदलकर उनके सामान्य DAT प्रत्यय रख दिए जाते हैं। डेटा फ़ाइलों में अपरिवर्तनीय विसंगतियों की संभावना इस रणनीति के साथ बहुत कम हो जाती है। हालाँकि, लेन-देन लॉग की वास्तविक डंपिंग काफी धीमी हो जाती है। सिस्टम डिजाइनर को यह तय करना होगा कि गति या सुरक्षा उच्च प्राथमिकता है या नहीं।

disc_only_copies स्टार्टअप पर लॉग फ़ाइल के प्रारंभिक डंप के दौरान इस प्रकार के प्रतिकृतियां केवल इस पैरामीटर से प्रभावित होती हैं। बहुत उच्च आवश्यकताओं वाले अनुप्रयोगों को डिजाइन करते समय, disc_only_copies तालिकाओं का उपयोग नहीं करना उचित होगा । इसका कारण सामान्य ऑपरेटिंग सिस्टम फ़ाइलों की यादृच्छिक अभिगम प्रकृति है। यदि कोई नोड बिजली की विफलता जैसे कारण के लिए नीचे जाता है, तो ये फ़ाइलें दूषित हो सकती हैं क्योंकि वे ठीक से बंद नहीं हैं। DAT फ़ाइलों के लिए disc_only_copies प्रति लेन-देन के आधार पर अपडेट किया जाता है।

यदि कोई आपदा होती है और Mnesia डेटाबेस दूषित हो जाता है, तो इसे बैकअप से फिर से बनाया जा सकता है। इसे अंतिम उपाय के रूप में देखें, क्योंकि बैकअप में पुराना डेटा है। डेटा उम्मीद के अनुरूप है, लेकिन डेटाबेस को पुनर्स्थापित करने के लिए एक पुराने बैकअप का उपयोग करने पर डेटा निश्चित रूप से खो जाता है।

Original text