😕 🍳 🎦 प्रमुख PostgreSQL विज्ञप्ति के बीच सीमलेस (लगभग) प्रवास तार्किक प्रतिकृति का उपयोग कर 🐰 🌉 👨🏽‍💻

ट्रू इंजीनियरिंग में, एक परियोजना पर, पोस्टग्रेक्यूएल के संस्करण को 9.6 से 11.1 तक बदलने की आवश्यकता आ गई है।

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

इसलिए, यह तय है, हम पलायन कर रहे हैं। बेशक, आप पुराने के साथ समानांतर में PostgreSQL सर्वर का एक नया संस्करण बढ़ा सकते हैं, एप्लिकेशन को रोक सकते हैं, डेटाबेस को स्थानांतरित करने के लिए डंप / रिस्टोर (या pg_upgrad) का उपयोग कर सकते हैं और फिर से आवेदन शुरू कर सकते हैं। आधार के बड़े आकार के कारण यह समाधान हमें शोभा नहीं देता, इसके अलावा, एप्लिकेशन मुकाबला मोड में काम करता है, और डाउनटाइम के लिए केवल कुछ मिनट हैं।

इसलिए, हमने PostgreSQL में तार्किक प्रतिकृति का उपयोग करके तीसरे पक्ष के प्लगइन का उपयोग करके माइग्रेशन का प्रयास करने का निर्णय लिया, जिसे pglogical कहा जाता है।

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

टीएल, डॉ

सब कुछ निकला (बैसाखी के बिना नहीं, उनके बारे में एक लेख)।
आप PostgreSQL संस्करण के भीतर 9.4 से 11.x तक, किसी भी संस्करण से किसी भी, नीचे या ऊपर की ओर माइग्रेट कर सकते हैं।
डाउनटाइम नए डेटाबेस सर्वर को फिर से कनेक्ट करने के लिए आपके एप्लिकेशन के लिए लगने वाले समय के बराबर है (हमारे मामले में, यह पूरे एप्लिकेशन का पुनरारंभ था, लेकिन जंगली में, जाहिर है, "संभव विकल्प")।

"माथे" समाधान हमारे लिए उपयुक्त क्यों नहीं था

जैसा कि हमने पहले ही कहा है, सबसे आसान तरीका है कि पुराने के साथ समानांतर में PostgreSQL सर्वर के नए संस्करण को बढ़ाएं, एप्लिकेशन को रोकें, डेटाबेस को डंप / रिस्टोर (या pg_upgrad) के माध्यम से स्थानांतरित करें और फिर से आवेदन शुरू करें। छोटी मात्रा के डेटाबेस के लिए, सिद्धांत रूप में, यह काफी उपयुक्त विकल्प है (या, सामान्य स्थिति में, वॉल्यूम महत्वहीन है, जब आपके पास पुराने सर्वर से डेटाबेस के "ट्रांसफ्यूजन" की अवधि के लिए आवेदन का डाउनटाइम का विकल्प होता है, नए सर्वर से, चाहे यह कितना भी लंबा हो)। लेकिन हमारे मामले में, डेटाबेस डिस्क पर लगभग 1.5 टीबी लेता है, और इसे हिलाना मिनटों का नहीं, बल्कि कई घंटों का होता है। आवेदन, बदले में, मुकाबला मोड में काम करता है, और मैं वास्तव में कुछ मिनट से अधिक के लिए डाउनटाइम से बचना चाहता था।

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

इसलिए, हमने PostgreSQL में तार्किक प्रतिकृति का उपयोग करके तीसरे पक्ष के प्लगइन का उपयोग करके माइग्रेशन का प्रयास करने का निर्णय लिया, जिसे pglogical कहा जाता है।

सामान्य जानकारी

Pglogical PostgreSQL में देशी लॉजिकल डिकोडिंग का उपयोग करके एक तार्किक प्रतिकृति प्रणाली है और एक PostgreSQL एक्सटेंशन के रूप में कार्यान्वित किया जाता है। आपको सदस्यता / प्रकाशन मॉडल का उपयोग करके चयनात्मक प्रतिकृति को कॉन्फ़िगर करने की अनुमति देता है। यह डेटाबेस में ट्रिगर के निर्माण या प्रतिकृति के लिए किसी भी बाहरी उपयोगिताओं के उपयोग की आवश्यकता नहीं है।

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

मैन्युअल रूप से pglogical का उपयोग करके प्रतिकृति स्थापित करना बहुत तुच्छ नहीं है, हालांकि सिद्धांत रूप में यह बहुत संभव है। सौभाग्य से, कॉन्फ़िगरेशन प्रक्रिया को स्वचालित करने के लिए एक तृतीय-पक्ष उपयोगिता pgrepup है, जिसका हम उपयोग करेंगे।

डिस्क स्पेस मेमो

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

हमारे मामले में, डेटाबेस संशोधनों की आवश्यकता थी, साथ ही 9.6 और 11 के बीच प्रवास के दौरान भंडारण प्रारूप "स्वैप" नवीनतम संस्करण के पक्ष में नहीं था, इसलिए डिस्क स्थान को 2 से नहीं, बल्कि लगभग 2.2 गुना बढ़ाना पड़ा। एलवीएम की प्रशंसा करें, यह मक्खी पर प्रवास की प्रक्रिया में किया जा सकता है।

सामान्य तौर पर, इसका ख्याल रखें।

मास्टर पर PostgreSQL 11 स्थापित करें

नोट: हम ओरेकल लिनक्स का उपयोग करते हैं, और इस वितरण के लिए निम्नलिखित सभी को तेज किया जाएगा। यह संभव है कि अन्य लिनक्स वितरणों को एक फ़ाइल के साथ थोड़ा संशोधन की आवश्यकता होगी, लेकिन यह महत्वपूर्ण होने की संभावना नहीं है।

#   yum install https://download.postgresql.org/pub/repos/yum/11/redhat/rhel-7-x86_64/pgdg-oraclelinux11-11-2.noarch.rpm #   postgresql11 yum install postgresql11 postgresql11-devel postgresql11-server postgresql11-contrib #   /usr/pgsql-11/bin/postgresql-11-setup initdb

पुराना डेटाादार /var/lib/pgsql/9.6/data में स्थित है, नया, तदनुसार, / var / lib / pgsql / 11 / data में है

एक्सेस सेटिंग्स ( pg_hba.conf ) और सर्वर सेटिंग्स ( postgresql.conf ) को 9.6 से 11 तक कॉपी करें।

एक ही मशीन पर दो PostgreSQL सर्वर चलाने के लिए, postgresql.conf 11 कॉन्फ़िगरेशन कॉन्फिगरेशन में, पोर्ट को 15432 (पोर्ट = 15432) में बदलें।

यहां आपको ध्यान से सोचने की ज़रूरत है कि आपको अपने मामले में विशेष रूप से PostgreSQL के नए संस्करण में क्या करने की आवश्यकता है, ताकि यह आपके postgresql.conf से शुरू हो (और आपका आवेदन अंततः इसके साथ काम कर सके)। हमारे मामले में, हमारे द्वारा उपयोग किए जाने वाले PostgreSQL एक्सटेंशन को नए संस्करण में स्थापित करना आवश्यक था। यह लेख के दायरे से परे है, बस नया PostgreSQL स्टार्ट अप करें, काम करें, और पूरी तरह से आपको सूट करें :)

 #  ,  ,  shared libraries, whatever... # .... #  systemctl enable postgresql-11 systemctl start postgresql-11

हम / var / lib / pgsql / 11 / data / pg_log / में देखते हैं । क्या सब ठीक है? हम जारी रखते हैं!

Pgrepup स्थापित और कॉन्फ़िगर करें

 #  python yum install python yum install python2-pip #  pgrepup pip install pgrepup #   pgrepup config

बारीकियों:

App_owner के रूप में हम उस उपयोगकर्ता को निर्दिष्ट करते हैं जिसके तहत PostgreSQL सर्वर चल रहे हैं।
डेटाबेस के लिए, खाका 1 निर्दिष्ट करें।
उपयोगकर्ता नाम और पासवर्ड - सुपरयूज़र एक्सेस के लिए डेटा। हमारे मामले में, ट्रस्ट विधि को पोस्टग्रेज उपयोगकर्ता के स्थानीय कनेक्शन के लिए pg_hba.conf में निर्दिष्ट किया गया था, इसलिए आप मनमाने ढंग से पासवर्ड निर्दिष्ट कर सकते हैं।

प्रतिकृति को कॉन्फ़िगर करें

 #   pgrepup check

हमें कई मापदंडों की सूची का आउटपुट मिलता है जिन्हें आवश्यक रूप से कॉन्फ़िगर किया जाना चाहिए।

उदाहरण सत्यापन परिणाम:

सत्यापन के दौरान सभी त्रुटियों को समाप्त करने की आवश्यकता होगी। दोनों सर्वरों की सेटिंग में Wal_level = LogICAL (कार्य के लिए लॉजिकल डिकोडिंग के लिए) सेट किया जाना चाहिए, प्रतिकृति इंजन के लिए आवश्यक सेटिंग्स (स्लॉट्स और wal_senders की संख्या)। Pgrepup उपयोगिता के संकेत काफी जानकारीपूर्ण हैं, अधिकांश बिंदुओं पर सवाल नहीं उठने चाहिए।

हम सभी आवश्यक सेटिंग्स बनाते हैं जो pgrepup के लिए पूछता है।

दोनों pg_hba.conf फ़ाइलों में हम उस उपयोगकर्ता के लिए अनुमतियाँ जोड़ते हैं जो प्रतिकृति करेंगे, सभी pgrepup प्रॉम्प्ट पर:

 host replication pgrepup_replication 127.0.0.1/32 md5 host all pgrepup_replication 127.0.0.1/32 md5

प्राथमिक कुंजी जोड़ें

कार्य के लिए प्रतिकृति के लिए, एक प्राथमिक कुंजी को सभी तालिकाओं में परिभाषित किया जाना चाहिए।

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

पीके के बिना तालिकाओं की एक सूची, अन्य चीजों के साथ, pgrepup check उत्पादन pgrepup check । इस सूची से सभी तालिकाओं के लिए, आपको किसी भी तरह से एक प्राथमिक कुंजी जोड़ने की आवश्यकता है जो आपको सूट करती है। हमारे मामले में, यह कुछ इस तरह था:

 ALTER TABLE %s ADD COLUMN temporary_pk BIGSERIAL NOT NULL PRIMARY KEY

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

Pglogical एक्सटेंशन स्थापित करें

एक्सटेंशन स्थापित करने के निर्देश यहां देखे जा सकते हैं । एक्सटेंशन को दोनों सर्वरों पर स्थापित किया जाना चाहिए।

 #       curl https://access.2ndquadrant.com/api/repository/dl/default/release/9.6/rpm | bash curl https://access.2ndquadrant.com/api/repository/dl/default/release/11/rpm | bash #   yum install postgresql96-pglogical postgresql11-pglogical

दोनों सर्वरों के postgresql.conf में लाइब्रेरी लोड जोड़ें:

 shared_preload_libraries = 'pglogical'

Pgl_ddl_deploy एक्सटेंशन इंस्टॉल करें

यह एक सहायक विस्तार है जो pgrepup तार्किक DDL प्रतिकृति के लिए उपयोग करता है।

 #      git clone https://github.com/enova/pgl_ddl_deploy.git #       PATH=/usr/pgsql-9.6/bin/:$PATH USE_PGXS=1 make USE_PGXS=1 make install make clean #       PATH=/usr/pgsql-11/bin/:$PATH make CLANG=true make install

दोनों सर्वरों के postgresql.conf में लाइब्रेरी लोड जोड़ें:

 shared_preload_libraries = 'pglogical,pgl_ddl_deploy'

परिवर्तन की जाँच

 #   postgresql systemctl restart postgresql-11

अब pgrepup check का उपयोग करके आपको यह सुनिश्चित करने की आवश्यकता है कि लक्ष्य सर्वर के साथ सब कुछ ठीक हो गया है और लक्ष्य सर्वर के बारे में सभी टिप्पणियां पूरी तरह से समाप्त हो गई हैं।

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

 #  systemctl restart postgresql-9.6 #  pgrepup check

अब कमांड के आउटपुट में, सभी आइटम को ओके के रूप में चिह्नित किया जाना चाहिए।

ऐसा लगता है कि आप प्रवास शुरू कर सकते हैं, लेकिन ...

Pgrepup बग्स को ठीक करें

Pgrepup के वर्तमान संस्करण में कई बग हैं जो प्रवासन को असंभव बनाते हैं। खींचे गए अनुरोध भेजे गए थे, लेकिन अफसोस, उन्हें अनदेखा किया गया है, इसलिए आपको मैन्युअल रूप से सुधार करना होगा।

हम pgrepup स्थापना फ़ोल्डर में जाते हैं (हमारा मामला /usr/lib/python2.7/site-packages/pgrepup/commands/ ) है।

एक बार करो। प्रत्येक * .py फ़ाइल में, फ़ंक्शन विवरण में गायब **kwargs जोड़ें। एक तस्वीर हजार शब्दों से बेहतर है:

यहाँ पर कमिट करें ।

दो कर दो। Setup.py में हम "sh -c", दो प्रविष्टियों के लिए एक खोज करते हैं, सभी मल्टी-लाइन शेल कमांड को सिंगल-लाइन बनाने की आवश्यकता होती है।

यहाँ पर कमिट करें ।

माइग्रेशन शुरू करें

 #  pgrepup setup

इस कमांड के साथ pgrepup प्रतिकृति शुरू करने के लिए दोनों सर्वर तैयार करता है, एक उपयोगकर्ता बनाता है, pglogical को कॉन्फ़िगर करता है, डेटाबेस स्कीमा को स्थानांतरित करता है।

 #   pgrepup start

उसने कहा, "चलो चलें!" और अपना हाथ लहराया:

प्रतिकृति चल रही है। वर्तमान स्थिति को pgrepup status कमांड का उपयोग करके देखा जा सकता है:

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

रास्ते के साथ, आप pgrepup मुखौटा में गहराई से देख सकते हैं और देख सकते हैं कि हुड के नीचे क्या होता है। मन की पूछताछ के लिए, यहां शुरुआती बिंदु के रूप में प्रश्नों की एक सूची है:

 SELECT * FROM pg_replication_origin_status ORDER BY remote_lsn DESC; SELECT *,pg_xlog_location_diff(s.sent_location,s.replay_location) byte_lag FROM pg_stat_replication s; SELECT query FROM pg_stat_activity WHERE application_name='subscription_copy'

काफी कॉफी होने पर (इस लेख को लिखते समय परीक्षण सर्वर पर, ~ 700Gb का डेटा एक दिन के आसपास रहता है), हम अंत में निम्नलिखित चित्र देखते हैं:

और इसका मतलब है कि यह एक नया गुलाम तैयार करने का समय है।

दास पर PostgreSQL 11 स्थापित करें

यहाँ सब कुछ सरल है और पाठ्यपुस्तक के अनुसार कोई भी बारीकियाँ नहीं हैं।

 #   yum install https://download.postgresql.org/pub/repos/yum/11/redhat/rhel-7-x86_64/pgdg-oraclelinux11-11-2.noarch.rpm #  postgresql 11 yum install postgresql11 postgresql11-devel postgresql11-server postgresql11-contrib #      su - postgres pg_basebackup -h db-master.hostname -p 15432 -D /var/lib/pgsql/11/data/ -R -P -U replication -X stream -c fast

एक्सेस सेटिंग्स ( pg_hba.conf ) और सर्वर सेटिंग्स ( postgresql.conf ) को 9.6 से 11. तक कॉपी करें। postgresql.conf 11 संस्करण कॉन्फिगरेशन में, पोर्ट को 15432 में बदलें (port = 15432)

 #  systemctl enable postgresql-11 systemctl start postgresql-11

 #     Master SELECT *,pg_wal_lsn_diff(s.sent_lsn,s.replay_lsn) AS byte_lag FROM pg_stat_replication s; #     Slave SELECT now()-pg_last_xact_replay_timestamp();

उप-योगों

इन सभी प्रक्रियाओं के बाद, हमें यह मुश्किल प्रतिकृति योजना मिलती है:

यहां, अंतिम जांच के रूप में (और, अंत में, यह सिर्फ सुंदर है), आप 9.6 मास्टर डेटाबेस में कुछ अद्यतन कर सकते हैं और यह देख सकते हैं कि इसे अन्य तीन सर्वरों पर कैसे दोहराया जाता है।

PostgreSQL के नए संस्करण में एप्लिकेशन को स्विच करना

अब तक, हमारे एप्लिकेशन को PostgreSQL के नए संस्करण के बारे में कुछ भी संदेह नहीं है, इसे ठीक करने का समय आ गया है। यहां विकल्प केवल दो चीजों पर निर्भर करते हैं:
क्या आप उन्हीं बंदरगाहों पर नई सेवाओं से आगे निकलेंगे, जिन पर पुराने लोगों ने काम किया था,
और क्या आपके एप्लिकेशन को डेटाबेस सर्वर को पुनरारंभ करते समय पुनरारंभ की आवश्यकता होती है।

मज़े के लिए, हम दोनों सवालों के जवाब "हाँ" देंगे और आगे बढ़ेंगे।

हम एप्लिकेशन को रोकते हैं।

 # ,   , : SELECT * FROM pg_stat_activity;

 #    #       sequences. pgrepup stop

 #      pgrepup uninstall

 #  master: #    systemctl disable postgresql-9.6 #   ,  ,  . systemctl stop postgresql-9.6 systemctl stop postgresql-11 #  slave: #    systemctl disable postgresql-9.6 #   ,  ,  . systemctl stop postgresql-9.6 systemctl stop postgresql-11

हम मास्टर और स्लेव के नए संस्करण के postgresql.conf कॉन्फ़िगरेशन में मानक पोर्ट लौटाते हैं।

नए स्लेव पर, हम पुनर्प्राप्ति में पोर्ट को मानक एक में भी बदलते हैं ।conf ।

रास्ते के साथ, निष्क्रिय पुराने संस्करण पर पोर्ट को बदलने के लिए पाप से एक सुझाव है:
हम मास्टर और स्लेव के पुराने संस्करण के postgresql.conf में गैर-मानक पोर्ट को उजागर करते हैं।
पुराने स्लेव पर, हम पुनर्प्राप्ति में एक गैर-मानक पोर्ट को भी बदलते हैं ।conf ।

 #   master systemctl enable postgresql-11 systemctl start postgresql-11 #   slave: systemctl enable postgresql-11 systemctl start postgresql-11

लॉग की जाँच करें।

मास्टर पर प्रतिकृति स्थिति की जाँच करें।

 SELECT *,pg_wal_lsn_diff(s.sent_lsn,s.replay_lsn) AS byte_lag FROM pg_stat_replication s;

हमने एप्लिकेशन लॉन्च किया। हम आधे घंटे के लिए खुश हैं।

और अंत में, इस विषय पर उपयोगी साहित्य:

अ छा!

प्रमुख PostgreSQL विज्ञप्ति के बीच सीमलेस (लगभग) प्रवास तार्किक प्रतिकृति का उपयोग कर