उत्पादन पर Postgresql 9.1 की स्ट्रीमिंग प्रतिकृति के कार्यान्वयन की समस्या थी। और कब से पहले उसके साथ कोई व्यवसाय नहीं था, उन्होंने उसका "चरम परीक्षण" करने का फैसला किया।
ऐसा करने के लिए, Ubuntu सर्वर के साथ दो VMWare प्लेयर वर्चुअल मशीनें लॉन्च की गईं। Postgresql 9.1 पर स्थापित और कॉन्फ़िगर की गई स्ट्रीमिंग प्रतिकृति।
सिंक की गति
होस्ट मशीन से एक स्क्रिप्ट लॉन्च की गई थी जिसमें लूप में प्रतिकृति डेटाबेस के परीक्षण तालिका में बहुत सारी पंक्तियाँ शामिल थीं। स्क्रिप्ट को 3 थ्रेड में चलाया गया था।
वर्चुअल मशीनों पर, प्रोसेसर पर दोनों (लोड में एक अनंत लूप) और परीक्षण तालिका से डेटा पढ़कर एक लोड बनाया गया था। असमान लोड की भी जाँच की गई थी - यह या तो दास पर काट दिया गया था, फिर मास्टर पर।
परिणाम बहुत अच्छी तस्वीर थी। हालांकि उनका मूल्यांकन "आंख से" किया गया था, लेकिन 1-2 सेकंड से अधिक के लिए कोई भी वंशानुक्रम नहीं देखा गया था। और फिर, इस तरह के एक desynchronization केवल एक बहुत ही उच्च भार (कई समानांतर लोड प्रक्रियाओं) और थोड़े समय के लिए हुआ।
बिजली आउटेज स्थिरता
fsync = बंद
अद्यतन और ऑपरेशन को सम्मिलित करने के लिए, Postgresql के पिछले संस्करण का उपयोग fsync = ऑफ विकल्प के साथ किया गया था। वर्चुअल मशीन के fsync अक्षम और हार्ड शटडाउन (पावर विफलता का अनुकरण) के साथ प्रतिकृति के व्यवहार का परीक्षण किया गया था।
परिणाम काफी अनुमानित थे। डेटाबेस को शुरू करने और बहाल करने के बाद, यह पता चला कि मास्टर पर बाइनरी लॉग में वर्तमान बिंदु गुलाम पर संसाधित बिंदु से पहले है। यानी डेटाबेस पूरी तरह से सिंक से बाहर है और आपको सर्वर को स्क्रैच से सिंक्रनाइज़ करने की आवश्यकता है (गुलाम डेटाबेस बनाने के लिए सामान्य प्रक्रिया का उपयोग करके - संपूर्ण डेटा निर्देशिका की प्रतिलिपि बनाने के साथ)।
fsync = पर
सर्वर को सिंक्रनाइज़ करने के बाद, हमने fsync सक्षम होने पर प्रतिकृति व्यवहार का परीक्षण किया।
एक "कठिन" शटडाउन के साथ, साल्वे कुछ खास नहीं हुआ। वह मास्टर के साथ पत्रिका में गुलाब और "पकड़ा"।
अधिक दिलचस्प स्थिति तब होती है जब आप मास्टर को बंद कर देते हैं। जब इसे ठीक से डिस्कनेक्ट किया गया था, तो यह बंद हो गया, इंतजार किया, चालू हुआ, जांच की गई, सब कुछ ठीक हो गया। आधार गुलाब, बरामद, और गुलाम के साथ सिंक्रनाइज़ किया गया।
इसके बाद, डेटा सेंटर में "ब्लिंकिंग इलेक्ट्रिसिटी" का अनुकरण किया गया। मास्टर सर्वर समय-समय पर मनमाने बिंदुओं पर "हार्ड-रीसेट" किया गया था। आमतौर पर, ये क्षण उस समय होते हैं जब Postgresql सर्वर शुरू होता है या थोड़ी देर बाद। नतीजतन, मास्टर पर आधार सामान्य रूप से बढ़ गया, लेकिन दास के साथ कुछ छोटी समस्याएं थीं। दास लॉग में, कुछ लेनदेन रिकॉर्ड के गलत आकार के बारे में संदेश आने लगे और यह मास्टर के साथ सिंक्रनाइज़ नहीं हुआ। हालांकि, गुलाम पर Postgresql को फिर से शुरू करने पर सब कुछ फिर से ठीक हो गया।
Fsync मान के आधार पर प्रविष्टि की गति
कई चक्रों में fsync मान पर सम्मिलन की गति की निर्भरता का परीक्षण किया गया था। परिणामों के अनुसार, यह पता चला कि fsync के साथ = गति लगभग 3.3% अधिक है। क्या आधार के नुकसान को तेज करने के लिए इसके लायक है जब बिजली बंद हो जाती है - यह हर किसी को तय करना है। मैं व्यक्तिगत रूप से Postgresql को विशेष रूप से fsync = on के साथ उपयोग करने का इरादा रखता हूं।
फ़ाइल ट्रिगर का उपयोग करके दास को मास्टर मोड में स्विच करें
स्विचिंग अच्छी तरह से काम करता है। लेकिन एक "लेकिन" है इस स्विच के साथ, दास पूरी तरह से स्वतंत्र स्वामी बन जाता है। यानी मास्टर के साथ पूर्ण सिंक्रनाइज़ेशन के बिना दास की स्थिति में वापस लौटना असंभव है। यह इस तथ्य का परिणाम है कि इस पर एक नई समयरेखा बनाई गई है - समयरेखा। इसके अलावा, इसके परिणामस्वरूप, यदि आप कई दासों का उपयोग करते हैं, तो अन्य सभी नए मास्टर से डिस्कनेक्ट हो जाते हैं। और उन्हें जोड़ने के लिए, उनके पूर्ण तुल्यकालन की आवश्यकता होती है।
परिणाम
इन परीक्षणों के परिणामस्वरूप, मुझे व्यक्तिगत रूप से यह विश्वास था कि पोस्टग्रैसेकल 9.1 में प्रतिकृति को पूरी तरह कार्यात्मक और विश्वसनीय माना गया है।