Kubernetes साठी PostgreSQL स्टेटमेंट्स, आमच्या निवडी आणि अनुभवाचे संक्षिप्त अवलोकन

वाढत्या प्रमाणात, ग्राहकांना खालील विनंत्या प्राप्त होत आहेत: “आम्हाला ते Amazon RDS सारखे हवे आहे, परंतु स्वस्त”; "आम्हाला ते RDS सारखे हवे आहे, परंतु सर्वत्र, कोणत्याही पायाभूत सुविधांमध्ये." Kubernetes वर असे व्यवस्थापित समाधान लागू करण्यासाठी, आम्ही PostgreSQL (Stolon, Crunchy Data आणि Zalando चे ऑपरेटर) साठी सर्वात लोकप्रिय ऑपरेटर्सची सद्यस्थिती पाहिली आणि आमची निवड केली.

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

RDS म्हणजे काय

जेव्हा लोक RDS बद्दल बोलतात, तेव्हा आमच्या अनुभवानुसार, त्यांचा अर्थ व्यवस्थापित DBMS सेवा म्हणजे:

1. कॉन्फिगर करणे सोपे;
2. स्नॅपशॉट्ससह कार्य करण्याची आणि त्यांच्याकडून पुनर्संचयित करण्याची क्षमता आहे (शक्यतो समर्थनासह PITR);
3. तुम्हाला मास्टर-स्लेव्ह टोपोलॉजी तयार करण्याची परवानगी देते;
4. विस्तारांची समृद्ध यादी आहे;
5. ऑडिटिंग आणि वापरकर्ता/प्रवेश व्यवस्थापन प्रदान करते.

सर्वसाधारणपणे सांगायचे तर, हातात असलेले कार्य अंमलात आणण्याचे दृष्टिकोन खूप भिन्न असू शकतात, परंतु सशर्त उत्तरेचा मार्ग आपल्या जवळ नाही. (2GIS मधील सहकाऱ्यांनी परिणाम म्हणून समान निष्कर्ष काढला त्याचा प्रयत्न "पोस्टग्रेस-आधारित फेलओव्हर क्लस्टर द्रुतपणे तैनात करण्यासाठी एक साधन तयार करा.")

Kubernetes इकोसिस्टममधील समान समस्यांचे निराकरण करण्यासाठी ऑपरेटर हा एक सामान्य दृष्टीकोन आहे. "फ्लांटा" च्या तांत्रिक संचालकाने कुबर्नेट्समध्ये लॉन्च केलेल्या डेटाबेसच्या संबंधात त्यांच्याबद्दल अधिक तपशीलवार बोलले आहे. डिस्टॉल, मध्ये त्याचा एक अहवाल.

NB: साधे ऑपरेटर द्रुतपणे तयार करण्यासाठी, आम्ही आमच्या मुक्त स्रोत उपयुक्ततेकडे लक्ष देण्याची शिफारस करतो शेल-ऑपरेटर. ते वापरून, तुम्ही गो च्या ज्ञानाशिवाय हे करू शकता, परंतु सिस्टम प्रशासकांना अधिक परिचित मार्गांनी: बॅश, पायथन इ.

PostgreSQL साठी अनेक लोकप्रिय K8s ऑपरेटर आहेत:

• स्टोलॉन;
• कुरकुरीत डेटा PostgreSQL ऑपरेटर;
• झालँडो पोस्टग्रेस ऑपरेटर.

चला त्यांना अधिक बारकाईने पाहूया.

ऑपरेटर निवड

वर नमूद केलेल्या महत्त्वाच्या वैशिष्ट्यांव्यतिरिक्त, आम्ही - कुबर्नेट्स इन्फ्रास्ट्रक्चर ऑपरेशन्स अभियंता या नात्याने - ऑपरेटरकडून पुढील गोष्टींची अपेक्षा केली आहे:

• Git आणि सह उपयोजन सानुकूल संसाधने;
• पॉड विरोधी आत्मीयता समर्थन;
• नोड अॅफिनिटी किंवा नोड सिलेक्टर स्थापित करणे;
• सहनशीलतेची स्थापना;
• ट्यूनिंग क्षमतांची उपलब्धता;
• समजण्यायोग्य तंत्रज्ञान आणि अगदी आदेश.

प्रत्येक बिंदूच्या तपशीलात न जाता (संपूर्ण लेख वाचल्यानंतर तुम्हाला अद्याप त्यांच्याबद्दल प्रश्न असल्यास टिप्पण्यांमध्ये विचारा), मी सर्वसाधारणपणे लक्षात घेईन की क्लस्टर नोड्सच्या स्पेशलायझेशनचे अधिक अचूकपणे वर्णन करण्यासाठी या पॅरामीटर्सची आवश्यकता आहे. त्यांना विशिष्ट अनुप्रयोगांसाठी ऑर्डर करा. अशा प्रकारे आम्ही कामगिरी आणि खर्चाच्या बाबतीत इष्टतम संतुलन साधू शकतो.

आता स्वतः PostgreSQL ऑपरेटर्सकडे वळू.

1. स्टोलॉन

स्टोलॉन मध्ये इटालियन कंपनी Sorint.lab कडून आधीच नमूद केलेला अहवाल DBMS साठी ऑपरेटर्समध्ये एक प्रकारचे मानक मानले जात असे. हा खूप जुना प्रकल्प आहे: त्याचे पहिले सार्वजनिक प्रकाशन नोव्हेंबर 2015 (!) मध्ये झाले आणि GitHub रेपॉजिटरी जवळजवळ 3000 तारे आणि 40+ योगदानकर्ते आहेत.

खरंच, स्टोलन हे विचारशील आर्किटेक्चरचे उत्कृष्ट उदाहरण आहे:

या ऑपरेटरचे डिव्हाइस अहवालात तपशीलवार आढळू शकते किंवा प्रकल्प दस्तऐवजीकरण. सर्वसाधारणपणे, असे म्हणणे पुरेसे आहे की ते वर्णन केलेले सर्व काही करू शकते: फेलओव्हर, पारदर्शक क्लायंट प्रवेशासाठी प्रॉक्सी, बॅकअप... शिवाय, प्रॉक्सी एका एंडपॉईंट सेवेद्वारे प्रवेश प्रदान करतात - खाली चर्चा केलेल्या इतर दोन उपायांपेक्षा वेगळे (त्यांच्या प्रत्येकासाठी दोन सेवा आहेत बेसमध्ये प्रवेश करणे).

तथापि, स्टोलन सानुकूल संसाधने नाहीत, म्हणूनच कुबर्नेट्समध्ये डीबीएमएस उदाहरणे तयार करणे - “हॉट केकसारखे” – सोपे आणि द्रुत आहे अशा प्रकारे ते तैनात केले जाऊ शकत नाही. व्यवस्थापन युटिलिटीद्वारे केले जाते stolonctl, उपयोजन हेल्म चार्टद्वारे केले जाते, आणि सानुकूल परिभाषित केले जातात आणि कॉन्फिगमॅपमध्ये सेट केले जातात.

एकीकडे, असे दिसून आले की ऑपरेटर खरोखर ऑपरेटर नाही (तरीही, तो CRD वापरत नाही). परंतु दुसरीकडे, ही एक लवचिक प्रणाली आहे जी तुम्हाला योग्य वाटेल तसे K8s मध्ये संसाधने कॉन्फिगर करण्याची परवानगी देते.

थोडक्यात, प्रत्येक डेटाबेससाठी स्वतंत्र चार्ट तयार करणे वैयक्तिकरित्या आमच्यासाठी योग्य वाटले नाही. त्यामुळे आम्ही पर्याय शोधू लागलो.

2. कुरकुरीत डेटा PostgreSQL ऑपरेटर

Crunchy डेटा पासून ऑपरेटर, एक तरुण अमेरिकन स्टार्टअप, एक तार्किक पर्याय वाटला. त्याचा सार्वजनिक इतिहास मार्च 2017 मध्ये पहिल्या रिलीझसह सुरू होतो, तेव्हापासून GitHub रेपॉजिटरीला फक्त 1300 तारे आणि 50+ योगदानकर्ते मिळाले आहेत. कुबर्नेट्स 1.15-1.18, OpenShift 3.11+ आणि 4.4+, GKE आणि VMware Enterprise PKS 1.3+ सह काम करण्यासाठी सप्टेंबरमधील नवीनतम रिलीझची चाचणी घेण्यात आली.

Crunchy Data PostgreSQL ऑपरेटरचे आर्किटेक्चर देखील नमूद केलेल्या आवश्यकता पूर्ण करते:

व्यवस्थापन युटिलिटीद्वारे होते pgoतथापि, ते कुबेरनेटसाठी सानुकूल संसाधने व्युत्पन्न करते. म्हणून, ऑपरेटरने आम्हाला संभाव्य वापरकर्ते म्हणून आनंद दिला:

• CRD द्वारे नियंत्रण आहे;
• सोयीस्कर वापरकर्ता व्यवस्थापन (सीआरडी द्वारे देखील);
• इतर घटकांसह एकत्रीकरण कुरकुरीत डेटा कंटेनर सूट — PostgreSQL साठी कंटेनर प्रतिमांचा एक विशेष संग्रह आणि त्याच्यासोबत काम करण्यासाठी उपयुक्तता (pgBackRest, pgAudit, योगदानातील विस्तार इ. समावेश).

तथापि, क्रन्ची डेटावरून ऑपरेटर वापरणे सुरू करण्याच्या प्रयत्नांमुळे अनेक समस्या समोर आल्या:

• सहन करण्याची कोणतीही शक्यता नव्हती - फक्त नोडसेलेक्टर प्रदान केले आहे.
• आम्ही एक स्टेटफुल ऍप्लिकेशन उपयोजित केले असूनही तयार केलेले पॉड हे उपयोजनाचा भाग होते. स्टेटफुलसेट्सच्या विपरीत, डिप्लॉयमेंट डिस्क तयार करू शकत नाही.

शेवटची कमतरता मजेदार क्षणांना कारणीभूत ठरते: चाचणी वातावरणात आम्ही एका डिस्कसह 3 प्रतिकृती चालविण्यास व्यवस्थापित केले स्थानिक स्टोरेज, ज्यामुळे ऑपरेटरने अहवाल दिला की 3 प्रतिकृती कार्यरत आहेत (जरी त्या नसल्या तरी).

या ऑपरेटरचे आणखी एक वैशिष्ट्य म्हणजे त्याचे विविध समर्थन प्रणालींसह तयार केलेले एकत्रीकरण. उदाहरणार्थ, pgAdmin आणि pgBounce, आणि मध्ये स्थापित करणे सोपे आहे दस्तऐवजीकरण पूर्व-कॉन्फिगर केलेले ग्राफाना आणि प्रोमिथियस मानले जातात. अलीकडच्या काळात 4.5.0-beta1 रिलीज करा प्रकल्पासह सुधारित एकीकरण स्वतंत्रपणे नोंदवले जाते pgमॉनिटर, ज्यासाठी ऑपरेटर बॉक्सच्या बाहेर PgSQL मेट्रिक्सचे स्पष्ट व्हिज्युअलायझेशन ऑफर करतो.

तथापि, Kubernetes-व्युत्पन्न संसाधनांच्या विचित्र निवडीमुळे आम्हाला वेगळे उपाय शोधण्याची गरज निर्माण झाली.

3. झालँडो पोस्टग्रेस ऑपरेटर

आम्‍ही झालॅंडोची उत्‍पादने बर्‍याच काळापासून ओळखतो: आम्‍हाला झालेनियम वापरण्‍याचा अनुभव आहे आणि अर्थातच, आम्ही प्रयत्न केला संरक्षक PostgreSQL साठी त्यांचे लोकप्रिय HA समाधान आहे. तयार करण्याच्या कंपनीच्या दृष्टिकोनाबद्दल पोस्टग्रेस ऑपरेटर त्याच्या लेखकांपैकी एक, अलेक्सी क्ल्युकिन यांनी प्रसारित केले पोस्टग्रेस-मंगळवार #5, आणि आम्हाला ते आवडले.

लेखात चर्चा केलेला हा सर्वात तरुण उपाय आहे: पहिले प्रकाशन ऑगस्ट 2018 मध्ये झाले. तथापि, औपचारिक प्रकाशनांची संख्या कमी असूनही, प्रकल्पाने खूप मोठा पल्ला गाठला आहे, GitHub वर 1300+ तारे आणि योगदानकर्त्यांची कमाल संख्या (70+) सह क्रन्ची डेटाच्या सोल्यूशनला लोकप्रियतेमध्ये मागे टाकले आहे.

“अंडर द हुड” हा ऑपरेटर वेळ-चाचणी उपाय वापरतो:

• संरक्षक आणि स्पिलो ड्रायव्हिंगसाठी,
• वाल-ई - बॅकअपसाठी,
• PgBouncer - कनेक्शन पूल म्हणून.

Zalando मधील ऑपरेटर आर्किटेक्चर अशा प्रकारे सादर केले आहे:

ऑपरेटर पूर्णपणे कस्टम रिसोर्सेसद्वारे व्यवस्थापित केला जातो, कंटेनरमधून आपोआप स्टेटफुल सेट तयार करतो, जो नंतर पॉडमध्ये विविध साइडकार जोडून सानुकूलित केला जाऊ शकतो. क्रंची डेटामधील ऑपरेटरच्या तुलनेत हे सर्व एक महत्त्वपूर्ण फायदा आहे.

आम्ही विचाराधीन 3 पर्यायांपैकी Zalando मधील उपाय निवडला असल्याने, अर्जाच्या सरावासह, त्याच्या क्षमतांचे पुढील वर्णन खाली सादर केले जाईल.

झालँडो येथील पोस्टग्रेस ऑपरेटरसह सराव करा

ऑपरेटर तैनात करणे अगदी सोपे आहे: फक्त GitHub वरून वर्तमान प्रकाशन डाउनलोड करा आणि निर्देशिकेतून YAML फायली लागू करा प्रकट होते. वैकल्पिकरित्या, आपण देखील वापरू शकता ऑपरेटरहब.

स्थापनेनंतर, आपण सेटअपबद्दल काळजी करावी लॉग आणि बॅकअपसाठी स्टोरेज. हे ConfigMap द्वारे केले जाते postgres-operator तुम्ही ऑपरेटर स्थापित केलेल्या नेमस्पेसमध्ये. रेपॉजिटरीज कॉन्फिगर केल्यावर, तुम्ही तुमचे पहिले PostgreSQL क्लस्टर तैनात करू शकता.

उदाहरणार्थ, आमचे मानक उपयोजन असे दिसते:

apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
 name: staging-db
spec:
 numberOfInstances: 3
 patroni:
   synchronous_mode: true
 postgresql:
   version: "12"
 resources:
   limits:
     cpu: 100m
     memory: 1Gi
   requests:
     cpu: 100m
     memory: 1Gi
 sidecars:
 - env:
   - name: DATA_SOURCE_URI
     value: 127.0.0.1:5432
   - name: DATA_SOURCE_PASS
     valueFrom:
       secretKeyRef:
         key: password
         name: postgres.staging-db.credentials
   - name: DATA_SOURCE_USER
     value: postgres
   image: wrouesnel/postgres_exporter
   name: prometheus-exporter
   resources:
     limits:
       cpu: 500m
       memory: 100Mi
     requests:
       cpu: 100m
       memory: 100Mi
 teamId: staging
 volume:
   size: 2Gi

हा मॅनिफेस्ट फॉर्ममध्ये साइडकारसह 3 उदाहरणांचा क्लस्टर तैनात करतो postgres_exporter, ज्यावरून आम्ही ऍप्लिकेशन मेट्रिक्स घेतो. जसे आपण पाहू शकता, सर्वकाही अगदी सोपे आहे आणि आपली इच्छा असल्यास, आपण अक्षरशः अमर्यादित क्लस्टर तयार करू शकता.

याकडे लक्ष देणे योग्य आहे वेब प्रशासन पॅनेल - postgres-operator-ui. हे ऑपरेटरसह येते आणि आपल्याला क्लस्टर तयार करण्यास आणि हटविण्यास तसेच ऑपरेटरद्वारे बनविलेल्या बॅकअपसह कार्य करण्यास अनुमती देते.

PostgreSQL क्लस्टरची यादी

बॅकअप व्यवस्थापन

आणखी एक मनोरंजक वैशिष्ट्य समर्थन आहे टीम API. ही यंत्रणा आपोआप तयार होते PostgreSQL मध्ये भूमिका, वापरकर्तानावांच्या परिणामी सूचीवर आधारित. API नंतर तुम्हाला वापरकर्त्यांची सूची परत करण्याची परवानगी देते ज्यांच्यासाठी भूमिका स्वयंचलितपणे तयार केल्या जातात.

समस्या आणि उपाय

तथापि, ऑपरेटरच्या वापरामुळे लवकरच अनेक महत्त्वपूर्ण कमतरता दिसून आल्या:

1. nodeSelector समर्थनाचा अभाव;
2. बॅकअप अक्षम करण्यात अक्षमता;
3. डेटाबेस निर्मिती कार्य वापरताना, डीफॉल्ट विशेषाधिकार दिसत नाहीत;
4. कधीकधी कागदपत्रे गहाळ असतात किंवा कालबाह्य असतात.

सुदैवाने, त्यापैकी बरेच निराकरण केले जाऊ शकते. चला शेवटपासून सुरुवात करूया - यासह समस्या दस्तऐवजीकरण.

बहुधा, आपणास हे तथ्य आढळेल की बॅकअपची नोंदणी कशी करावी आणि बॅकअप बकेटला ऑपरेटर UI शी कसे कनेक्ट करावे हे नेहमीच स्पष्ट नसते. कागदपत्रे याबद्दल बोलतात, परंतु वास्तविक वर्णन त्यात आहे PR:

1. गुप्त करणे आवश्यक आहे;
2. पॅरामीटर म्हणून ऑपरेटरला पास करा pod_environment_secret_name ऑपरेटर सेटिंग्जसह CRD मध्ये किंवा कॉन्फिगमॅपमध्ये (आपण ऑपरेटर कसे स्थापित करायचे यावर अवलंबून).

तथापि, हे बाहेर वळते म्हणून, हे सध्या अशक्य आहे. म्हणूनच आम्ही गोळा केले ऑपरेटरची तुमची आवृत्ती काही अतिरिक्त तृतीय-पक्ष विकासासह. त्याबद्दल अधिक माहितीसाठी, खाली पहा.

आपण ऑपरेटरला बॅकअपसाठी पॅरामीटर्स पास केल्यास, म्हणजे - wal_s3_bucket आणि AWS S3 मध्ये ऍक्सेस की, नंतर ते सर्वकाही बॅकअप घेईल: केवळ उत्पादनातच नाही तर स्टेजिंग देखील. हे आम्हाला शोभत नव्हते.

स्पिलोच्या पॅरामीटर्सच्या वर्णनात, जे ऑपरेटर वापरताना PgSQL साठी मूलभूत डॉकर रॅपर आहे, असे दिसून आले: आपण पॅरामीटर पास करू शकता WAL_S3_BUCKET रिक्त, त्यामुळे बॅकअप अक्षम करणे. शिवाय, मला खूप आनंद झाला तयार पीआर, जे आम्ही लगेच आमच्या काट्यात स्वीकारले. आता आपल्याला फक्त जोडण्याची आवश्यकता आहे enableWALArchiving: false PostgreSQL क्लस्टर संसाधनासाठी.

होय, 2 ऑपरेटर चालवून ते वेगळ्या पद्धतीने करण्याची संधी होती: एक स्टेजिंगसाठी (बॅकअपशिवाय), आणि दुसरा उत्पादनासाठी. पण आम्ही एक करू शकलो.

ठीक आहे, आम्ही S3 साठी डेटाबेसमध्ये प्रवेश कसा हस्तांतरित करायचा ते शिकलो आणि बॅकअप स्टोरेजमध्ये येऊ लागले. ऑपरेटर UI मध्ये बॅकअप पृष्ठ कसे कार्य करावे?

तुम्हाला ऑपरेटर UI मध्ये 3 व्हेरिएबल्स जोडणे आवश्यक आहे:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

यानंतर, बॅकअपचे व्यवस्थापन उपलब्ध होईल, जे आमच्या बाबतीत स्टेजिंगसह कार्य सुलभ करेल, आम्हाला अतिरिक्त स्क्रिप्टशिवाय उत्पादनातून स्लाइस वितरित करण्यास अनुमती देईल.

टीम्स एपीआय सोबत काम करणे आणि ऑपरेटर टूल्स वापरून डेटाबेस आणि भूमिका तयार करण्याच्या भरपूर संधी हा आणखी एक फायदा होता. तथापि, तयार केले भूमिकांना डीफॉल्टनुसार कोणतेही अधिकार नव्हते. त्यानुसार, वाचन अधिकार असलेला वापरकर्ता नवीन तक्ते वाचू शकत नाही.

अस का? कोडमध्ये तथ्य असूनही आहे आवश्यक GRANT, ते नेहमी वापरले जात नाहीत. 2 पद्धती आहेत: syncPreparedDatabases и syncDatabases. द syncPreparedDatabases - विभागातील वस्तुस्थिती असूनही preparedDatabases आहे एक अट आहे defaultRoles и defaultUsers भूमिका तयार करण्यासाठी, डीफॉल्ट अधिकार लागू केले जात नाहीत. आम्ही पॅच तयार करण्याच्या प्रक्रियेत आहोत जेणेकरून हे अधिकार आपोआप लागू होतील.

आणि आमच्याशी संबंधित असलेल्या सुधारणांमधील शेवटचा मुद्दा - पॅच, जे तयार केलेल्या स्टेटफुल सेटमध्ये नोड अॅफिनिटी जोडते. आमचे क्लायंट बर्‍याचदा स्पॉट उदाहरणे वापरून खर्च कमी करण्यास प्राधान्य देतात आणि ते स्पष्टपणे डेटाबेस सेवा होस्ट करणे योग्य नाहीत. या समस्येचे निराकरण सहिष्णुतेद्वारे केले जाऊ शकते, परंतु नोड अॅफिनिटीची उपस्थिती अधिक आत्मविश्वास देते.

काय झालं?

वरील समस्यांचे निराकरण करण्याच्या परिणामांवर आधारित, आम्ही झालँडो येथील पोस्टग्रेस ऑपरेटरला आपले भांडार, जेथे ते अशा उपयुक्त पॅचसह गोळा केले जाते. आणि अधिक सोयीसाठी, आम्ही देखील गोळा केले डॉकर प्रतिमा.

फोर्कमध्ये स्वीकारलेल्या PR ची यादी:

• डॉकरमधील ऑपरेटरसाठी सुरक्षित हलकी प्रतिमा तयार करणे;
• बॅकअप अक्षम करत आहे;
• k8s च्या वर्तमान आवृत्त्यांसाठी संसाधन आवृत्त्या अद्यतनित करत आहे;
• नोड अ‍ॅफिनिटीची अंमलबजावणी.

समुदायाने या PR ला समर्थन दिल्यास ते चांगले होईल जेणेकरून ते ऑपरेटरच्या पुढील आवृत्तीसह अपस्ट्रीम मिळतील (1.6).

बोनस! उत्पादन स्थलांतर यशोगाथा

जर तुम्ही Patroni वापरत असाल, तर थेट उत्पादन कमीत कमी डाउनटाइमसह ऑपरेटरकडे स्थलांतरित केले जाऊ शकते.

स्पिलो तुम्हाला S3 स्टोरेज द्वारे स्टँडबाय क्लस्टर तयार करण्यास अनुमती देते वाल-ई, जेव्हा PgSQL बायनरी लॉग प्रथम S3 मध्ये संग्रहित केला जातो आणि नंतर प्रतिकृतीद्वारे पंप केला जातो. पण आपल्याकडे असल्यास काय करावे नाही जुन्या पायाभूत सुविधांवर Wal-E द्वारे वापरले जाते? या समस्येचे निराकरण आधीच आहे हे सुचवले होते हब वर.

PostgreSQL तार्किक प्रतिकृती बचावासाठी येते. तथापि, आम्ही प्रकाशने आणि सदस्यत्वे कशी तयार करावी याबद्दल तपशीलवार विचार करणार नाही, कारण... आमची योजना फसली होती.

वस्तुस्थिती अशी आहे की डेटाबेसमध्ये लाखो पंक्तींसह अनेक लोड केलेल्या सारण्या होत्या, त्या शिवाय, सतत पुन्हा भरल्या आणि हटविल्या गेल्या. साधी सदस्यता с copy_data, जेव्हा नवीन प्रतिकृती मास्टर कडील सर्व सामग्री कॉपी करते, तेव्हा ती फक्त मास्टर सोबत राहू शकत नाही. सामग्री कॉपी करणे एक आठवडा काम केले, परंतु मास्टरकडे कधीही पकडले नाही. शेवटी, याने मला समस्या सोडवण्यास मदत केली लेख Avito मधील सहकारी: तुम्ही वापरून डेटा ट्रान्सफर करू शकता pg_dump. मी या अल्गोरिदमच्या आमच्या (किंचित सुधारित) आवृत्तीचे वर्णन करेन.

कल्पना अशी आहे की तुम्ही विशिष्ट प्रतिकृती स्लॉटशी जोडलेले अक्षम केलेले सदस्यत्व बनवू शकता आणि नंतर व्यवहार क्रमांक दुरुस्त करू शकता. उत्पादन कार्यासाठी प्रतिकृती उपलब्ध होत्या. हे महत्त्वाचे आहे कारण प्रतिकृती सातत्यपूर्ण डंप तयार करण्यात मदत करेल आणि मास्टरकडून बदल प्राप्त करणे सुरू ठेवेल.

स्थलांतर प्रक्रियेचे वर्णन करणार्‍या पुढील आज्ञा खालील होस्ट नोटेशन्स वापरतील:

1. मास्टर - स्त्रोत सर्व्हर;
2. प्रतिकृती1 — जुन्या उत्पादनावर स्ट्रीमिंग प्रतिकृती;
3. प्रतिकृती2 - नवीन तार्किक प्रतिकृती.

स्थलांतर योजना

1. स्कीमामधील सर्व सारण्यांसाठी मास्टरवर सदस्यता तयार करा public पाया dbname:

psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"

2. मास्टरवर प्रतिकृती स्लॉट तयार करा:

psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"

3. जुन्या प्रतिकृतीवरील प्रतिकृती थांबवा:

psql -h replica1 -c "select pg_wal_replay_pause();"

4. मास्टरकडून व्यवहार क्रमांक मिळवा:

psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"

5. जुन्या प्रतिकृतीतून डंप काढा. आम्ही हे अनेक थ्रेड्समध्ये करू, जे प्रक्रियेस गती देण्यास मदत करेल:

pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname

6. नवीन सर्व्हरवर डंप अपलोड करा:

pg_restore -h replica2 -F d -j 8 -d dbname dump/

7. डंप डाउनलोड केल्यानंतर, तुम्ही स्ट्रीमिंग प्रतिकृतीवर प्रतिकृती सुरू करू शकता:

psql -h replica1 -c "select pg_wal_replay_resume();"

७. नवीन लॉजिकल प्रतिकृतीवर सबस्क्रिप्शन तयार करूया:

psql -h replica2 -c "create subscription oldprod connection 'host=replica1 port=5432 user=postgres password=secret dbname=dbname' publication dbname with (enabled = false, create_slot = false, copy_data = false, slot_name='repl');"

8. चला मिळवूया oid सदस्यता:

psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"

9. समजा ते प्राप्त झाले oid=1000. सबस्क्रिप्शनवर व्यवहार क्रमांक लागू करूया:

psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"

10. प्रतिकृती सुरू करूया:

psql -h replica2 -d dbname -c "alter subscription oldprod enable;"

11. सदस्यता स्थिती तपासा, प्रतिकृती कार्य करेल:

psql -h replica2 -d dbname -c "select * from pg_replication_origin_status;"
psql -h master -d dbname -c "select slot_name, restart_lsn, confirmed_flush_lsn from pg_replication_slots;"

12. प्रतिकृती सुरू केल्यानंतर आणि डेटाबेस सिंक्रोनाइझ झाल्यानंतर, तुम्ही बदलू शकता.

13. प्रतिकृती अक्षम केल्यानंतर, तुम्हाला अनुक्रम दुरुस्त करणे आवश्यक आहे. हे चांगले वर्णन केले आहे wiki.postgresql.org वरील लेखात.

या योजनेबद्दल धन्यवाद, स्विचओव्हर कमीतकमी विलंबाने झाला.

निष्कर्ष

Kubernetes ऑपरेटर तुम्हाला K8s संसाधनांच्या निर्मितीमध्ये कमी करून विविध क्रिया सुलभ करण्याची परवानगी देतात. तथापि, त्यांच्या मदतीने उल्लेखनीय ऑटोमेशन प्राप्त केल्यामुळे, हे लक्षात ठेवण्यासारखे आहे की ते अनेक अनपेक्षित बारकावे देखील आणू शकतात, म्हणून आपले ऑपरेटर हुशारीने निवडा.

PostgreSQL साठी तीन सर्वात लोकप्रिय Kubernetes ऑपरेटर विचारात घेतल्यानंतर, आम्ही Zalando मधील प्रकल्प निवडला. आणि आम्हाला काही अडचणींवर मात करावी लागली, परंतु परिणाम खरोखरच आनंददायी होता, म्हणून आम्ही हा अनुभव काही इतर PgSQL इंस्टॉलेशन्समध्ये वाढवण्याची योजना आखत आहोत. तुम्हाला तत्सम उपाय वापरण्याचा अनुभव असल्यास, टिप्पण्यांमधील तपशील पाहून आम्हाला आनंद होईल!

PS

आमच्या ब्लॉगवर देखील वाचा:

• «डेटाबेस आणि कुबर्नेट्स (पुनरावलोकन आणि व्हिडिओ अहवाल)";
• «पोस्टग्रेस मंगळवार #5: PostgreSQL आणि Kubernetes. CI/CD. चाचणी ऑटोमेशन";
• «K8s मधील Redis ऑपरेटरसह एक कथा आणि या डेटाबेसमधील डेटाचे विश्लेषण करण्यासाठी उपयुक्ततेचे एक लहान-पुनरावलोकन».

स्त्रोत: www.habr.com