अजगर में फायरबर्ड के लिए मल्टीमास्टर प्रतिकृति

एक बार फायरबर्ड DBMS के तहत चलने वाले दो डेटाबेस को सिंक्रोनाइज़ करने का काम था। स्थिति संक्षेप में ऐसी ही है।

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

अंदर से बाहर काम करते हैं

शुरुआत के लिए, सभी डेटा को दोहराया नहीं जाएगा। सर्विस टेबल हैं, लॉग की टेबल हैं, रजिस्ट्रियां और जर्नल्स हैं जो स्वचालित रूप से प्राथमिक दस्तावेज़ीकरण के टेबल से उत्पन्न होते हैं - उन्हें बाहर रखा जाना चाहिए। इसलिए पहले हम तय करते हैं कि हम क्या सिंक्रनाइज़ करेंगे। ऐसा करने के लिए, तालिका RPL_TABLES में सिंक्रनाइज़ तालिकाओं और सेवा जानकारी के नाम शामिल हैं - चाहे सभी फ़ील्ड को दोहराने की आवश्यकता हो, और क्या यह तालिका एक दस्तावेज़ शीर्षलेख है (यह डेटाबेस के तर्क को प्रभावित करता है)। क्रमशः तालिका RPL_FIELDS में, उन तालिकाओं के फ़ील्ड नाम जिन्हें पूरी तरह से सिंक्रनाइज़ करने की आवश्यकता नहीं है, संग्रहीत हैं।

इसके बाद, तीन प्रक्रियाओं को लिखा गया था, जो इस जानकारी के आधार पर, निर्दिष्ट तालिकाओं में सभी परिवर्तनों को लॉग करने के लिए आवश्यक ट्रिगर उत्पन्न करते हैं। उनमें से दो - RPL_ALLFIELDS और RPL_SOMEFIELDS - ट्रिगर उत्पन्न करते हैं, जो बदले में अन्य प्रतिकृति प्रतिभागियों द्वारा निष्पादन के लिए sql क्वेरी उत्पन्न करते हैं। उन्हें लिखते समय सबसे मुश्किल हिस्सा उद्धरणों की संख्या में गलती नहीं करना था :) तीसरा - RPL_INSTALL - उपरोक्त सेटिंग्स तालिकाओं का विश्लेषण करता है और उनके लिए आवश्यक प्रक्रिया शुरू करता है। इन प्रक्रियाओं को लिखते समय, हमने निष्पादन कथन / निष्पादित ब्लॉक का एक गुच्छा का उपयोग किया, जो अन्य बातों के अलावा, आपको प्रक्रिया के भीतर से डेटाबेस मेटाडेटा को बदलने की अनुमति देता है।

नतीजतन, कार्यक्रम के उपयोगकर्ताओं द्वारा किए गए सभी परिवर्तन RPL_LOG तालिका में सहेजे जाते हैं, भले ही वे (उपयोगकर्ता) कहाँ, कब और कैसे (उन्हें) किए गए हों। अब चलो कई डेटाबेस के बीच बातचीत पर चलते हैं।

"स्टार" स्कीम के अनुसार सिंक्रोनाइज़ेशन किया जाता है: प्रत्येक डेटाबेस सिंक्रोनाइज़ेशन सर्वर से जुड़ा होता है, अंतिम सिंक्रोनाइज़ेशन सत्र के क्षण से उसमें होने वाले परिवर्तनों को अपलोड करता है, अन्य क्लाइंट डेटाबेस से परिवर्तन के सेट प्राप्त करता है, उन्हें खुद पर लागू करता है और उन्हें समाप्त कर दिया जाता है। सर्वर अपने आप में एक ही तरह से काम करता है, एक क्लाइंट होने के नाते।
यह विस्तार से होता है। प्रत्येक क्लाइंट डेटाबेस में RPL_SESSIONS तालिका होती है। एक प्रतिकृति सत्र की शुरुआत में, यह इसे एक नए सत्र की शुरुआत में चिह्नित करता है, जिसके पहचानकर्ता को प्रत्येक उत्पन्न अनुरोध के लिए RPL_LOG तालिका में संग्रहीत किया जाता है। उसके बाद, RPL_LOG टेबल से, पिछले सत्र के सभी संचित अनुरोधों का चयन किया जाता है, एक फ़ाइल के लिए लिखा जाता है (समस्याओं के मामले में और अधिक विश्लेषण के लिए, और बस मामले में) और RPL_BLOB तालिका में सर्वर पर डाला जाता है। ब्लॉब के साथ, डेटाबेस पहचानकर्ता और सत्र संख्या लिखी जाती है। इसके अलावा अन्य डेटाबेस से इसी तरह की बूँदें सर्वर से बाहर पंप की जाती हैं और उनके डेटाबेस पर लागू होती हैं। उसके बाद, पड़ोसी डेटाबेस में से प्रत्येक के लिए अंतिम सफलतापूर्वक सिंक्रनाइज़ किए गए सत्र की संख्या के बारे में जानकारी क्लाइंट के RPL_DATABASES तालिका में लिखी जाती है और (फिर, समस्या विश्लेषण के मामले में) आधार के पहचानकर्ता, बूँद, सत्र और सिंक्रनाइज़ेशन समय RPL_RECEIVED तालिका में लिखे जाते हैं।

बाहर काम करते हैं

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

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

उन सर्वरों के बीच सुरक्षा सुनिश्चित करने के लिए जिन पर डेटाबेस चल रहे हैं, एक वीपीएन उठाया गया है और सभी काम केवल इसके माध्यम से किया जाता है। इसके अलावा, डेटाबेस में प्रतिकृति के लिए एक अलग उपयोगकर्ता बनाया गया है, जिसने केवल RPL_ * तालिकाओं के अधिकार पढ़े हैं।

पूर्णता

फिलहाल, प्रतिकृति स्थिति को सही ढंग से हल करने में सक्षम नहीं है जब एक ही डेटा अलग-अलग डेटाबेस में एक साथ बदल रहा है। मौजूदा दृष्टिकोण के साथ, दो डेटाबेस केवल "सूचना का आदान-प्रदान" करते हैं: प्रतिकृति के बाद पहले डेटाबेस में, दूसरे से डेटा सहेजा जाएगा, दूसरे में, क्रमशः, जो पहले दर्ज किए गए थे। अब इस तरह का प्रतिबंध हमारे लिए महत्वहीन है, क्योंकि विभिन्न डेटाबेस में समान डेटा को एक व्यक्ति द्वारा एक नियम के रूप में, अत्यंत दुर्लभ रूप से संपादित किया जाता है। इसलिए जब कोई दुकान से दुकान पर जाता है, तो सबसे अधिक संभावना है कि वे पहले से ही अगले प्रतिकृति सत्र को पूरा करेंगे। लेकिन, फिर भी, एक समस्या है, और इसे हल किया जाएगा।

परिणाम

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

* वास्तव में, RPL_TABLES तालिका में एकमात्र बाइंडिंग is_docheader विकल्प है, जिसका तात्पर्य है कि संबंधित तालिका में एक कमिटेड फ़ील्ड की मौजूदगी और एक क्वेरी उत्पन्न करना जब केवल यह फ़ील्ड बदलता है, टेबल में किसी भी अन्य परिवर्तन को अनदेखा करता है।

जो लोग स्वयं समाधान का प्रयास करना चाहते हैं वे संपूर्ण एसक्यूएल स्क्रिप्ट और पायथन क्लाइंट को पूरी फाइलों में डाउनलोड कर सकते हैं। मुझे मिले विचारों, आलोचनाओं और बग के लिए आभारी रहूंगा।