जीरो डाउनटाइम के साथ PostgreSQL10 को PostgreSQL11 में अपग्रेड कैसे करें

ऐतिहासिक रूप से, PostgreSQL के साथ काम करते समय सबसे कठिन काम उन्नयन से निपटना रहा है। सबसे सहज अपग्रेड तरीका जिसके बारे में आप सोच सकते हैं, एक नए संस्करण में एक प्रतिकृति उत्पन्न करना और उसमें एप्लिकेशन की विफलता करना है। PostgreSQL के साथ, यह मूल रूप से संभव नहीं था। अपग्रेड को पूरा करने के लिए आपको अपग्रेड करने के अन्य तरीकों के बारे में सोचना होगा, जैसे कि pg_upgrad का उपयोग करना, डंप करना और पुनर्स्थापित करना, या Slony या Bucardo जैसे कुछ तृतीय पक्ष टूल का उपयोग करना, इन सभी के अपने-अपने कैविएट हैं।

यह क्यों था? जिस तरह से PostgreSQL प्रतिकृति को लागू करता है।

PostgreSQL बिल्ट-इन स्ट्रीमिंग प्रतिकृति वह है जिसे भौतिक कहा जाता है:यह बाइट-बाय-बाइट स्तर पर परिवर्तनों को दोहराएगा, किसी अन्य सर्वर में डेटाबेस की एक समान प्रतिलिपि बनाएगा। अपग्रेड के बारे में सोचते समय इस पद्धति की बहुत सी सीमाएं हैं, क्योंकि आप किसी भिन्न सर्वर संस्करण में या यहां तक कि किसी भिन्न आर्किटेक्चर में प्रतिकृति नहीं बना सकते हैं।

तो, यहाँ वह जगह है जहाँ PostgreSQL 10 गेम चेंजर बन जाता है। इन नए संस्करणों 10 और 11 के साथ, PostgreSQL अंतर्निहित तार्किक प्रतिकृति को लागू करता है, जो भौतिक प्रतिकृति के विपरीत, आप PostgreSQL के विभिन्न प्रमुख संस्करणों के बीच दोहरा सकते हैं। यह, निश्चित रूप से, रणनीतियों के उन्नयन के लिए एक नया द्वार खोलता है।

इस ब्लॉग में, आइए देखें कि कैसे हम तार्किक प्रतिकृति का उपयोग करके अपने PostgreSQL 10 को PostgreSQL 11 में शून्य डाउनटाइम के साथ अपग्रेड कर सकते हैं। सबसे पहले, आइए तार्किक प्रतिकृति के परिचय के माध्यम से चलते हैं।

तार्किक प्रतिकृति क्या है?

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

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

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

तार्किक प्रतिकृति आरेख

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

आप निम्नलिखित ब्लॉगों में तार्किक प्रतिकृति के बारे में अधिक जानकारी प्राप्त कर सकते हैं:

PostgreSQL में तार्किक प्रतिकृति का अवलोकन
PostgreSQL स्ट्रीमिंग प्रतिकृति बनाम तार्किक प्रतिकृति

Logical Replication का उपयोग करके PostgreSQL 10 को PostgreSQL 11 में अपग्रेड कैसे करें

इसलिए, अब जब हम जानते हैं कि यह नई सुविधा किस बारे में है, तो हम इस बारे में सोच सकते हैं कि हम अपग्रेड की समस्या को हल करने के लिए इसका उपयोग कैसे कर सकते हैं।

हम PostgreSQL (10 और 11) के दो अलग-अलग प्रमुख संस्करणों के बीच तार्किक प्रतिकृति को कॉन्फ़िगर करने जा रहे हैं, और निश्चित रूप से, आपके द्वारा यह काम करने के बाद, यह केवल नए संस्करण के साथ डेटाबेस में एप्लिकेशन फेलओवर करने की बात है।

तार्किक प्रतिकृति को काम में लाने के लिए हम निम्नलिखित चरणों का पालन करने जा रहे हैं:

प्रकाशक नोड कॉन्फ़िगर करें
सदस्य नोड कॉन्फ़िगर करें
सदस्य उपयोगकर्ता बनाएं
एक प्रकाशन बनाएं
ग्राहक में तालिका संरचना बनाएं
सदस्यता बनाएं
प्रतिकृति स्थिति जांचें

तो चलिए शुरू करते हैं।

प्रकाशक की ओर से, हम निम्नलिखित पैरामीटर को postgresql.conf फ़ाइल में कॉन्फ़िगर करने जा रहे हैं:

सुनें_पते:किस आईपी पते पर सुनना है। हम सभी के लिए '*' का उपयोग करेंगे।
wal_level:निर्धारित करता है कि WAL को कितनी जानकारी लिखी गई है। हम इसे तार्किक पर सेट करने जा रहे हैं।
max_replication_slots:सर्वर द्वारा समर्थित प्रतिकृति स्लॉट की अधिकतम संख्या निर्दिष्ट करता है। इसे कम से कम कनेक्ट होने के लिए अपेक्षित सदस्यताओं की संख्या, साथ ही तालिका सिंक्रनाइज़ेशन के लिए कुछ आरक्षित पर सेट किया जाना चाहिए।
max_wal_senders:स्टैंडबाय सर्वर या स्ट्रीमिंग बेस बैकअप क्लाइंट से समवर्ती कनेक्शन की अधिकतम संख्या निर्दिष्ट करता है। इसे कम से कम max_replication_slots के साथ-साथ भौतिक प्रतिकृतियों की संख्या के समान सेट किया जाना चाहिए जो एक ही समय में जुड़े हुए हैं।

ध्यान रखें कि इनमें से कुछ मापदंडों को लागू करने के लिए PostgreSQL सेवा को फिर से शुरू करने की आवश्यकता है।

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

तो इसके आधार पर, हमारे प्रकाशक (इस मामले में हमारे PostgreSQL 10 सर्वर) को निम्नानुसार कॉन्फ़िगर करें:

postgresql.conf:

listen_addresses = '*'
wal_level = logical
max_wal_senders = 8
max_replication_slots = 4

pg_hba.conf:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host     all     rep     192.168.100.144/32     md5

हमें उपयोगकर्ता (हमारे उदाहरण प्रतिनिधि में) को बदलना होगा, जिसका उपयोग प्रतिकृति के लिए किया जाएगा, और IP पता 192.168.100.144/32 IP के लिए जो हमारे PostgreSQL 11 से मेल खाता है।

ग्राहक पक्ष पर, इसे सेट करने के लिए max_replication_slots की भी आवश्यकता होती है। इस मामले में, इसे कम से कम उन सब्सक्रिप्शन पर सेट किया जाना चाहिए जो सब्सक्राइबर में जोड़े जाएंगे।

अन्य पैरामीटर जिन्हें यहां सेट करने की आवश्यकता है वे हैं:

max_logical_replication_workers:तार्किक प्रतिकृति कार्यकर्ताओं की अधिकतम संख्या निर्दिष्ट करता है। इसमें लागू वर्कर और टेबल सिंक्रोनाइज़ेशन वर्कर दोनों शामिल हैं। तार्किक प्रतिकृति कार्यकर्ताओं को max_worker_processes द्वारा परिभाषित पूल से लिया जाता है। इसे कम से कम सब्सक्रिप्शन की संख्या पर सेट किया जाना चाहिए, साथ ही टेबल सिंक्रोनाइज़ेशन के लिए कुछ रिजर्व।
max_worker_processes:सिस्टम द्वारा समर्थित अधिकतम पृष्ठभूमि प्रक्रियाओं को सेट करता है। प्रतिकृति कार्यकर्ताओं के लिए समायोजित करने के लिए इसे समायोजित करने की आवश्यकता हो सकती है, कम से कम max_logic_replication_workers + 1। इस पैरामीटर के लिए PostgreSQL पुनरारंभ की आवश्यकता है।

इसलिए, हमें अपने सब्सक्राइबर (इस मामले में हमारे PostgreSQL 11 सर्वर) को निम्नानुसार कॉन्फ़िगर करना होगा:

postgresql.conf:

listen_addresses = '*'
max_replication_slots = 4
max_logical_replication_workers = 4
max_worker_processes = 8

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

wal_level = logical
archive_mode = on

यदि हम एक नया प्रतिकृति दास जोड़ना चाहते हैं या PITR बैकअप का उपयोग करना चाहते हैं तो ये पैरामीटर उपयोगी होंगे।

प्रकाशक में, हमें वह उपयोगकर्ता बनाना होगा जिससे हमारा ग्राहक कनेक्ट होगा:

world=# CREATE ROLE rep WITH LOGIN PASSWORD '*****' REPLICATION; 
CREATE ROLE

प्रतिकृति कनेक्शन के लिए उपयोग की जाने वाली भूमिका में प्रतिकृति विशेषता होनी चाहिए। भूमिका के लिए एक्सेस को pg_hba.conf में कॉन्फ़िगर किया जाना चाहिए और इसमें LOGIN विशेषता होनी चाहिए।

प्रारंभिक डेटा की प्रतिलिपि बनाने में सक्षम होने के लिए, प्रतिकृति कनेक्शन के लिए उपयोग की जाने वाली भूमिका में प्रकाशित तालिका पर SELECT विशेषाधिकार होना चाहिए।

world=# GRANT SELECT ON ALL TABLES IN SCHEMA public to rep;
GRANT

हम सभी तालिकाओं के लिए प्रकाशक नोड में pub1 प्रकाशन बनाएंगे:

world=# CREATE PUBLICATION pub1 FOR ALL TABLES;
CREATE PUBLICATION

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

बनाए गए प्रकाशन की पुष्टि करने के लिए हम pg_publication कैटलॉग का उपयोग करने जा रहे हैं। इस कैटलॉग में डेटाबेस में बनाए गए सभी प्रकाशनों के बारे में जानकारी है।

world=# SELECT * FROM pg_publication;
-[ RECORD 1 ]+------
pubname      | pub1
pubowner     | 16384
puballtables | t
pubinsert    | t
pubupdate    | t
pubdelete    | t

कॉलम विवरण:

पबनाम:प्रकाशन का नाम।
प्रकाशक:प्रकाशन का स्वामी।
puballtables:यदि सही है, तो यह प्रकाशन स्वचालित रूप से डेटाबेस में सभी तालिकाओं को शामिल करता है, जिसमें भविष्य में बनाई जाने वाली कोई भी तालिका शामिल है।
pubinsert:यदि सत्य है, INSERT संचालन प्रकाशन में तालिकाओं के लिए दोहराया जाता है।
pubupdate:अगर सही है, तो प्रकाशन में तालिकाओं के लिए अद्यतन कार्रवाई दोहराई जाती है।
pubdelete:अगर सही है, DELETE ऑपरेशंस को प्रकाशन में टेबल के लिए दोहराया जाता है।

जैसा कि स्कीमा को दोहराया नहीं गया है, हमें PostgreSQL 10 में एक बैकअप लेना चाहिए और इसे हमारे PostgreSQL 11 में पुनर्स्थापित करना चाहिए। बैकअप केवल स्कीमा के लिए लिया जाएगा, क्योंकि जानकारी को प्रारंभिक स्थानांतरण में दोहराया जाएगा।

PostgreSQL 10 में:

$ pg_dumpall -s > schema.sql

PostgreSQL 11 में:

$ psql -d postgres -f schema.sql

एक बार जब हमारे पास PostgreSQL 11 में हमारा स्कीमा होता है, तो हम सब्सक्रिप्शन बनाते हैं, होस्ट, डीबीनाम, उपयोगकर्ता और पासवर्ड के मूल्यों को हमारे पर्यावरण के अनुरूप रखते हैं।

पोस्टग्रेएसक्यूएल 11:

world=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=192.168.100.143 dbname=world user=rep password=*****' PUBLICATION pub1;
NOTICE:  created replication slot "sub1" on publisher
CREATE SUBSCRIPTION

उपरोक्त प्रतिकृति प्रक्रिया शुरू करेगा, जो प्रकाशन में तालिकाओं की प्रारंभिक तालिका सामग्री को सिंक्रनाइज़ करता है और फिर उन तालिकाओं में वृद्धिशील परिवर्तनों को दोहराना शुरू करता है।

सदस्यता बनाने वाला उपयोगकर्ता एक सुपरयुसर होना चाहिए। सदस्यता लागू करने की प्रक्रिया सुपरयूज़र के विशेषाधिकारों के साथ स्थानीय डेटाबेस में चलेगी।

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

world=# SELECT * FROM pg_stat_subscription;
-[ RECORD 1 ]---------+------------------------------
subid                 | 16428
subname               | sub1
pid                   | 1111
relid                 |
received_lsn          | 0/172AF90
last_msg_send_time    | 2018-12-05 22:11:45.195963+00
last_msg_receipt_time | 2018-12-05 22:11:45.196065+00
latest_end_lsn        | 0/172AF90
latest_end_time       | 2018-12-05 22:11:45.195963+00

कॉलम विवरण:

सबिड:सब्सक्रिप्शन का OID.
उपनाम:सदस्यता का नाम।
पिड:सदस्यता कार्यकर्ता प्रक्रिया की प्रक्रिया आईडी।
relid:उस संबंध का OID जिसे कार्यकर्ता सिंक्रनाइज़ कर रहा है; मुख्य लागू कार्यकर्ता के लिए शून्य।
received_lsn:अंतिम राइट-फ़ॉरवर्ड लॉग स्थान प्राप्त हुआ, इस फ़ील्ड का प्रारंभिक मान 0.
last_msg_send_time:मूल वाल प्रेषक से प्राप्त अंतिम संदेश का समय भेजें।
last_msg_receipt_time:मूल वाल प्रेषक से प्राप्त अंतिम संदेश की प्राप्ति का समय।
latest_end_lsn:अंतिम लेखन-आगे लॉग स्थान मूल WAL प्रेषक को रिपोर्ट किया गया।
latest_end_time:अंतिम राइट-फ़ॉरवर्ड लॉग स्थान का समय मूल WAL प्रेषक को रिपोर्ट किया गया।

मास्टर में प्रतिकृति की स्थिति को सत्यापित करने के लिए हम pg_stat_replication का उपयोग कर सकते हैं:

world=# SELECT * FROM pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
pid              | 1178
usesysid         | 16427
usename          | rep
application_name | sub1
client_addr      | 192.168.100.144
client_hostname  |
client_port      | 58270
backend_start    | 2018-12-05 22:11:45.097539+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/172AF90
write_lsn        | 0/172AF90
flush_lsn        | 0/172AF90
replay_lsn       | 0/172AF90
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async

कॉलम विवरण:

पिड:वाल प्रेषक प्रक्रिया की प्रक्रिया आईडी।
usesysid:उपयोगकर्ता का OID इस WAL प्रेषक प्रक्रिया में लॉग इन है।
प्रयोक्तानाम:इस WAL प्रेषक प्रक्रिया में लॉग इन किए गए उपयोगकर्ता का नाम।
application_name:उस एप्लिकेशन का नाम जो इस वाल प्रेषक से जुड़ा है।
client_addr:इस WAL प्रेषक से जुड़े क्लाइंट का IP पता। यदि यह फ़ील्ड रिक्त है, तो यह इंगित करता है कि क्लाइंट सर्वर मशीन पर यूनिक्स सॉकेट के माध्यम से जुड़ा हुआ है।
client_hostname:कनेक्टेड क्लाइंट का होस्टनाम, जैसा कि client_addr के रिवर्स DNS लुकअप द्वारा रिपोर्ट किया गया है। यह फ़ील्ड केवल IP कनेक्शन के लिए गैर-शून्य होगी, और केवल तभी जब log_hostname सक्षम हो।
client_port:टीसीपी पोर्ट नंबर जिसे क्लाइंट इस वाल प्रेषक के साथ संचार के लिए उपयोग कर रहा है, या -1 यदि यूनिक्स सॉकेट का उपयोग किया जाता है।
बैकएंड_स्टार्ट:वह समय जब यह प्रक्रिया शुरू की गई थी।
backend_xmin:इस स्टैंडबाय का xmin क्षितिज hot_standby_feedback द्वारा रिपोर्ट किया गया है।
राज्य:वर्तमान वाल प्रेषक राज्य। संभावित मान हैं:स्टार्टअप, कैचअप, स्ट्रीमिंग, बैकअप और स्टॉपिंग।
sent_lsn:इस कनेक्शन पर अंतिम राइट-फॉरवर्ड लॉग लोकेशन भेजा गया।
write_lsn:इस स्टैंडबाय सर्वर द्वारा डिस्क पर लिखा गया अंतिम राइट-फॉरवर्ड लॉग लोकेशन।
flush_lsn:इस स्टैंडबाय सर्वर द्वारा अंतिम राइट-फ़ॉरवर्ड लॉग स्थान डिस्क पर फ़्लश किया गया।
replay_lsn:इस स्टैंडबाय सर्वर पर डेटाबेस में अंतिम राइट-फ़ॉरवर्ड लॉग लोकेशन फिर से चलाई गई।
write_lag:हाल ही में WAL को स्थानीय रूप से फ्लश करने और यह सूचना प्राप्त करने के बीच समय बीत गया कि इस स्टैंडबाय सर्वर ने इसे लिखा है (लेकिन अभी तक इसे फ्लश या लागू नहीं किया है)।
flush_lag:हाल ही में WAL को स्थानीय रूप से फ्लश करने और यह सूचना प्राप्त करने के बीच समय व्यतीत हुआ कि इस स्टैंडबाय सर्वर ने इसे लिखा और फ़्लश किया है (लेकिन अभी तक इसे लागू नहीं किया है)।
replay_lag:हाल ही में WAL को स्थानीय रूप से फ्लश करने और यह सूचना प्राप्त करने के बीच कि इस स्टैंडबाय सर्वर ने इसे लिखा, फ़्लश और लागू किया है, के बीच का समय बीत गया।
sync_priority:प्राथमिकता-आधारित सिंक्रोनस प्रतिकृति में सिंक्रोनस स्टैंडबाय के रूप में चुने जाने के लिए इस स्टैंडबाय सर्वर की प्राथमिकता।
sync_state:इस स्टैंडबाय सर्वर की सिंक्रोनस स्थिति। संभावित मान async, संभावित, सिंक, कोरम हैं।

यह सत्यापित करने के लिए कि प्रारंभिक स्थानांतरण कब समाप्त हो गया है, हम ग्राहक पर PostgreSQL लॉग देख सकते हैं:

2018-12-05 22:11:45.096 UTC [1111] LOG:  logical replication apply worker for subscription "sub1" has started
2018-12-05 22:11:45.103 UTC [1112] LOG:  logical replication table synchronization worker for subscription "sub1", table "city" has started
2018-12-05 22:11:45.114 UTC [1113] LOG:  logical replication table synchronization worker for subscription "sub1", table "country" has started
2018-12-05 22:11:45.156 UTC [1112] LOG:  logical replication table synchronization worker for subscription "sub1", table "city" has finished
2018-12-05 22:11:45.162 UTC [1114] LOG:  logical replication table synchronization worker for subscription "sub1", table "countrylanguage" has started
2018-12-05 22:11:45.168 UTC [1113] LOG:  logical replication table synchronization worker for subscription "sub1", table "country" has finished
2018-12-05 22:11:45.206 UTC [1114] LOG:  logical replication table synchronization worker for subscription "sub1", table "countrylanguage" has finished

या pg_subscription_rel कैटलॉग पर srsubstate चर की जाँच कर रहा है। इस कैटलॉग में प्रत्येक सदस्यता में प्रत्येक प्रतिकृति संबंध के लिए स्थिति है।

world=# SELECT * FROM pg_subscription_rel;
-[ RECORD 1 ]---------
srsubid    | 16428
srrelid    | 16387
srsubstate | r
srsublsn   | 0/172AF20
-[ RECORD 2 ]---------
srsubid    | 16428
srrelid    | 16393
srsubstate | r
srsublsn   | 0/172AF58
-[ RECORD 3 ]---------
srsubid    | 16428
srrelid    | 16400
srsubstate | r
srsublsn   | 0/172AF90

कॉलम विवरण:

srsubid:सदस्यता का संदर्भ।
srrelid:संबंध का संदर्भ।
srsubstate:राज्य कोड:i =इनिशियलाइज़, d =डेटा कॉपी किया जा रहा है, s =सिंक्रोनाइज़ किया जा रहा है, r =रेडी (सामान्य प्रतिकृति)।
srsublsn:s और r राज्यों के लिए LSN समाप्त करें।

हम अपने PostgreSQL 10 में कुछ परीक्षण रिकॉर्ड सम्मिलित कर सकते हैं और पुष्टि कर सकते हैं कि हमारे पास हमारे PostgreSQL 11 में है:

पोस्टग्रेएसक्यूएल 10:

world=# INSERT INTO city (id,name,countrycode,district,population) VALUES (5001,'city1','USA','District1',10000);
INSERT 0 1
world=# INSERT INTO city (id,name,countrycode,district,population) VALUES (5002,'city2','ITA','District2',20000);
INSERT 0 1
world=# INSERT INTO city (id,name,countrycode,district,population) VALUES (5003,'city3','CHN','District3',30000);
INSERT 0 1

पोस्टग्रेएसक्यूएल 11:

world=# SELECT * FROM city WHERE id>5000;
  id  | name  | countrycode | district  | population
------+-------+-------------+-----------+------------
 5001 | city1 | USA         | District1 |      10000
 5002 | city2 | ITA         | District2 |      20000
 5003 | city3 | CHN         | District3 |      30000
(3 rows)

इस बिंदु पर, हमारे पास हमारे एप्लिकेशन को हमारे PostgreSQL 11 पर इंगित करने के लिए सब कुछ तैयार है।

इसके लिए, सबसे पहले, हमें यह पुष्टि करने की आवश्यकता है कि हमारे पास प्रतिकृति अंतराल नहीं है।

मास्टर पर:

world=# SELECT  application_name,  pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) lag FROM pg_stat_replication;
-[ RECORD 1 ]----+-----
application_name | sub1
lag              | 0

और अब, हमें केवल अपने एप्लिकेशन या लोड बैलेंसर (यदि हमारे पास एक है) से अपने एंडपॉइंट को नए PostgreSQL 11 सर्वर में बदलने की आवश्यकता है।

यदि हमारे पास HAProxy जैसा लोड बैलेंसर है, तो हम इसे PostgreSQL 10 को सक्रिय और PostgreSQL 11 को बैकअप के रूप में इस तरह से कॉन्फ़िगर कर सकते हैं:

HAProxy स्थिति देखें

इसलिए, यदि आप PostgreSQL 10 में मास्टर को बंद कर देते हैं, तो बैकअप सर्वर, इस मामले में PostgreSQL 11 में, उपयोगकर्ता/एप्लिकेशन के लिए पारदर्शी तरीके से ट्रैफ़िक प्राप्त करना शुरू कर देता है।

माइग्रेशन के अंत में, हम PostgreSQL 11 में अपने नए मास्टर की सदस्यता को हटा सकते हैं:

world=# DROP SUBSCRIPTION sub1;
NOTICE:  dropped replication slot "sub1" on publisher
DROP SUBSCRIPTION

और सत्यापित करें कि इसे सही तरीके से हटाया गया है:

world=# SELECT * FROM pg_subscription_rel;
(0 rows)
world=# SELECT * FROM pg_stat_subscription;
(0 rows)

आज श्वेतपत्र डाउनलोड करें क्लस्टरकंट्रोल के साथ पोस्टग्रेएसक्यूएल प्रबंधन और स्वचालन इस बारे में जानें कि पोस्टग्रेएसक्यूएल को तैनात करने, मॉनिटर करने, प्रबंधित करने और स्केल करने के लिए आपको क्या जानना चाहिए। श्वेतपत्र डाउनलोड करें

सीमाएं

तार्किक प्रतिकृति का उपयोग करने से पहले, कृपया निम्नलिखित सीमाओं को ध्यान में रखें:

डेटाबेस स्कीमा और डीडीएल कमांड को दोहराया नहीं जाता है। प्रारंभिक स्कीमा को pg_dump --schema-only का उपयोग करके कॉपी किया जा सकता है।
अनुक्रम डेटा दोहराया नहीं जाता है। अनुक्रम द्वारा समर्थित सीरियल या पहचान कॉलम में डेटा को तालिका के हिस्से के रूप में दोहराया जाएगा, लेकिन अनुक्रम स्वयं अभी भी ग्राहक पर प्रारंभ मान दिखाएगा।
TRUNCATE कमांड की प्रतिकृति समर्थित है, लेकिन विदेशी कुंजियों से जुड़े तालिकाओं के समूहों को काटते समय कुछ सावधानी बरतनी चाहिए। काट-छाँट करने की क्रिया को दोहराते समय, सब्सक्राइबर टेबल के उसी समूह को काट देगा, जिसे प्रकाशक पर काट दिया गया था, या तो स्पष्ट रूप से निर्दिष्ट किया गया था या CASCADE के माध्यम से अप्रत्यक्ष रूप से एकत्र किया गया था, माइनस टेबल जो सब्सक्रिप्शन का हिस्सा नहीं हैं। अगर सभी प्रभावित टेबल एक ही सब्सक्रिप्शन का हिस्सा हैं तो यह ठीक से काम करेगा। लेकिन अगर सब्सक्राइबर पर काट-छांट की जाने वाली कुछ तालिकाओं में उन तालिकाओं के लिए विदेशी-कुंजी लिंक हैं जो समान (या किसी भी) सदस्यता का हिस्सा नहीं हैं, तो सब्सक्राइबर पर ट्रंकेट कार्रवाई का आवेदन विफल हो जाएगा।
बड़ी वस्तुओं को दोहराया नहीं जाता है। सामान्य तालिकाओं में डेटा संग्रहीत करने के अलावा इसके लिए कोई समाधान नहीं है।
आधार तालिकाओं से आधार तालिकाओं तक केवल प्रतिकृति संभव है। अर्थात्, प्रकाशन और सदस्यता पक्ष पर तालिकाएँ सामान्य तालिकाएँ होनी चाहिए, न कि दृश्य, भौतिक दृश्य, विभाजन मूल तालिकाएँ, या विदेशी तालिकाएँ। विभाजन के मामले में, आप एक-से-एक विभाजन पदानुक्रम को दोहरा सकते हैं, लेकिन आप वर्तमान में किसी भिन्न विभाजन वाले सेटअप को दोहरा नहीं सकते हैं।

निष्कर्ष

अपने PostgreSQL सर्वर को नियमित रूप से अपग्रेड करके अप टू डेट रखना PostgreSQL 10 संस्करण तक एक आवश्यक लेकिन कठिन काम रहा है।

इस ब्लॉग में हमने तार्किक प्रतिकृति के लिए एक संक्षिप्त परिचय दिया, एक PostgreSQL सुविधा जो मूल रूप से संस्करण 10 में पेश की गई थी, और हमने आपको दिखाया है कि यह कैसे शून्य डाउनटाइम रणनीति के साथ इस चुनौती को पूरा करने में आपकी मदद कर सकता है।