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

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

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

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

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

PostgreSQL तार्किक प्रतिकृति

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

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

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

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

लॉजिकल प्रतिकृति का उपयोग करके PostgreSQL 11 को PostgreSQL 12 में अपग्रेड कैसे करें

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

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

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

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

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

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

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

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

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

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     rep1     10.10.10.131/32     md5

आपको उपयोगकर्ता को बदलना होगा (इस उदाहरण में rep1), जिसका उपयोग प्रतिकृति के लिए किया जाएगा, और IP पता 10.10.10.131/32 IP के लिए जो आपके PostgreSQL 12 नोड से संबंधित है।

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

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

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

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

postgresql.conf:

listen_addresses = '*'

max_replication_slots = 4

max_logical_replication_workers = 4

max_worker_processes = 8

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

wal_level = logical

archive_mode = on

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

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

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

CREATE ROLE

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

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

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

GRANT

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

world=# CREATE PUBLICATION pub1 FOR ALL TABLES;

CREATE PUBLICATION

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

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

world=# SELECT * FROM pg_publication;

-[ RECORD 1 ]+-----

pubname      | pub1

pubowner     | 10

puballtables | t

pubinsert    | t

pubupdate    | t

pubdelete    | t

pubtruncate  | t

कॉलम विवरण:

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

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

PostgreSQL 11 में:

$ pg_dumpall -s > schema.sql

PostgreSQL 12 में:

$ psql -d postgres -f schema.sql

एक बार जब आप PostgreSQL 12 में अपना स्कीमा प्राप्त कर लेते हैं, तो आपको होस्ट, dbname, उपयोगकर्ता और पासवर्ड के मानों को अपने परिवेश से मेल खाने वाले मानों के स्थान पर, सदस्यता बनाने की आवश्यकता होती है।

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

world=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=10.10.10.130 dbname=world user=rep1 password=*****' PUBLICATION pub1;

NOTICE:  created replication slot "sub1" on publisher

CREATE SUBSCRIPTION

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

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

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

world=# SELECT * FROM pg_stat_subscription;

-[ RECORD 1 ]---------+------------------------------

subid                 | 16422

subname               | sub1

pid                   | 476

relid                 |

received_lsn          | 0/1771668

last_msg_send_time    | 2020-09-29 17:40:34.711411+00

last_msg_receipt_time | 2020-09-29 17:40:34.711533+00

latest_end_lsn        | 0/1771668

latest_end_time       | 2020-09-29 17:40:34.711411+00

कॉलम विवरण:

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

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

world=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid              | 527

usesysid         | 16428

usename          | rep1

application_name | sub1

client_addr      | 10.10.10.131

client_hostname  |

client_port      | 35570

backend_start    | 2020-09-29 17:40:04.404905+00

backend_xmin     |

state            | streaming

sent_lsn         | 0/1771668

write_lsn        | 0/1771668

flush_lsn        | 0/1771668

replay_lsn       | 0/1771668

write_lag        |

flush_lag        |

replay_lag       |

sync_priority    | 0

sync_state       | async

कॉलम विवरण:

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

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

2020-09-29 17:40:04.403 UTC [476] LOG:  logical replication apply worker for subscription "sub1" has started

2020-09-29 17:40:04.411 UTC [477] LOG:  logical replication table synchronization worker for subscription "sub1", table "city" has started

2020-09-29 17:40:04.422 UTC [478] LOG:  logical replication table synchronization worker for subscription "sub1", table "country" has started

2020-09-29 17:40:04.516 UTC [477] LOG:  logical replication table synchronization worker for subscription "sub1", table "city" has finished

2020-09-29 17:40:04.522 UTC [479] LOG:  logical replication table synchronization worker for subscription "sub1", table "countrylanguage" has started

2020-09-29 17:40:04.570 UTC [478] LOG:  logical replication table synchronization worker for subscription "sub1", table "country" has finished

2020-09-29 17:40:04.676 UTC [479] LOG:  logical replication table synchronization worker for subscription "sub1", table "countrylanguage" has finished

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

world=# SELECT * FROM pg_subscription_rel;

 srsubid | srrelid | srsubstate | srsublsn

---------+---------+------------+-----------

   16422 |   16386 | r          | 0/1771630

   16422 |   16392 | r          | 0/1771630

   16422 |   16399 | r          | 0/1771668

(3 rows)

कॉलम विवरण:

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

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

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

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

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

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 12 पर इंगित करने के लिए सब कुछ तैयार है।

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

प्राथमिक नोड पर:

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 12 सर्वर में बदलना होगा।

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

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

माइग्रेशन के अंत में, आप PostgreSQL 12 में अपने नए प्राथमिक नोड में सदस्यता हटा सकते हैं:

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)

सीमाएं

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

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

निष्कर्ष

नियमित उन्नयन करके अपने PostgreSQL सर्वर को अद्यतित रखना PostgreSQL 10 संस्करण तक एक आवश्यक लेकिन कठिन कार्य रहा है। सौभाग्य से अब यह एक अलग कहानी है तार्किक प्रतिकृति के लिए धन्यवाद।

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

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

PostgreSQL तार्किक प्रतिकृति

लॉजिकल प्रतिकृति का उपयोग करके PostgreSQL 11 को PostgreSQL 12 में अपग्रेड कैसे करें

postgresql.conf:

​pg_hba.conf:

postgresql.conf:

सीमाएं

निष्कर्ष

pg_hba.conf: