PostgreSQL13 में अपग्रेड करना

पोस्टग्रेएसक्यूएल 13 में नया क्या है, इस बारे में हाल के एक ब्लॉग में, हमने इस संस्करण की कुछ नई विशेषताओं की समीक्षा की, लेकिन अब देखते हैं कि इन सभी उल्लिखित कार्यात्मकताओं का लाभ उठाने में सक्षम होने के लिए कैसे अपग्रेड किया जाए। ।

PostgreSQL 13 में अपग्रेड करना

यदि आप अपने वर्तमान PostgreSQL संस्करण को इस नए संस्करण में अपग्रेड करना चाहते हैं, तो इस कार्य को करने के लिए आपके पास तीन मुख्य मूल विकल्प हैं।

Pg_dump/pg_dumpall:यह एक तार्किक बैकअप टूल है जो आपको अपने डेटा को डंप करने और उसे पुनर्स्थापित करने की अनुमति देता है नया PostgreSQL संस्करण। यहां आपके पास एक डाउनटाइम अवधि होगी जो आपके डेटा आकार के अनुसार अलग-अलग होगी। आपको सिस्टम को रोकने या प्राथमिक नोड में नए डेटा से बचने, pg_dump चलाने, उत्पन्न डंप को नए डेटाबेस नोड में स्थानांतरित करने और इसे पुनर्स्थापित करने की आवश्यकता है। इस समय के दौरान, आप डेटा असंगति से बचने के लिए अपने प्राथमिक PostgreSQL डेटाबेस में नहीं लिख सकते।
Pg_upgrade:यह आपके PostgreSQL संस्करण को इन-प्लेस अपग्रेड करने के लिए एक PostgreSQL टूल है। यह उत्पादन के माहौल में खतरनाक हो सकता है और हम उस मामले में इस पद्धति की अनुशंसा नहीं करते हैं। इस पद्धति का उपयोग करने से आपके पास डाउनटाइम भी होगा, लेकिन संभवत:यह पिछली pg_dump विधि का उपयोग करने की तुलना में काफी कम होगा।
तार्किक प्रतिकृति:PostgreSQL 10 के बाद से, आप इस प्रतिकृति पद्धति का उपयोग कर सकते हैं जो आपको प्रमुख संस्करण उन्नयन के साथ प्रदर्शन करने की अनुमति देता है शून्य (या लगभग शून्य) डाउनटाइम। इस तरह, आप पिछले PostgreSQL संस्करण में एक स्टैंडबाय नोड जोड़ सकते हैं, और जब प्रतिकृति अप-टू-डेट होती है, तो आप नए PostgreSQL नोड को बढ़ावा देने के लिए एक विफलता प्रक्रिया कर सकते हैं।

तो, आइए इन विधियों को एक-एक करके देखें।

pg_dump/pg_dumpall का उपयोग करना

यदि डाउनटाइम आपके लिए कोई समस्या नहीं है, तो यह तरीका अपग्रेड करने का एक आसान तरीका है।

डंप बनाने के लिए, आप चला सकते हैं:

$ pg_dumpall > dump_pg12.out

या एकल डेटाबेस का डंप बनाने के लिए:

$ pg_dump world > dump_world_pg12.out

फिर, आप इस डंप को नए PostgreSQL संस्करण के साथ सर्वर पर कॉपी कर सकते हैं, और इसे पुनर्स्थापित कर सकते हैं:

$ psql -f dump_pg12.out postgres

ध्यान रखें कि इस प्रक्रिया के दौरान आपको अपने आवेदन को रोकना होगा या अपने डेटाबेस में लिखने से बचना होगा, अन्यथा, आपके पास डेटा असंगति या संभावित डेटा हानि होगी।

pg_upgrad का उपयोग करना

सबसे पहले, आपको सर्वर पर नए और पुराने दोनों PostgreSQL संस्करण स्थापित करने होंगे।

$ rpm -qa |grep postgres
postgresql13-contrib-13.3-2PGDG.rhel8.x86_64
postgresql13-server-13.3-2PGDG.rhel8.x86_64
postgresql13-libs-13.3-2PGDG.rhel8.x86_64
postgresql13-13.3-2PGDG.rhel8.x86_64
postgresql12-libs-12.7-2PGDG.rhel8.x86_64
postgresql12-server-12.7-2PGDG.rhel8.x86_64
postgresql12-12.7-2PGDG.rhel8.x86_64
postgresql12-contrib-12.7-2PGDG.rhel8.x86_64

फिर, पहले, आप -c ध्वज जोड़कर अपग्रेड के परीक्षण के लिए pg_upgrad चला सकते हैं:

$ /usr/pgsql-13/bin/pg_upgrade -b /usr/pgsql-12/bin -B /usr/pgsql-13/bin -d /var/lib/pgsql/12/data -D /var/lib/pgsql/13/data -c

Performing Consistency Checks on Old Live Server

------------------------------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok
Checking for new cluster tablespace directories             ok

*Clusters are compatible*

झंडे का मतलब है:

-b:पुरानी PostgreSQL निष्पादन योग्य निर्देशिका
-B:नई PostgreSQL निष्पादन योग्य निर्देशिका
-d:पुराना डेटाबेस क्लस्टर कॉन्फ़िगरेशन निर्देशिका
-D:नया डेटाबेस क्लस्टर कॉन्फ़िगरेशन निर्देशिका
-c:केवल क्लस्टर की जांच करें। यह कोई डेटा नहीं बदलता है

यदि सब कुछ ठीक दिखता है, तो आप -c ध्वज के बिना वही कमांड चला सकते हैं और यह आपके PostgreSQL सर्वर को अपग्रेड कर देगा। इसके लिए आपको पहले अपने वर्तमान संस्करण को रोकना होगा और उल्लिखित कमांड को चलाना होगा।

$ systemctl stop postgresql-12
$ /usr/pgsql-13/bin/pg_upgrade -b /usr/pgsql-12/bin -B /usr/pgsql-13/bin -d /var/lib/pgsql/12/data -D /var/lib/pgsql/13/data
...

Upgrade Complete

----------------

Optimizer statistics are not transferred by pg_upgrade so, once you start the new server, consider running:

    ./analyze_new_cluster.sh

Running this script will delete the old cluster's data files:

    ./delete_old_cluster.sh

जब यह पूरा हो जाता है, जैसा कि संदेश से पता चलता है, आप उन स्क्रिप्ट का उपयोग नए PostgreSQL सर्वर का विश्लेषण करने और पुराने सर्वर के सुरक्षित होने पर उसे हटाने के लिए कर सकते हैं।

तार्किक प्रतिकृति का उपयोग करना

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

तो इसके आधार पर, प्रकाशक को कॉन्फ़िगर करें, इस मामले में PostgreSQL 12 सर्वर, निम्नानुसार है।

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.141/32     md5

वहां ग्राहक आईपी पते का उपयोग करें।

अब, आपको सब्सक्राइबर को कॉन्फ़िगर करना होगा, इस मामले में PostgreSQL 13 सर्वर, निम्नानुसार है।

postgresql.conf कॉन्फ़िगरेशन फ़ाइल संपादित करें:

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

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

wal_level = logical
archive_mode = on

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

इनमें से कुछ परिवर्तनों के लिए सर्वर को पुनरारंभ करना आवश्यक है, इसलिए प्रकाशक और ग्राहक दोनों को पुनरारंभ करें।

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

world=# CREATE ROLE rep1 WITH LOGIN PASSWORD '********' REPLICATION;
CREATE ROLE
world=# GRANT SELECT ON ALL TABLES IN SCHEMA public to rep1;
GRANT

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

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

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

PostgreSQL 12 में, रन करें:

$ pg_dumpall -s > schema.sql

PostgreSQL 13 में, रन करें:

$ psql -d postgres -f schema.sql

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

world=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=10.10.10.140 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                 | 16421
subname               | sub1
pid                   | 464
relid                 |
received_lsn          | 0/23A8490
last_msg_send_time    | 2021-07-23 22:42:26.358605+00
last_msg_receipt_time | 2021-07-23 22:42:26.358842+00
latest_end_lsn        | 0/23A8490
latest_end_time       | 2021-07-23 22:42:26.358605+00

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

world=# SELECT * FROM pg_subscription_rel;
 srsubid | srrelid | srsubstate | srsublsn
---------+---------+------------+-----------
   16421 |   16408 | r          | 0/23B1738
   16421 |   16411 | r          | 0/23B17A8
   16421 |   16405 | r          | 0/23B17E0
   16421 |   16402 | r          | 0/23B17E0
(4 rows)

कॉलम विवरण:

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

जब प्रारंभिक स्थानांतरण समाप्त हो जाता है, तो आपके पास अपने एप्लिकेशन को अपने नए PostgreSQL 13 सर्वर पर इंगित करने के लिए सब कुछ तैयार होता है।

निष्कर्ष

जैसा कि आप देख सकते हैं, PostgreSQL के पास आपकी आवश्यकताओं और डाउनटाइम सहनशीलता के आधार पर अपग्रेड करने के लिए विभिन्न विकल्प हैं।

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