अपने डेटाबेस को PostgreSQL संस्करण 10 में अपग्रेड करना - आपको क्या पता होना चाहिए

जैसे ही PostgreSQL 11 पर अधिक से अधिक पोस्ट वेब पर दिखाई देते हैं, पोस्टग्रेज़ 9 का उपयोग करते समय आप उतने ही पुराने महसूस कर सकते हैं। हालाँकि PostgreSQL 10 संस्करण रिलीज़ केवल कुछ महीने पहले हुआ था, लोग पहले से ही अगले संस्करण के बारे में बात कर रहे हैं। चीजें आगे बढ़ रही हैं, इसलिए आप पीछे नहीं रहना चाहते। इस ब्लॉग में हम चर्चा करेंगे कि नवीनतम संस्करण पोस्टग्रेज 10 में अपग्रेड करने के लिए आपको क्या जानना चाहिए।

अपग्रेड विकल्प

शुरू करने से पहले आपको सबसे पहली बात यह जाननी चाहिए कि अपग्रेड करने के कई तरीके हैं:

1. पारंपरिक pg_dumpall(pg_dump) / pg_restore(psql)
2. पारंपरिक pg_upgrad
3. ट्रिगर आधारित प्रतिकृति (स्लोनी, स्व-लिखित)
4. pgological प्रतिकृति का उपयोग करना

ऐसी विविधता क्यों है? क्योंकि प्रत्येक का एक अलग इतिहास होता है, जिसे स्थापित करने और विभिन्न सेवाओं की पेशकश करने के लिए अलग-अलग प्रयासों की आवश्यकता होती है। आइए उनमें से प्रत्येक को करीब से देखें।

पारंपरिक डंप/पुनर्स्थापना

pg_dump t > /tmp/f
psql -p 5433 -f /tmp/f

पारंपरिक डंप/पुनर्स्थापना को पूरा होने में सबसे लंबा समय लगता है और फिर भी यह अक्सर उन लोगों के लिए एक लोकप्रिय विकल्प है जो डाउनटाइम का खर्च उठा सकते हैं। पहला, तार्किक बैकअप लेना और उसे डेटाबेस के नए, उच्च संस्करण में पुनर्स्थापित करना जितना आसान है। आप कह सकते हैं कि यह अपग्रेड नहीं है, वास्तव में, जब आप अपने डेटा को "नई संरचना" में "आयात" करते हैं। परिणामस्वरूप आप दो सेटअप के साथ समाप्त होंगे - एक पुराना (निचला संस्करण) और नया अपग्रेड किया गया। यदि पुनर्स्थापना प्रक्रिया बिना किसी त्रुटि के समाप्त हो जाती है, तो आप बहुत अधिक हैं। यदि नहीं, तो आपको किसी भी त्रुटि को समाप्त करने और प्रक्रिया को फिर से शुरू करने के लिए मौजूदा पुराने क्लस्टर को संशोधित करना होगा।

यदि आप आयात के लिए psql का उपयोग करते हैं, तो आपको माइग्रेशन से पहले नए सेटअप पर निष्पादित करने के लिए स्वयं कुछ प्रीलोड स्क्रिप्ट बनाने की आवश्यकता हो सकती है। उदाहरण के लिए, आप नए सेटअप में तैयार करने के लिए आवश्यक भूमिकाओं की सूची प्राप्त करने के लिए pg_dumpall -g या पुराने से अनुमतियों को छोड़ने के लिए विपरीत रन pg_dump -x प्राप्त करना चाहेंगे। यह प्रक्रिया छोटे डेटाबेस पर बहुत सरल है, जटिलता आपके डीबी संरचना के आकार और जटिलता के साथ बढ़ती है और इस बात पर निर्भर करती है कि आपने कौन सी सुविधाएं स्थापित की हैं। मूल रूप से इस पद्धति के सफल होने के लिए, आपको अपग्रेड सफल होने तक प्रयास और सुधार करते रहने की आवश्यकता है।

इस पद्धति का उपयोग करने के लाभों में शामिल हैं...

• हालांकि आप अपने द्वारा बनाए गए एक बैकअप के साथ लंबा समय बिता सकते हैं - पुराने सर्वर पर लोड एक बैकअप लेने जितना छोटा है।
• यह विधि ज्यादातर एक बैकअप-पुनर्स्थापन अनुक्रम है (संभवतः कुछ मंत्रों, गीतों और ढोल के साथ)
• इस पद्धति का उपयोग करना अपग्रेड करने का सबसे पुराना तरीका है और कई लोगों द्वारा सत्यापित किया गया है

जब आप अंत में अपग्रेड को पूरा करते हैं तो आपको या तो पुराने सर्वर को बंद करना होगा या कुछ डेटा हानि को स्वीकार करना होगा (या वैकल्पिक रूप से नए सर्वर पर बैकअप बहाल करते समय पुराने सर्वर पर होने वाले डीएमएल को फिर से चलाएं)। और ऐसा करने में बिताया गया समय आपके डेटाबेस के आकार के सापेक्ष है।

आप निश्चित रूप से, पुनर्स्थापना समाप्त होने से पहले एक नए डेटाबेस का "उपयोग" शुरू कर सकते हैं (विशेषकर सभी इंडेक्स बनने से पहले - अक्सर इंडेक्स के लिए सबसे अधिक समय लगता है)। लेकिन फिर भी ऐसा डाउनटाइम अक्सर अस्वीकार्य होता है।

पारंपरिक pg_upgrad

MacBook-Air:~ vao$ /usr/local/Cellar/postgresql/10.2/bin/initdb -D tl0 >/tmp/suppressing_to_save_screen_space_read_it

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
MacBook-Air:~ vao$ /usr/local/Cellar/postgresql/10.2/bin/pg_upgrade -b /usr/local/Cellar/postgresql/9.5.3/bin -B /usr/local/Cellar/postgresql/10.2/bin -d t -D tl0 | tail
Creating script to delete old cluster                        ok

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

पारंपरिक pg_upgrad को एक प्रमुख संस्करण में अपग्रेड करने में लगने वाले समय को कम करने के लिए बनाया गया था। आपके संबंधों की मात्रा के आधार पर यह मिनटों के रूप में तेज़ हो सकता है (हास्यास्पद मामलों में सेकंड, जैसे एक टेबल डेटाबेस और "विपरीत मामलों" में घंटे) विशेष रूप से --link तर्क के साथ।

तैयारी का क्रम पहले अपग्रेड विधि से थोड़ा अलग है। अपग्रेड का मज़ाक उड़ाने के लिए और इस प्रकार यह जाँचने के लिए कि क्या यह संभव है, आपको स्ट्रीमिंग प्रतिकृति का निर्माण करना चाहिए या WALs से एक स्टैंडबाय सर्वर पुनर्प्राप्त करना चाहिए। यह इतना जटिल क्यों है? जैसा कि आपने मूल रूप से किया था, आप यथा-करीबी-इन-स्टेट-डेटाबेस पर अपग्रेड का परीक्षण करना सुनिश्चित करना चाहते हैं। "बाइनरी" प्रतिकृति या पीआईटीआर यहां हमारी मदद करेगा। आपके द्वारा पुनर्प्राप्ति और पुनर्प्राप्ति_टारगेट_एक्शन =प्रचार (PITR) या नव निर्मित दास को बढ़ावा देने के बाद (pg_ctl को बढ़ावा देना या ट्रिगर फ़ाइल रखना) (स्ट्रीमिंग प्रतिकृति) फिर आप pg_upgrad को चलाने का प्रयास कर सकते हैं। pg_upgrad_internal.log की जाँच करने से आपको पता चल जाएगा कि प्रक्रिया सफल रही या नहीं। इसके अलावा, आपके पास पिछली विधि के समान ही कोशिश-और-फिक्स दृष्टिकोण है। आप परीक्षण डेटाबेस के विरुद्ध की गई कार्रवाइयों को एक स्क्रिप्ट में सहेजते हैं, जब तक कि आप इसे सफलतापूर्वक pg_upgrad नहीं करते। इसके अतिरिक्त, आप अब आवश्यक नहीं परीक्षण destroy को नष्ट कर सकते हैं अपग्रेड किया गया डेटाबेस, अपग्रेड करने के लिए मूल डेटाबेस तैयार करने के लिए फिर सेव की गई स्क्रिप्ट चलाएँ।

इस पद्धति का उपयोग करने के लाभों में शामिल हैं…

• तार्किक बैकअप/पुनर्स्थापन की तुलना में कम डाउनटाइम
• एक साफ-सुथरी प्रक्रिया - pg_upgrad मौजूदा डेटा और संरचना के साथ मूल डेटाबेस को अपग्रेड करता है
• अतीत में बहुत उपयोग किया गया है और अभी भी 9.4 से नीचे चलने वाले अधिकांश डीबीए संस्करण के लिए प्राथमिकता होगी (जो pglogic का उपयोग करने की अनुमति देता है)

इस पद्धति का उपयोग करने के नुकसान में शामिल हैं…

• डाउनटाइम की आवश्यकता है

ट्रिगर आधारित प्रतिकृति

मान लें कि संस्करण 10 पोर्ट 5433 पर है और उसी तालिका को तैयार किया गया है:

db=# create server upgrade_to_10 foreign data wrapper postgres_fdw options (port '5433', dbname 'dbl0');
CREATE SERVER
Time: 9.135 ms
db=# create user mapping for vao SERVER upgrade_to_10 options (user 'vao');
CREATE USER MAPPING
Time: 8.741 ms
db=# create foreign table rl0 (pk int, t text) server upgrade_to_10 options (table_name 'r');
CREATE FOREIGN TABLE
Time: 9.358 ms

यह एक अत्यंत सरलीकृत fn() है और बहुत ही बुनियादी तार्किक प्रतिकृति के लिए ट्रिगर है। ऐसा दृष्टिकोण इतना आदिम है कि यह विदेशी कुंजियों के साथ काम नहीं करेगा, लेकिन कोड छोटा है:

db=# create or replace function tf() returns trigger as $$
begin
 if TG_0P = 'INSERT' then
   insert into r10 select NEW.*;
 elseif TG_0P = 'UPDATE' then
   delete from rl0 where pk = NEW.pk;
   insert into rl0 select NEW.*;
 elseif TG_0P = 'DELETE' then
   delete from rl0 where pk = OLD.pk;
 end if;
return case when TG_0P in ('INSERT','UPDATE') then NEW else OLD end;
end;
SS language plpgsql;
CREATE FUNCTION
Time: 8.531 ms
db=# create trigger t before insert or update or delete on r for each row execute procedure tf(); CREATE TRIGGER
Time: 8.813 ms

उदाहरण:

db=# insert into r(t) select chr(g) from generate_series(70,75) g;
INSERT 0 6
Time: 12.621 ms
db=# update r set t = 'updated' where pk=2;
UPDATE 1
Time: 10.398 ms
db=# delete from r where pk=1;
DELETE 1
Time: 9.634 ms
db=# select * from r;
 pk |    t
----+---------
  3 | H
  4 | I
  5 | J
  6 | K
  2 | updated
(5 rows)

Time: 9.026 ms
db=# select * from rl0;
 pk |    t
----+---------
  3 | H
  4 | I
  5 | J
  6 | K
  2 | updated
(5 rows)

Time: 1.201 ms

अंत में, यह जाँचना कि हम किसी भिन्न डेटाबेस को दोहराते हैं:

db=# select *,current_setting('port') from dblink('upgrade.to.lO','select setting from pg_settings where name=$$port$$') as t(setting_10 text);
 setting_10 | currerrt.setting
------------+------------------
 5433       | 5432
(l row)

Time: 23.633 ms

मैं इस पद्धति को सबसे अधिक विदेशी कहूंगा। दोनों इस तथ्य के लिए कि स्ट्रीमिंग प्रतिकृति के साथ और बाद में pglogic के साथ, ट्रिगर आधारित प्रतिकृति का उपयोग कम लोकप्रिय हो जाता है। इसका मास्टर पर अधिक भार है, सेटअप के दौरान बढ़ी हुई जटिलता और अच्छी तरह से संरचित प्रलेखन की कमी है। यहां प्रक्रिया की कोई तैयारी (जैसे) नहीं है, क्योंकि आप स्लोनी को विभिन्न प्रमुख संस्करणों पर सेटअप करना चाहते हैं।

इस पद्धति का उपयोग करने के लाभों में शामिल हैं…

• कोई बैकअप लेने की आवश्यकता नहीं है और न ही किसी डाउनटाइम की आवश्यकता है (विशेषकर आप किसी pgbouncer या haproxy के पीछे हैं)।

इस पद्धति का उपयोग करने के नुकसान में शामिल हैं…

• सेटअप की उच्च जटिलता
• संरचित दस्तावेज़ों का अभाव
• बहुत लोकप्रिय नहीं - अध्ययन (और साझा करने) के लिए कम उपयोगकर्ता मामले

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

pglogic के साथ तार्किक प्रतिकृति

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

इस पद्धति का उपयोग करने के लाभों में शामिल हैं…

• मूल रूप से कोई डाउनटाइम नहीं
• अत्यंत आशाजनक विशेषता, ट्रिगर आधारित प्रतिकृति की तुलना में बहुत कम प्रयास

इस पद्धति का उपयोग करने के नुकसान में शामिल हैं…

• सेटअप के लिए अभी भी अत्यधिक जटिल है (विशेषकर पुराने संस्करणों के लिए)
• संरचित दस्तावेज़ों का अभाव
• बहुत लोकप्रिय नहीं - अध्ययन (और साझा करने) के लिए कम उपयोगकर्ता मामले

ट्रिगर-आधारित और pgological प्रतिकृति दोनों प्रमुख संस्करण माइग्रेशन का उपयोग संस्करण को डाउनग्रेड करने के लिए किया जा सकता है (निश्चित रूप से कुछ उचित मूल्य तक, उदाहरण के लिए, pglogic केवल 9.4 से उपलब्ध है और ट्रिगर प्रतिकृति आपके इच्छित संस्करण के रूप में स्थापित करना कठिन और कठिन हो जाता है पुराने होने के लिए डाउनग्रेड करने के लिए)।

अपग्रेड से पहले की जाने वाली कार्रवाइयां

• बैकअप लें
• सुनिश्चित करें कि पर्याप्त डिस्क स्थान है
• अपने एक्सटेंशन जांचें (महत्वपूर्ण है कि कोई भी बाहरी मॉड्यूल भी बाइनरी संगत हैं, हालांकि इसे pg_upgrad द्वारा चेक नहीं किया जा सकता है)
• नए डेटाबेस पर एक ही datcollate और datctype आदि का उपयोग करना सुनिश्चित करें (pg_database जांचें)
• देखें (डीडीएल + ड्रॉप) दृश्य, फ़ंक्शन, एक्सटेंशन, प्रकार जो अपग्रेड को बाधित कर सकते हैं
• उपयोग करें -- वास्तव में pg_upgrad करने से पहले जांचें

अपग्रेड के बाद की जाने वाली कार्रवाइयां

• pg_upgrad_server.log से परामर्श करें (यदि आपने pg_upgrad का उपयोग किया है)
• अपग्रेड किए गए डेटाबेस पर विश्लेषण चलाएं (वैकल्पिक, क्योंकि यह ऑटोवैक्यूम द्वारा किया जाएगा, लेकिन आप चुन सकते हैं कि यदि आप इसे स्वयं करते हैं तो पहले किन संबंधों का विश्लेषण किया जाना चाहिए)
• प्रीवार्म लोकप्रिय पेज (वैकल्पिक, लेकिन शुरुआत में प्रदर्शन को बढ़ावा दे सकता है)

निष्कर्ष

यहां कुछ सामान्य नोट दिए गए हैं जिन्हें PostgreSQL संस्करण 10 पर जाने का निर्णय लेने से पहले जानना अच्छा है…

• pg_sequences पेश किए गए थे, जो पहले लोकप्रिय सेलेक्ट * FROM सीक्वेंस_नाम के व्यवहार को बदल रहे थे - अब केवल last_value | log_cnt | is_called लौटाए जाते हैं, जो आपसे "प्रारंभिक गुण" छिपाते हैं (बदले गए व्यवहार पर निर्भर किसी भी कोड को समायोजित करें)
• pg_basebackup डिफ़ॉल्ट रूप से WAL स्ट्रीम करता है। अपग्रेड के बाद आपको अपनी स्क्रिप्ट को संशोधित करने की आवश्यकता हो सकती है (विकल्प -x हटा दिया गया)
• सभी pg_ctl क्रियाएँ पूर्ण होने की प्रतीक्षा कर रही हैं। पहले आपको pg_ctl प्रारंभ होने के बाद सीधे डेटाबेस से कनेक्ट करने का प्रयास करने से बचने के लिए -w जोड़ना पड़ता था। इस प्रकार यदि आप अभी भी "async" स्टार्ट या स्टॉप का उपयोग करना चाहते हैं, तो आपको इसे -W के साथ स्पष्ट रूप से चिह्नित करना होगा। आपको अपनी स्क्रिप्ट को समायोजित करने की आवश्यकता हो सकती है ताकि वे इच्छित व्यवहार करें।
• WALs को संग्रहीत करने या स्ट्रीमिंग प्रतिकृति या PITR की निगरानी/नियंत्रण के लिए सभी स्क्रिप्ट की समीक्षा करने की आवश्यकता है, ताकि उन्हें परिवर्तित xlog नामों में समायोजित किया जा सके। उदा. pg_is_xlog_replay_paused() से चुनें * अब आपको गुलाम WALs रीप्ले की स्थिति नहीं दिखाएगा - आपको इसके बजाय pg_is_wal_replay_paused() से चयन * का उपयोग करना होगा। साथ ही cp /blah/pg_xlog/* को /blah/pg_wal/* में बदलने की जरूरत है और इसी तरह मूल रूप से pg_xlog की सभी घटनाओं के लिए। इतने बड़े पैमाने पर, गैर-पिछड़े संगत परिवर्तन के पीछे का कारण उस मामले को संबोधित करना है जब कोई नया व्यक्ति लॉग को हटाकर "कुछ स्थान साफ़ करने" के लिए राइट-फ़ॉरवर्ड-लॉग को हटा देता है, और डेटाबेस खो देता है।
• नए नामों के लिए pg_stat_replication का उपयोग करके स्क्रिप्ट समायोजित करें (स्थान बदलकर lsn कर दिया गया है)
• आवश्यकता होने पर सेट रिटर्निंग फ़ंक्शन के साथ क्वेरी समायोजित करें
• यदि आपने संस्करण 10 से पहले pglogic एक्सटेंशन के रूप में उपयोग किया है, तो आपको "कॉलम" के बीच pg_hba.conf बदलते मान को समायोजित करने की आवश्यकता हो सकती है
• pg_log के एक नए नाम के लिए स्क्रिप्ट समायोजित करें जो लॉग है, इसलिए कुछ इस तरह ढूंढें /pg_data/pg_log/postgresql-*  -mmin +$((60*48)) -type f -exec bash /blah/moveto.s3 ।श्री {} \; काम करेगा। बेशक आप इसके बजाय एक प्रतीकात्मक लिंक बना सकते हैं, लेकिन लॉग को डिफ़ॉल्ट स्थान पर खोजने के लिए कार्रवाई करने की आवश्यकता होगी। डिफ़ॉल्ट में एक और छोटा परिवर्तन log_line_prefix है - यदि आपकी नियमित अभिव्यक्ति एक निश्चित प्रारूप पर निर्भर करती है, तो आपको इसे समायोजित करने की आवश्यकता है।
• यदि आप अभी भी अपने पोस्टग्रेज़ डेटाबेस में अनएन्क्रिप्टेड पासवर्ड का उपयोग कर रहे थे, तो यह रिलीज़ पूर्ण रूप से इसे हटा देता है। तो यह उन लोगों के लिए चीजों को सुलझाने का समय है जो --unencrypted...
. पर निर्भर थे
• पिछले रिलीज के साथ असंगत परिवर्तन या तो बहुत सारे कोड (min_parallel_relation_size) या बहुत प्राचीन (बाहरी tsearch2) में संदर्भित होने के लिए बहुत ताज़ा हैं या बहुत अधिक आकर्षक हैं (बिल्ड में फ़्लोटिंग-पॉइंट टाइमस्टैम्प समर्थन को हटाना), इसलिए हम उन्हें छोड़ देंगे। बेशक वे रिलीज पेज पर सूचीबद्ध हैं।
• जैसा कि 9.5 से 9.6 के साथ था, आपको pg_stat_activity (एक नया कॉलम और नए संभावित मान) को क्वेरी करने के लिए अपनी स्क्रिप्ट को समायोजित करने की आवश्यकता हो सकती है
• यदि आप वैक्यूम वर्बोज़ आउटपुट सहेज रहे थे/विश्लेषण कर रहे थे, तो आपको अपना कोड समायोजित करने की आवश्यकता हो सकती है
• इसके अलावा आप नए विभाजन कार्यान्वयन पर एक नज़र डालना चाहेंगे - आप नए "मानकों" का अनुपालन करने के लिए अपने मौजूदा "सेट" को फिर से तैयार करना चाहेंगे
• समयरेखा जांचें (यदि आप pg_upgrad करते हैं तो नए डेटाबेस के लिए रीसेट कर दिया जाएगा)

इन चरणों के अलावा, जिन्हें आपको 10 में अपग्रेड करने के लिए जानना होगा, ऐसी बहुत सी चीज़ें हैं जो इस रिलीज़ को एक बहुप्रतीक्षित रिलीज़ बनाती हैं। कृपया रिलीज नोट्स या ब्लॉग ब्लॉग में परिवर्तन पर अनुभाग पढ़ें।