प्रतिकृति स्लॉट क्या हैं?
उन दिनों में जब "प्रतिकृति स्लॉट" अभी तक पेश नहीं किए गए थे, वाल सेगमेंट का प्रबंधन एक चुनौती थी। मानक स्ट्रीमिंग प्रतिकृति में, मास्टर को दास की स्थिति का कोई ज्ञान नहीं है। एक मास्टर का उदाहरण लें जो एक बड़े लेनदेन को अंजाम देता है, जबकि एक स्टैंडबाय नोड कुछ घंटों के लिए रखरखाव मोड में होता है (जैसे सिस्टम पैकेज को अपग्रेड करना, नेटवर्क सुरक्षा को समायोजित करना, हार्डवेयर अपग्रेड आदि)। किसी बिंदु पर, मास्टर चेकपॉइंट पास के रूप में अपने लेनदेन लॉग (वाल सेगमेंट) को हटा देता है। एक बार जब दास रखरखाव बंद कर देता है, तो संभवतः उसके पास एक विशाल दास अंतराल होता है और उसे स्वामी के साथ पकड़ना होता है। आखिरकार, दास को नीचे जैसा घातक मुद्दा मिलेगा:
LOG: started streaming WAL from primary at 0/73000000 on timeline 1
FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000000000073 has already been removedसामान्य दृष्टिकोण यह है कि आप अपने postgresql.conf में एक WAL अभिलेखीय स्क्रिप्ट निर्दिष्ट करें जो WAL फ़ाइलों को एक या अधिक दीर्घकालिक संग्रह स्थानों पर कॉपी करेगी। यदि आपके पास कोई स्टैंडबाय या अन्य स्ट्रीमिंग प्रतिकृति क्लाइंट नहीं है, तो मूल रूप से सर्वर एक बार संग्रह स्क्रिप्ट हो जाने या ठीक प्रतिक्रिया देने के बाद WAL फ़ाइल को त्याग सकता है। लेकिन क्रैश पुनर्प्राप्ति के लिए आपको अभी भी कुछ हाल की WAL फ़ाइलों की आवश्यकता होगी (हाल ही में WAL फ़ाइलों से डेटा क्रैश पुनर्प्राप्ति के दौरान फिर से चलाया जाता है। स्टैंडबाय नोड के हमारे उदाहरण में जो एक लंबी रखरखाव अवधि के लिए रखा गया है, समस्याएँ तब उत्पन्न होती हैं जब यह ऑनलाइन वापस आती है और पूछती है WAL फ़ाइल के लिए प्राथमिक जो अब प्राथमिक नहीं है, तो प्रतिकृति विफल हो जाती है।
इस समस्या को PostgreSQL 9.4 में "प्रतिकृति स्लॉट" के माध्यम से संबोधित किया गया था।
यदि प्रतिकृति स्लॉट का उपयोग नहीं कर रहे हैं, तो प्रतिकृति विफल होने के जोखिम को कम करने का एक सामान्य तरीका wal_keep_segments को इतना ऊंचा सेट करना है कि WAL फ़ाइलों की आवश्यकता हो सकती है जिन्हें घुमाया या पुनर्नवीनीकरण नहीं किया जाएगा। इस दृष्टिकोण का नुकसान यह है कि यह निर्धारित करना कठिन है कि आपके सेटअप के लिए कौन सा मूल्य सर्वोत्तम है। आपको दैनिक आधार पर रखरखाव की आवश्यकता नहीं होगी या आपको WAL फ़ाइलों का एक बड़ा ढेर रखने की आवश्यकता नहीं होगी जो आपके डिस्क संग्रहण को खा जाती है। हालांकि यह काम करता है, यह एक आदर्श समाधान नहीं है क्योंकि मास्टर पर डिस्क स्थान को जोखिम में डालने से आने वाले लेनदेन विफल हो सकते हैं।
प्रतिकृति स्लॉट का उपयोग न करने का वैकल्पिक तरीका है कि PostgreSQL को निरंतर संग्रह के साथ कॉन्फ़िगर किया जाए और संग्रह को प्रतिकृति पहुंच प्रदान करने के लिए एक पुनर्स्थापना_कमांड प्रदान किया जाए। प्राथमिक पर वाल बिल्ड-अप से बचने के लिए, आप वाल फाइलों के लिए एक अलग वॉल्यूम या स्टोरेज डिवाइस का उपयोग कर सकते हैं, जैसे, सैन या एनएफएस। एक और बात सिंक्रोनस प्रतिकृति के साथ है क्योंकि इसके लिए आवश्यक है कि प्राथमिक को लेनदेन करने के लिए स्टैंडबाय नोड्स की प्रतीक्षा करनी पड़े। इसका मतलब है, यह आश्वासन देता है कि वाल फाइलें स्टैंडबाय नोड्स पर लागू की गई हैं। लेकिन फिर भी, यह सबसे अच्छा है कि आप प्राथमिक से संग्रह आदेश प्रदान करें ताकि एक बार WAL के प्राथमिक में पुनर्नवीनीकरण हो जाने के बाद, निश्चिंत रहें कि पुनर्प्राप्ति के मामले में आपके पास WAL बैकअप हैं। हालांकि कुछ स्थितियों में, सिंक्रोनस प्रतिकृति एक आदर्श समाधान नहीं है क्योंकि यह एसिंक्रोनस प्रतिकृति की तुलना में कुछ प्रदर्शन ओवरहेड के साथ आता है।
प्रतिकृति स्लॉट के प्रकार
प्रतिकृति स्लॉट दो प्रकार के होते हैं। ये हैं:
भौतिक प्रतिकृति स्लॉट
मानक स्ट्रीमिंग प्रतिकृति के लिए उपयोग किया जा सकता है। वे यह सुनिश्चित करेंगे कि डेटा को बहुत जल्दी पुनर्नवीनीकरण न किया जाए।
तार्किक प्रतिकृति स्लॉट
तार्किक प्रतिकृति भौतिक प्रतिकृति स्लॉट के समान काम करती है और तार्किक प्रतिकृति के लिए उपयोग की जाती है। हालाँकि, उनका उपयोग तार्किक डिकोडिंग के लिए किया जाता है। तार्किक डिकोडिंग के पीछे का विचार उपयोगकर्ताओं को लेन-देन लॉग में संलग्न करने और इसे एक प्लगइन के साथ डीकोड करने का मौका देना है। यह डेटाबेस में किए गए परिवर्तनों को निकालने की अनुमति देता है और इसलिए किसी भी प्रारूप में और किसी भी उद्देश्य के लिए लेनदेन लॉग में।
इस ब्लॉग में, हम भौतिक प्रतिकृति स्लॉट का उपयोग करेंगे और ClusterControl का उपयोग करके इसे कैसे प्राप्त करें।
प्रतिकृति स्लॉट का उपयोग करने के लाभ और नुकसान
प्रतिकृति स्लॉट एक बार सक्षम होने के बाद निश्चित रूप से फायदेमंद होते हैं। डिफ़ॉल्ट रूप से, "प्रतिकृति स्लॉट" सक्षम नहीं होते हैं और उन्हें मैन्युअल रूप से सेट करना पड़ता है। प्रतिकृति स्लॉट का उपयोग करने के फायदों में से हैं
- यह सुनिश्चित करता है कि मास्टर सभी प्रतिकृतियों को प्राप्त करने के लिए पर्याप्त WAL सेगमेंट बनाए रखे
- मास्टर को उन पंक्तियों को हटाने से रोकता है जो प्रतिकृतियों पर पुनर्प्राप्ति विरोध का कारण बन सकती हैं
- एक मास्टर लेन-देन लॉग को केवल तभी रीसायकल कर सकता है जब वह सभी प्रतिकृतियों द्वारा उपभोग कर लिया गया हो। यहाँ लाभ यह है कि एक गुलाम कभी भी इतना पीछे नहीं रह सकता कि एक पुन:समन्वयन की आवश्यकता हो।
प्रतिकृति स्लॉट भी कुछ चेतावनी के साथ आते हैं।
- एक अनाथ प्रतिकृति स्लॉट मास्टर से ढेर की गई WAL फ़ाइलों के कारण असीमित डिस्क वृद्धि का कारण बन सकता है
- लंबे समय तक रखरखाव (जैसे दिन या सप्ताह) के तहत रखे गए स्लेव नोड्स और जो एक प्रतिकृति स्लॉट से बंधे होते हैं, मास्टर से WAL फ़ाइलों को ढेर करने के कारण अनबाउंड डिस्क वृद्धि होगी
आप उपयोग नहीं किए गए स्लॉट का निर्धारण करने के लिए pg_replication_slots को क्वेरी करके इसकी निगरानी कर सकते हैं। हम इस पर थोड़ी देर बाद फिर से जांच करेंगे।
प्रतिकृति स्लॉट का उपयोग करना
जैसा कि पहले बताया गया है, प्रतिकृति स्लॉट दो प्रकार के होते हैं। इस ब्लॉग के लिए, हम प्रतिकृति स्ट्रीमिंग के लिए भौतिक प्रतिकृति स्लॉट का उपयोग करेंगे।
प्रतिकृति स्लॉट बनाना
प्रतिकृति बनाना सरल है। ऐसा करने के लिए आपको मौजूदा फ़ंक्शन pg_create_ Physical_replication_slot को इनवॉइस करना होगा और इसे मास्टर नोड में चलाना और बनाना होगा। फ़ंक्शन सरल है,
maximus_db=# \df pg_create_physical_replication_slot
Schema | pg_catalog
Name | pg_create_physical_replication_slot
Result data type | record
Argument data types | slot_name name, immediately_reserve boolean DEFAULT false, OUT slot_name name, OUT xlog_position pg_lsn
Type | normalउदा. स्लॉट1 नामक एक प्रतिकृति स्लॉट बनाना,
postgres=# SELECT pg_create_physical_replication_slot('slot1');
-[ RECORD 1 ]-----------------------+---------
pg_create_physical_replication_slot | (slot1,)प्रतिकृति स्लॉट नाम और इसका अंतर्निहित विन्यास केवल सिस्टम-वाइड है और क्लस्टर-वाइड नहीं है। उदाहरण के लिए, यदि आपके पास नोडए (वर्तमान मास्टर), और स्टैंडबाय नोड्स नोडबी और नोडसी है, जो मास्टर नोडए पर स्लॉट बना रहा है, जिसका नाम "स्लॉट1" है, तो डेटा नोडबी और नोडसी के लिए उपलब्ध नहीं होगा। इसलिए, जब फ़ेलओवर/स्विचओवर होने वाला हो, तो आपको अपने द्वारा बनाए गए स्लॉट्स को फिर से बनाना होगा।
एक प्रतिकृति स्लॉट छोड़ना
अप्रयुक्त प्रतिकृति स्लॉट को छोड़ना या हटाना होगा। जैसा कि पहले कहा गया है, जब अनाथ प्रतिकृति स्लॉट या स्लॉट होते हैं जिन्हें किसी क्लाइंट या स्टैंडबाय नोड्स को असाइन नहीं किया गया है, तो इसे छोड़े जाने पर असीमित डिस्क स्थान समस्याएं हो सकती हैं। इसलिए यह बहुत महत्वपूर्ण है कि जब इनका उपयोग नहीं हो रहा हो तो इन्हें छोड़ना होगा। इसे छोड़ने के लिए, बस pg_drop_replication_slot का आह्वान करें। इस फ़ंक्शन की निम्नलिखित परिभाषा है:
maximus_db=# \df pg_drop_replication_slot
Schema | pg_catalog
Name | pg_drop_replication_slot
Result data type | void
Argument data types | name
Type | normalइसे छोड़ना आसान है:
maximus_db=# select pg_drop_replication_slot('slot2');
-[ RECORD 1 ]------------+-
pg_drop_replication_slot |अपने PostgreSQL प्रतिकृति स्लॉट की निगरानी करना
अपने प्रतिकृति स्लॉट की निगरानी करना कुछ ऐसा है जिसे आप मिस नहीं करना चाहते हैं। बस नीचे की तरह प्राथमिक/मास्टर नोड में pg_replication_slots दृश्य से जानकारी एकत्र करें:
postgres=# select * from pg_replication_slots;
-[ RECORD 1 ]-------+-----------
slot_name | main_slot
plugin |
slot_type | physical
datoid |
database |
active | t
active_pid | 16297
xmin |
catalog_xmin |
restart_lsn | 2/F4000108
confirmed_flush_lsn |
-[ RECORD 2 ]-------+-----------
slot_name | main_slot2
plugin |
slot_type | physical
datoid |
database |
active | f
active_pid |
xmin |
catalog_xmin |
restart_lsn |
confirmed_flush_lsn |उपरोक्त परिणाम दर्शाता है कि main_slot लिया गया है, लेकिन main_slot2 नहीं।
एक और चीज जो आप कर सकते हैं, वह यह है कि आपके पास मौजूद स्लॉट से कितना पिछड़ा हुआ है, इसकी निगरानी करना है। इसे प्राप्त करने के लिए, आप बस नीचे दिए गए नमूना परिणाम के आधार पर क्वेरी का उपयोग कर सकते हैं:
postgres=# SELECT redo_lsn, slot_name,restart_lsn,
round((redo_lsn-restart_lsn) / 1024 / 1024 / 1024, 2) AS GB_behind
FROM pg_control_checkpoint(), pg_replication_slots;
redo_lsn | slot_name | restart_lsn | gb_behind
------------+-----------+-------------+-----------
1/8D400238 | slot1 | 0/9A000000 | 3.80लेकिन redo_lsn 9.6 में मौजूद नहीं है, redo_location का उपयोग करेगा, इसलिए 9.6 में,
imbd=# SELECT redo_location, slot_name,restart_lsn,
round((redo_location-restart_lsn) / 1024 / 1024 / 1024, 2) AS GB_behind
FROM pg_control_checkpoint(), pg_replication_slots;
-[ RECORD 1 ]-+-----------
redo_location | 2/F6008BE0
slot_name | main_slot
restart_lsn | 2/F6008CC0
gb_behind | 0.00
-[ RECORD 2 ]-+-----------
redo_location | 2/F6008BE0
slot_name | main_slot2
restart_lsn | 2/F6008CC0
gb_behind | 0.00सिस्टम चर आवश्यकताएँ
प्रतिकृति स्लॉट को लागू करने के लिए मैन्युअल सेटिंग की आवश्यकता होती है। ऐसे चर हैं जिन्हें आपको ध्यान में रखना है कि परिवर्तनों की आवश्यकता है और आपके postgresql.conf में निर्दिष्ट किया जाना चाहिए। नीचे देखें:
- max_replication_slots - यदि 0 पर सेट है, तो इसका मतलब है कि प्रतिकृति स्लॉट पूरी तरह से अक्षम हैं। यदि आप PostgreSQL <10 संस्करणों का उपयोग कर रहे हैं, तो इस स्लॉट को 0 (डिफ़ॉल्ट) के अलावा अन्य निर्दिष्ट करना होगा। PostgreSQL 10 के बाद से, डिफ़ॉल्ट 10 है। यह चर प्रतिकृति स्लॉट की अधिकतम संख्या निर्दिष्ट करता है। इसे वर्तमान में मौजूद प्रतिकृति स्लॉट की संख्या से कम मान पर सेट करने से सर्वर प्रारंभ नहीं हो पाएगा।
- wal_level - कम से कम प्रतिकृति या उच्चतर होना चाहिए (प्रतिकृति डिफ़ॉल्ट है)। hot_standby या संग्रह को सेट करने से प्रतिकृति को मैप किया जाएगा। भौतिक प्रतिकृति स्लॉट के लिए, प्रतिकृति पर्याप्त है। तार्किक प्रतिकृति स्लॉट के लिए, तार्किक को प्राथमिकता दी जाती है।
- max_wal_senders - डिफ़ॉल्ट रूप से 10 पर सेट, 9.6 संस्करण में 0 जिसका अर्थ है कि प्रतिकृति अक्षम है। हमारा सुझाव है कि आप इसे कम से कम 16 पर सेट करें, खासकर ClusterControl के साथ चलते समय।
- hot_standby - संस्करणों में <10, आपको इसे उस पर सेट करना होगा जिस पर डिफ़ॉल्ट रूप से बंद है। यह स्टैंडबाय नोड्स के लिए महत्वपूर्ण है, जिसका अर्थ है कि चालू होने पर, आप पुनर्प्राप्ति के दौरान या स्टैंडबाय मोड में क्वेरी कनेक्ट और चला सकते हैं।
- primary_slot_name - यह वेरिएबल रिकवरी.कॉन्फ के माध्यम से स्टैंडबाय नोड पर सेट किया गया है। प्रेषक (या प्राथमिक/मास्टर) से कनेक्ट होने पर रिसीवर या स्टैंडबाय नोड द्वारा उपयोग किया जाने वाला यह स्लॉट है।
आपको यह ध्यान रखना होगा कि नए मानों को पुनः लोड करने के लिए इन चरों को अधिकतर डेटाबेस सेवा पुनरारंभ की आवश्यकता होती है।
ClusterControl PostgreSQL पर्यावरण में प्रतिकृति स्लॉट का उपयोग करना
अब, देखते हैं कि हम भौतिक प्रतिकृति स्लॉट का उपयोग कैसे कर सकते हैं और उन्हें ClusterControl द्वारा प्रबंधित Postgres सेटअप में कैसे लागू कर सकते हैं।
PostgreSQL डेटाबेस नोड्स का परिनियोजन
आइए इस बार PostgreSQL 9.6 संस्करण का उपयोग करके ClusterControl का उपयोग करके 3-नोड PostgreSQL क्लस्टर को परिनियोजित करना प्रारंभ करें।
ClusterControl उनके डिफ़ॉल्ट के आधार पर तदनुसार परिभाषित निम्नलिखित सिस्टम वेरिएबल के साथ नोड्स को परिनियोजित करेगा या मूल्यों को ट्यून किया। में:
postgres=# select name, setting from pg_settings where name in ('max_replication_slots', 'wal_level', 'max_wal_senders', 'hot_standby');
name | setting
-----------------------+---------
hot_standby | on
max_replication_slots | 0
max_wal_senders | 16
wal_level | replica
(4 rows)PostgreSQL के संस्करणों में> 9.6, max_replication_slots डिफ़ॉल्ट मान 10 है जो डिफ़ॉल्ट रूप से सक्षम है लेकिन 9.6 या निम्न संस्करणों में नहीं जो डिफ़ॉल्ट रूप से अक्षम है। आपको 0 से अधिक max_replication_slots असाइन करने की आवश्यकता है। इस उदाहरण में, मैंने max_replication_slots को 5 पर सेट किया है।
[email protected]:~# grep 'max_replication_slots' /etc/postgresql/9.6/main/postgresql.conf
# max_replication_slots = 0 # max number of replication slots
max_replication_slots = 5और सेवा को फिर से शुरू किया,
[email protected]:~# pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
9.6 main 5432 online postgres /var/lib/postgresql/9.6/main pg_log/postgresql-%Y-%m-%d_%H%M%S.log
[email protected]:~# pg_ctlcluster 9.6 main restartप्राथमिक और स्टैंडबाय नोड्स के लिए प्रतिकृति स्लॉट सेट करना
ऐसा करने के लिए ClusterControl में कोई विकल्प नहीं है, इसलिए आपको अपने स्लॉट मैन्युअल रूप से बनाने होंगे। इस उदाहरण में, मैंने होस्ट 192.168.30.100 में प्राइमरी में स्लॉट बनाए:
192.168.10.100:5432 [email protected]_db=# SELECT pg_create_physical_replication_slot('slot1'), pg_create_physical_replication_slot('slot2');
pg_create_physical_replication_slot | pg_create_physical_replication_slot
-------------------------------------+-------------------------------------
(slot1,) | (slot2,)
(1 row)यह जांचना कि हमने अभी क्या शो बनाए हैं,
192.168.10.100:5432 [email protected]_db=# select * from pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn
-----------+--------+-----------+--------+----------+--------+------------+------+--------------+-------------+---------------------
slot1 | | physical | | | f | | | | |
slot2 | | physical | | | f | | | | |
(2 rows)अब स्टैंडबाय नोड्स में, हमें रिकवरी.कॉन्फ को अपडेट करना होगा और वेरिएबल प्राइमरी_स्लॉट_नाम को जोड़ना होगा और एप्लिकेशन_नाम को बदलना होगा ताकि नोड की पहचान करना आसान हो। यहां बताया गया है कि यह होस्ट 192.168.30.110 Recovery.conf में कैसा दिखता है:
[email protected]:/var/lib/postgresql/9.6/main/pg_log# cat ../recovery.conf
standby_mode = 'on'
primary_conninfo = 'application_name=node11 host=192.168.30.100 port=5432 user=cmon_replication password=m8rLmZxyn23Lc2Rk'
recovery_target_timeline = 'latest'
primary_slot_name = 'slot1'
trigger_file = '/tmp/failover_5432.trigger'होस्ट 192.168.30.120 में भी यही काम कर रहे हैं लेकिन application_name बदल दिया है और Primary_slot_name ='slot2' सेट कर दिया है।
प्रतिकृति स्लॉट स्वास्थ्य की जांच:
192.168.10.100:5432 [email protected]_db=# select * from pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn
-----------+--------+-----------+--------+----------+--------+------------+------+--------------+-------------+---------------------
slot1 | | physical | | | t | 24252 | | | 0/CF0A4218 |
slot2 | | physical | | | t | 11635 | | | 0/CF0A4218 |
(2 rows)आपको और क्या चाहिए?
चूंकि ClusterControl इस समय प्रतिकृति स्लॉट का समर्थन नहीं करता है, इसलिए कुछ चीजें हैं जिन पर आपको ध्यान देने की आवश्यकता है। यह क्या हैं? आइए विवरण में चलते हैं।
विफलता/स्विचओवर प्रक्रिया
जब ClusterControl के माध्यम से ऑटो फेलओवर या स्विचओवर का प्रयास किया गया है, तो प्राथमिक और स्टैंडबाय नोड्स पर स्लॉट्स को बरकरार नहीं रखा जाएगा। आपको इसे मैन्युअल रूप से फिर से बनाना होगा, अगर सही तरीके से सेट किया गया है तो वेरिएबल्स की जांच करें और उसके अनुसार रिकवरी.कॉन्फ को संशोधित करें।
एक मास्टर से एक गुलाम का पुनर्निर्माण
गुलाम का पुनर्निर्माण करते समय, Recovery.conf को बरकरार नहीं रखा जाएगा। इसका अर्थ है कि आपकी प्राथमिक_स्लॉट_नाम वाली पुनर्प्राप्ति.कॉन्फ़ सेटिंग्स मिटा दी जाएंगी। आपको इसे मैन्युअल रूप से फिर से निर्दिष्ट करने की आवश्यकता है और यह निर्धारित करने के लिए pg_replication_slots दृश्य की जांच करें कि क्या स्लॉट ठीक से उपयोग किए गए हैं या अनाथ छोड़ दिए गए हैं।
यदि आप किसी मास्टर से स्लेव/स्टैंडबाय नोड का पुनर्निर्माण करना चाहते हैं, तो आपको नीचे दिए गए आदेश की तरह ही PGAPPNAME env चर निर्दिष्ट करने पर विचार करना पड़ सकता है:
$ export PGAPPNAME="app_repl_testnode15"; /usr/pgsql-9.6/bin/pg_basebackup -h 192.168.10.190 -U cmon_replication -D /var/lib/pgsql/9.6/data -p5434 -W -S main_slot -X s -R -P-R परम निर्दिष्ट करना बहुत महत्वपूर्ण है, इसलिए यह पुनर्प्राप्ति.कॉन्फ़ को फिर से बनाएगा, जबकि -S यह निर्दिष्ट करेगा कि स्टैंडबाय नोड का पुनर्निर्माण करते समय किस स्लॉट नाम का उपयोग करना है।
निष्कर्ष
PostgreSQL में प्रतिकृति स्लॉट को लागू करना सीधा है फिर भी कुछ निश्चित चेतावनी हैं जिन्हें आपको याद रखना चाहिए। ClusterControl के साथ परिनियोजन करते समय, आपको फ़ेलओवर या स्लेव के पुनर्निर्माण के दौरान कुछ सेटिंग्स को अपडेट करने की आवश्यकता होगी।
