स्ट्रीम प्रतिकृति और तार्किक प्रतिकृति के बीच अंतर

टीएल;डीआर :तार्किक प्रतिकृति पंक्ति-दर-पंक्ति परिवर्तन भेजता है, भौतिक प्रतिकृति डिस्क ब्लॉक परिवर्तन भेजता है। कुछ कार्यों के लिए तार्किक प्रतिकृति बेहतर है, दूसरों के लिए भौतिक प्रतिकृति।

ध्यान दें कि PostgreSQL 12 (अपडेट के समय वर्तमान) में तार्किक प्रतिकृति स्थिर और विश्वसनीय है, लेकिन काफी सीमित है। यदि आप यह प्रश्न पूछ रहे हैं तो भौतिक प्रतिकृति का प्रयोग करें।

स्ट्रीमिंग प्रतिकृति हो सकती है तार्किक प्रतिकृति। यह सब थोड़ा जटिल है।

WAL-शिपिंग बनाम स्ट्रीमिंग

PostgreSQL में मास्टर से रेप्लिका में डेटा भेजने के दो मुख्य तरीके हैं:

वाल-शिपिंग या निरंतर संग्रह , जहां अलग-अलग राइट-फ़ॉरवर्ड-लॉग फ़ाइलें pg_xlog . से कॉपी की जाती हैं archive_command . द्वारा मास्टर पर किसी अन्य स्थान पर चल रहा है। एक restore_command प्रतिकृति के recovery.conf . में कॉन्फ़िगर किया गया है संग्रह को लाने के लिए प्रतिकृति पर चलता है ताकि प्रतिकृति वाल को फिर से चला सके।

इसका उपयोग पॉइंट-इन-टाइम प्रतिकृति . के लिए किया जाता है (PITR), जिसका उपयोग निरंतर बैकअप की एक विधि के रूप में किया जाता है।

मास्टर सर्वर से सीधे नेटवर्क कनेक्शन की आवश्यकता नहीं है। प्रतिकृति में लंबा विलंब हो सकता है, विशेष रूप से बिना archive_timeout . के समूह। तुल्यकालिक प्रतिकृति के लिए WAL शिपिंग का उपयोग नहीं किया जा सकता है।
स्ट्रीमिंग प्रतिकृति , जहां प्रत्येक परिवर्तन एक या अधिक प्रतिकृति सर्वरों को सीधे टीसीपी/आईपी कनेक्शन पर भेजा जाता है जैसा कि ऐसा होता है। प्रतिकृतियों के पास एक सीधा नेटवर्क कनेक्शन होना चाहिए जो मास्टर उनके recovery.conf . में कॉन्फ़िगर किया गया हो का primary_conninfo विकल्प।

स्ट्रीमिंग प्रतिकृति में बहुत कम या कोई देरी नहीं है, जब तक कि प्रतिकृति बनाए रखने के लिए पर्याप्त तेज़ है। इसका उपयोग तुल्यकालिक प्रतिकृति . के लिए किया जा सकता है . आप PITR के लिए स्ट्रीमिंग प्रतिकृति का उपयोग नहीं कर सकते हैं, इसलिए यह निरंतर बैकअप के लिए अधिक उपयोग नहीं है। यदि आप मास्टर पर कोई तालिका छोड़ते हैं, तो उफ़, वह प्रतिकृतियों पर भी गिरा दी जाती है।

इस प्रकार, दो विधियों के अलग-अलग उद्देश्य हैं।

एसिंक्रोनस बनाम सिंक्रोनस स्ट्रीमिंग

उसके ऊपर, तुल्यकालिक . है और एसिंक्रोनस स्ट्रीमिंग प्रतिकृति:

एसिंक्रोनस स्ट्रीमिंग प्रतिकृति . में जब मास्टर तेज/व्यस्त हो तो प्रतिकृति को मास्टर के पीछे गिरने की अनुमति दी जाती है। यदि मास्टर क्रैश हो जाता है तो आप उस डेटा को खो सकते हैं जिसे अभी तक दोहराया नहीं गया था।

यदि एसिंक्रोनस प्रतिकृति मास्टर से बहुत पीछे हो जाती है, तो मास्टर उस जानकारी को फेंक सकता है जिसे प्रतिकृति की आवश्यकता होती है यदि max_wal_size (जिसे पहले wal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master's pg_wal(was pg_xlog) मास्टर को तब तक भर सकता है और काम करने से रोक सकता है जब तक कि डिस्क स्थान खाली न हो जाए यदि max_wal_size बहुत अधिक है या स्लॉट का उपयोग किया जाता है।
तुल्यकालिक प्रतिकृति . में मास्टर तब तक प्रतिबद्ध नहीं होता जब तक कि प्रतिकृति ने पुष्टि नहीं की कि उसे लेनदेन प्राप्त हुआ है। यदि मास्टर क्रैश हो जाता है और आपको प्रतिकृति में विफल होना पड़ता है तो आप कभी भी डेटा नहीं खोते हैं। मास्टर कभी भी प्रतिकृति की जरूरत के डेटा को फेंक नहीं देगा या अपने एक्सलॉग को भरेगा और प्रतिकृति देरी के कारण डिस्क स्थान से बाहर नहीं चलेगा। बदले में यह मास्टर को धीमा कर सकता है या यहां तक कि काम करना बंद कर सकता है यदि प्रतिकृतियों में समस्या है, और नेटवर्क विलंबता के कारण इसका मास्टर पर हमेशा कुछ प्रदर्शन प्रभाव पड़ता है।

जब कई प्रतिकृतियां होती हैं, तो एक समय में केवल एक ही समकालिक होती है। देखें synchronous_standby_names ।

आपके पास सिंक्रोनस लॉग शिपिंग नहीं हो सकती है।

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

तार्किक बनाम भौतिक

कि . के ऊपर हमारे पास तार्किक है बनाम भौतिक स्ट्रीमिंग प्रतिकृति, जैसा कि PostgreSQL 9.4 में पेश किया गया है:

भौतिक स्ट्रीमिंग प्रतिकृति . में परिवर्तन लगभग डिस्क ब्लॉक स्तर पर भेजे जाते हैं, जैसे "रिलेशनशिप 12311 के डिस्क पेज 18 के ऑफसेट 14 पर, हेक्स मान 0x2342beef1222 के साथ टपल लिखा..."।

भौतिक प्रतिकृति सब कुछ भेजती है :PostgreSQL में हर डेटाबेस की सामग्री, हर डेटाबेस में सभी टेबल। यह अनुक्रमणिका प्रविष्टियाँ भेजता है, जब आप VACUUM FULL करते हैं तो यह संपूर्ण नई तालिका डेटा भेजता है , यह लेन-देन के लिए डेटा भेजता है जो वापस लुढ़क जाता है, आदि। इसलिए यह बहुत अधिक "शोर" उत्पन्न करता है और बहुत अधिक डेटा भेजता है। इसके लिए प्रतिकृति को पूरी तरह से समान होने की भी आवश्यकता होती है, इसलिए आप ऐसा कुछ भी नहीं कर सकते जिसके लिए लेनदेन की आवश्यकता हो, जैसे अस्थायी या अनलॉग टेबल बनाना। प्रतिकृति को क्वेरी करने से प्रतिकृति में देरी होती है, इसलिए प्रतिकृति पर लंबे प्रश्नों को रद्द करने की आवश्यकता होती है।

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

भौतिक प्रतिकृति परिपक्व, अच्छी तरह से परीक्षण और व्यापक रूप से अपनाई गई है।

तार्किक स्ट्रीमिंग प्रतिकृति , 9.4 में नया, उच्च स्तर पर परिवर्तन भेजता है, और बहुत कुछ चुनिंदा रूप से।

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

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

PostgreSQL में मल्टी-मास्टर प्रतिकृति बनाने के लिए तार्किक प्रतिकृति का भी उपयोग किया जा सकता है, जो भौतिक प्रतिकृति का उपयोग करके संभव नहीं है।

बदले में, हालांकि, यह (वर्तमान में) बड़े लेनदेन को स्ट्रीम नहीं कर सकता जैसा कि वे होते हैं। उन्हें प्रतिबद्ध होने तक इंतजार करना होगा। इसलिए मास्टर पर किए गए बड़े लेन-देन और प्रतिकृति पर लागू होने के बीच एक लंबा विलंब हो सकता है।

यह लेन-देन को प्रतिबद्ध क्रम में सख्ती से दोहराता है, इसलिए छोटे तेज़ लेन-देन एक बड़े लेनदेन के पीछे फंस सकते हैं और कुछ समय के लिए विलंबित हो सकते हैं।

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

आवेदन प्रक्रिया स्वयं "कुछ बाइट्स लिखें जहां मुझे बताया गया है" से भी अधिक जटिल है। यह भौतिक प्रतिकृति की तुलना में प्रतिकृति पर अधिक संसाधन भी लेता है।

वर्तमान तार्किक प्रतिकृति कार्यान्वयन परिपक्व या व्यापक रूप से अपनाया नहीं गया है, या विशेष रूप से उपयोग में आसान नहीं है।

बहुत सारे विकल्प, मुझे बताएं कि क्या करना है

ओफ़्फ़। जटिल, हुह? और मुझे विलंबित प्रतिकृति, स्लॉट, max_wal_size के विवरण में भी नहीं मिला है , समयसीमा, प्रचार कैसे काम करता है, पोस्टग्रेज-एक्सएल, बीडीआर और मल्टीमास्टर, आदि।

तो आपको क्या करना चाहिए करें ?

एक भी सही उत्तर नहीं है। अन्यथा PostgreSQL केवल उसी तरह से समर्थन करेगा। लेकिन कुछ सामान्य उपयोग के मामले हैं:

बैकअप और आपदा रिकवरी . के लिए pgbarman . का उपयोग करें आधार बैकअप बनाने और आपके लिए WAL बनाए रखने के लिए, निरंतर बैकअप को प्रबंधित करने में आसान प्रदान करना। आपको अभी भी समय-समय पर pg_dump लेना चाहिए अतिरिक्त बीमा के रूप में बैकअप।

शून्य डेटा हानि जोखिम के साथ उच्च उपलब्धता . के लिए स्ट्रीमिंग सिंक्रोनस प्रतिकृति का उपयोग करें।

कम डेटा हानि जोखिम और बेहतर प्रदर्शन के साथ उच्च उपलब्धता . के लिए आपको एसिंक्रोनस स्ट्रीमिंग प्रतिकृति का उपयोग करना चाहिए। फ़ॉलबैक के लिए या तो WAL संग्रह सक्षम करें या प्रतिकृति स्लॉट का उपयोग करें। Icinga जैसे बाहरी उपकरणों का उपयोग करके मॉनिटर करें कि प्रतिकृति मास्टर के पीछे कितनी दूर है।

स्ट्रीम प्रतिकृति और तार्किक प्रतिकृति के बीच अंतर

WAL-शिपिंग बनाम स्ट्रीमिंग

एसिंक्रोनस बनाम सिंक्रोनस स्ट्रीमिंग

तार्किक बनाम भौतिक

बहुत सारे विकल्प, मुझे बताएं कि क्या करना है

संदर्भ