WAL-G कडून बॅकअप. 2019 मध्ये काय आहे? आंद्रे बोरोडिन

मी सुचवितो की तुम्ही 2019 च्या सुरुवातीपासूनच्या अहवालाचा उतारा आंद्रे बोरोडिन यांनी वाचा "WAL-G सह बॅकअप. 2019 मध्ये काय आहे?"

सर्वांना नमस्कार! माझे नाव आंद्रे बोरोडिन आहे. मी यांडेक्सचा विकासक आहे. मला 2016 पासून PostgreSQL मध्ये स्वारस्य आहे, जेव्हा मी विकसकांशी बोललो आणि त्यांनी सांगितले की सर्वकाही सोपे आहे - तुम्ही स्त्रोत कोड घ्या आणि तो तयार करा आणि सर्वकाही कार्य करेल. आणि तेव्हापासून मी थांबू शकत नाही - मी सर्व प्रकारच्या वेगवेगळ्या गोष्टी लिहितो.

मी ज्या गोष्टींवर काम करत आहे त्यापैकी एक म्हणजे बॅकअप सिस्टम. WAL-G. सर्वसाधारणपणे, Yandex वर आम्ही PostgreSQL मधील बॅकअप सिस्टमवर बर्याच काळापासून काम करत आहोत. आणि आम्ही बॅकअप सिस्टम कसे बनवतो यावरील सहा अहवालांची मालिका तुम्हाला इंटरनेटवर सापडेल. आणि दरवर्षी ते थोडेसे विकसित होतात, थोडे विकसित होतात आणि अधिक विश्वासार्ह बनतात.

पण आजचा अहवाल हा केवळ आम्ही काय केले याबद्दल नाही तर ते किती सोपे आहे आणि काय आहे याबद्दल देखील आहे. तुमच्यापैकी किती जणांनी आधीच WAL-G बद्दलचे माझे अहवाल पाहिले आहेत? काही लोकांनी पाहिले नाही हे चांगले आहे, कारण मी सर्वात सोप्या गोष्टीपासून सुरुवात करेन.

जर अचानक तुमच्याकडे PostgreSQL क्लस्टर असेल, आणि मला वाटते की प्रत्येकाकडे त्यांच्यापैकी एक दोन असतील, आणि अचानक अद्याप कोणतीही बॅकअप सिस्टम नसेल, तर तुम्हाला कोणतेही S3 स्टोरेज किंवा Google Cloud सुसंगत स्टोरेज मिळणे आवश्यक आहे.

उदाहरणार्थ, तुम्ही आमच्या स्टँडवर येऊन Yandex Object Storage साठी प्रमोशनल कोड घेऊ शकता, जो S3 सुसंगत आहे.

मग एक बादली तयार करा. हे फक्त माहितीसाठी कंटेनर आहे.

सेवा वापरकर्ता तयार करा.

सेवा वापरकर्त्यासाठी प्रवेश की तयार करा: aws-s3-key.

WAL-G चे नवीनतम स्थिर प्रकाशन डाउनलोड करा.

आमचे प्री-रिलीझ रिलीझपेक्षा वेगळे कसे आहेत? मला अनेकदा लवकर सोडण्यास सांगितले जाते. आणि जर आवृत्तीमध्ये पुरेसा वेळ नसेल, उदाहरणार्थ, एक महिना, तर मी ते सोडतो. हे आहे नोव्हेंबरचे प्रकाशन. आणि याचा अर्थ असा आहे की दर महिन्याला आम्हाला काही प्रकारचे बग आढळले, सामान्यत: गंभीर नसलेल्या कार्यक्षमतेमध्ये, परंतु आम्ही अद्याप रिलीझ केलेले नाही. मागील आवृत्ती फक्त नोव्हेंबर आहे. त्यात आम्हाला कोणतेही बग माहीत नाहीत, म्हणजे प्रकल्प जसजसा पुढे जात आहे तसतसे बग जोडले गेले.

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

यानंतर, तुम्ही तुमचा पहिला बॅकअप घेऊ शकता. WAL-G मध्ये "बॅकअप-पुश" म्हणा आणि WAL-G मध्ये तुमच्या क्लस्टरचे pgdata स्थान निर्दिष्ट करा. आणि बहुधा, PostgreSQL तुम्हाला सांगेल, जर तुमच्याकडे आधीच बॅकअप सिस्टम नसेल, तर तुम्हाला "आर्काइव्ह-मोड" सक्षम करणे आवश्यक आहे.

याचा अर्थ असा की तुम्हाला सेटिंग्जमध्ये जाऊन “archive_mode = on” चालू करावे लागेल आणि “archive_command” जोडावे लागेल, जो WAL-G मध्ये देखील एक सबकमांड आहे. परंतु काही कारणास्तव लोक या विषयावर बार स्क्रिप्ट वापरतात आणि ते WAL-G भोवती गुंडाळतात. कृपया असे करू नका. WAL-G मध्ये आढळलेली कार्यक्षमता वापरा. तुमचे काही चुकत असेल तर लिहा GitHub. WAL-G असे गृहीत धरते की हा एकमेव प्रोग्राम आहे जो archive_command मध्ये चालतो.

आम्ही WAL-G चा वापर प्रामुख्याने Yandex डेटाबेस व्यवस्थापनामध्ये उच्च उपलब्धता क्लस्टर तयार करण्यासाठी करतो.

आणि हे सहसा एका मास्टरच्या टोपोलॉजी आणि अनेक प्रतिकृतींमध्ये वापरले जाते. त्याच वेळी, ते यांडेक्स ऑब्जेक्ट स्टोरेजमध्ये बॅकअप प्रत बनवते.

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

सामान्यतः, नवीन नोड जोडताना आम्हाला बॅकअप सिस्टम कार्यक्षमतेची आवश्यकता असते. ते महत्त्वाचे का आहे? सामान्यतः लोक क्लस्टरमध्ये नवीन नोड जोडतात कारण विद्यमान क्लस्टर रीड लोड हाताळू शकत नाही. त्यांना नवीन प्रतिकृती जोडणे आवश्यक आहे. आम्ही pg_basebackup वरून मास्टरवर लोड जोडल्यास, मास्टर कोसळू शकतो. म्हणून, आमच्यासाठी हे खूप महत्वाचे होते की आम्ही मास्टरवर कमीत कमी लोड तयार करून, आर्काइव्हमधून एक नवीन नोड त्वरीत अपलोड करू शकतो.

आणि आणखी एक समान परिस्थिती. कनेक्टिव्हिटी तुटलेल्या डेटा सेंटरवरून क्लस्टर मास्टर स्विच केल्यानंतर जुने मास्टर पुन्हा सुरू करण्याची गरज आहे.

• परिणामी, कॉपी सिस्टमसाठी आवश्यकता तयार करताना, आम्हाला समजले की क्लाउडमध्ये कार्यरत असताना pg_basebackup आमच्यासाठी योग्य नाही.
• आम्हाला आमचा डेटा संकुचित करायचा होता. परंतु बॉक्समध्ये जे येते त्याव्यतिरिक्त जवळजवळ कोणतीही बॅकअप प्रणाली डेटा कॉम्प्रेशन प्रदान करेल.
• आम्हाला सर्वकाही समांतर करायचे आहे कारण क्लाउडमधील वापरकर्ता मोठ्या प्रमाणात प्रोसेसर कोर खरेदी करतो. परंतु जर आपल्याकडे काही ऑपरेशनमध्ये समांतरता नसेल तर मोठ्या संख्येने कोर निरुपयोगी ठरतात.
• आम्हाला एन्क्रिप्शन आवश्यक आहे कारण बहुतेकदा डेटा आमचा नसतो आणि स्पष्ट मजकूरात संग्रहित केला जाऊ शकत नाही. तसे, WAL-G मध्ये आमचे योगदान एन्क्रिप्शनने सुरू झाले. आम्ही WAL-G मध्ये एन्क्रिप्शन पूर्ण केले, त्यानंतर आम्हाला विचारण्यात आले: "कदाचित आमच्यापैकी कोणीतरी प्रकल्प विकसित करेल?" आणि तेव्हापासून मी एक वर्षाहून अधिक काळ WAL-G सह काम करत आहे.
• आम्हाला रिसोर्स थ्रॉटलिंगची देखील गरज होती, कारण कालांतराने क्लाउड वापरल्याने, आम्हाला आढळले की काहीवेळा लोकांवर रात्रीच्या वेळी किराणा सामानाचा भार असतो आणि या भारात हस्तक्षेप केला जाऊ शकत नाही. म्हणूनच आम्ही संसाधन थ्रॉटलिंग जोडले आहे.
• तसेच सूची आणि व्यवस्थापन.
• आणि पडताळणी.

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

आणि विद्यमान प्रणालींचे परीक्षण केल्यावर, आम्ही या निष्कर्षावर पोहोचलो की आम्ही WAL-G विकसित करू. तेव्हा तो एक नवीन प्रकल्प होता. बॅकअप सिस्टमच्या क्लाउड इन्फ्रास्ट्रक्चरच्या दिशेने विकासावर प्रभाव पाडणे खूप सोपे होते.

आपण ज्या मुख्य विचारसरणीचे पालन करतो ती म्हणजे WAL-G हे बाललाईकासारखे सोपे असावे.

WAL-G मध्ये 4 कमांड आहेत. हे:

वॉल-पुश - शाफ्ट संग्रहित करा.

वॉल-फेच - एक शाफ्ट मिळवा.

बॅकअप-पुश - बॅकअप घ्या.

बॅकअप-फेच - बॅकअप सिस्टममधून बॅकअप घ्या.

खरं तर, WAL-G कडे या बॅकअपचे व्यवस्थापन देखील आहे, म्हणजे इतिहासातील रेकॉर्ड आणि बॅकअप सूचीबद्ध करणे आणि हटवणे ज्याची या क्षणी आवश्यकता नाही.

डेल्टा कॉपी तयार करणे हे आमच्यासाठी महत्त्वाचे कार्य आहे.

डेल्टा कॉपी म्हणजे आम्ही संपूर्ण क्लस्टरचा संपूर्ण बॅकअप तयार करत नाही, तर क्लस्टरमधील बदललेल्या फाइल्सची फक्त बदललेली पृष्ठे तयार करतो. असे दिसते की कार्यात्मकदृष्ट्या हे WAL वापरून पुनर्प्राप्त करण्याच्या क्षमतेसारखेच आहे. पण आम्ही WAL सिंगल-थ्रेडेड डेल्टा बॅकअप समांतर रोल अप करू शकतो. त्यानुसार, जेव्हा आम्ही शनिवारी बेसिक बॅकअप घेतो, डेल्टा बॅकअप रोज घेतो आणि गुरुवारी आम्ही अयशस्वी होतो, तेव्हा आम्हाला 4 डेल्टा बॅकअप आणि WAL चे 10 तास रोल अप करावे लागतात. डेल्टा बॅकअप समांतर रोल केल्यामुळे यास सुमारे समान वेळ लागेल.

LSN-आधारित डेल्टा - याचा अर्थ असा की बॅकअप तयार करताना, ते बदलले आहे हे समजून घेण्यासाठी आम्हाला प्रत्येक पृष्ठ एकत्र करणे आणि मागील बॅकअपच्या LSN बरोबर त्याचे LSN तपासणे आवश्यक आहे. कोणतेही पृष्ठ ज्यामध्ये संभाव्यतः बदललेला डेटा असू शकतो तो डेल्टा बॅकअपमध्ये उपस्थित असावा.

मी म्हटल्याप्रमाणे, समांतरतेकडे बरेच लक्ष दिले गेले.

परंतु PostgreSQL मधील संग्रहण API सुसंगत आहे. PostgreSQL एक WAL फाइल संग्रहित करते आणि ती पुनर्संचयित करताना एका WAL फाइलची विनंती करते. पण जेव्हा डेटाबेस "WAL-FETCH" कमांड वापरून एका WAL फाइलची विनंती करतो, तेव्हा आम्ही "WAL-PREFETCH" कमांडला कॉल करतो, जे समांतरपणे ऑब्जेक्ट स्टोअरमधून डेटा आणण्यासाठी पुढील 8 फाइल्स तयार करते.

आणि जेव्हा डेटाबेस आम्हाला एक फाईल संग्रहित करण्यास सांगते, तेव्हा आम्ही archive_status पाहतो आणि इतर WAL फाइल्स आहेत का ते पाहतो. आणि आम्ही समांतर WAL डाउनलोड करण्याचा प्रयत्न करत आहोत. हे लक्षणीय कार्यप्रदर्शन लाभ प्रदान करते आणि संग्रहित न केलेल्या WAL च्या संख्येतील अंतर लक्षणीयरीत्या कमी करते. अनेक बॅकअप सिस्टम डेव्हलपरचा असा विश्वास आहे की ही एक धोकादायक प्रणाली आहे कारण आम्ही पोस्टग्रेएसक्यूएल API नसलेल्या कोडच्या इंटर्नल्सच्या आमच्या ज्ञानावर अवलंबून असतो. PostgreSQL आमच्यासाठी archive_status फोल्डरच्या उपस्थितीची हमी देत ​​नाही आणि शब्दार्थाची, WAL फायलींसाठी सज्जता सिग्नलची हमी देत ​​नाही. तरीसुद्धा, आम्ही स्त्रोत कोडचा अभ्यास करत आहोत, आम्ही पाहतो की हे असे आहे आणि आम्ही त्याचा फायदा घेण्याचा प्रयत्न करीत आहोत. आणि PostgreSQL ज्या दिशेने विकसित होत आहे त्या दिशेने आम्ही नियंत्रण ठेवतो; जर अचानक ही यंत्रणा खंडित झाली तर आम्ही ते वापरणे थांबवू.

त्याच्या शुद्ध स्वरूपात, LSN-आधारित WAL डेल्टाला कोणतीही क्लस्टर फाइल वाचणे आवश्यक आहे ज्याचा फाइल सिस्टममधील मोड-टाइम मागील बॅकअपपासून बदलला आहे. आम्ही यासह बराच काळ जगलो, जवळजवळ एक वर्ष. आणि शेवटी आम्ही या निष्कर्षावर पोहोचलो की आमच्याकडे WAL डेल्टा आहेत.

याचा अर्थ असा की प्रत्येक वेळी जेव्हा आम्ही मास्टरवर WAL संग्रहित करतो, तेव्हा आम्ही केवळ ते संकुचित करतो, कूटबद्ध करतो आणि नेटवर्कवर पाठवतो, परंतु त्याच वेळी आम्ही ते वाचतो. आम्ही त्यातील नोंदींचे विश्लेषण आणि वाचन करतो. आम्ही समजतो की कोणते ब्लॉक बदलले आहेत आणि डेल्टा फाइल्स गोळा करतात.

डेल्टा फाइल WAL फायलींच्या विशिष्ट श्रेणीचे वर्णन करते, WAL च्या या श्रेणीमध्ये कोणते ब्लॉक बदलले गेले आहेत याबद्दल माहितीचे वर्णन करते. आणि मग या डेल्टा फाइल्स देखील संग्रहित केल्या जातात.

येथे आम्हाला या वस्तुस्थितीचा सामना करावा लागत आहे की आम्ही सर्व काही त्वरीत समांतर केले, परंतु आम्ही समांतरपणे अनुक्रमिक इतिहास वाचू शकत नाही, कारण एका विशिष्ट विभागात आम्हाला मागील डब्ल्यूएएल रेकॉर्डचा शेवट येऊ शकतो, ज्याशी आमच्याकडे अद्याप कनेक्ट करण्यासाठी काहीही नाही, कारण समांतर वाचनामुळे आपण प्रथम भविष्याचे विश्लेषण करतो, ज्याला अद्याप भूतकाळ नाही.

परिणामी, आम्हाला _delta_partial फाइल्समध्ये न समजणारे तुकडे टाकावे लागले. परिणामी, जेव्हा आपण भूतकाळाकडे परत जाऊ, तेव्हा आपण डब्ल्यूएएल रेकॉर्डचे तुकडे एकामध्ये चिकटवू, त्यानंतर आपण त्याचे विश्लेषण करू आणि त्यात काय बदल झाले ते समजून घेऊ.

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

परिणामी, आमच्या सर्व दुःखामुळे आम्ही WAL-G पार्सिंग लायब्ररी उघडली. माझ्या माहितीनुसार, अद्याप कोणीही ते वापरत नाही, परंतु कोणाला ते लिहायचे असेल आणि वापरायचे असेल तर ते सार्वजनिक डोमेनमध्ये आहे. (अपडेट केलेली लिंक https://github.com/wal-g/wal-g/tree/master/internal/walparser)

परिणामी, सर्व माहिती प्रवाह खूपच क्लिष्ट दिसतात. आमचे मास्टर शाफ्ट संग्रहित करतात आणि डेल्टा फायली संग्रहित करतात. आणि बॅकअप प्रत बनवणार्‍या प्रतिकृतीला बॅकअप दरम्यान गेलेल्या वेळेत डेल्टा फाइल्स मिळाल्या पाहिजेत. या प्रकरणात, इतिहासाचे काही भाग मोठ्या प्रमाणात जोडणे आणि विश्लेषित करणे आवश्यक आहे, कारण संपूर्ण इतिहास मोठ्या विभागांमध्ये बसत नाही. आणि यानंतरच प्रतिकृती संपूर्ण डेल्टा बॅकअप संग्रहित करू शकते.

आलेखांवर सर्व काही अगदी सोपे दिसते. हे आमच्या वास्तविक क्लस्टर्सपैकी एक डाउनलोड आहे. आमच्याकडे LSN-आधारित, एका दिवसात बनवलेले आहे. आणि आम्ही पाहतो की LSN-आधारित डेल्टा बॅकअप पहाटे तीन ते पहाटे पाच वाजेपर्यंत चालू होता. प्रोसेसर कोरच्या संख्येत हा भार आहे. डब्ल्यूएएल-डेल्टाने आम्हाला येथे सुमारे 20 मिनिटे लागली. म्हणजेच ते लक्षणीय वेगवान झाले, परंतु त्याच वेळी नेटवर्कवर अधिक तीव्र देवाणघेवाण झाली.

डेटाबेसच्या इतिहासात कोणते ब्लॉक्स बदलले आणि कोणत्या वेळी बदलले याबद्दल आमच्याकडे माहिती असल्याने, आम्ही पुढे गेलो आणि कार्यक्षमता समाकलित करण्याचा निर्णय घेतला - "pg_prefaulter" नावाचा PostgreSQL विस्तार.

याचा अर्थ असा की जेव्हा स्टँड-बाय बेस रिस्टोर कमांड कार्यान्वित करतो, तेव्हा ते WAL-G ला पुढील WAL फाइल आणण्यास सांगते. नजीकच्या भविष्यात WAL पुनर्प्राप्ती प्रक्रिया कोणत्या डेटा ब्लॉक्समध्ये प्रवेश करेल आणि या ब्लॉक्सवर वाचन ऑपरेशन सुरू करेल हे आम्हाला समजते. एसएसडी नियंत्रकांची कार्यक्षमता वाढवण्यासाठी हे केले गेले. कारण डब्ल्यूएएल रोल त्या पानावर पोहोचेल जे बदलणे आवश्यक आहे. हे पृष्ठ डिस्कवर आहे आणि पृष्ठ कॅशेमध्ये नाही. आणि हे पृष्ठ येण्याची तो समकालिकपणे प्रतीक्षा करेल. पण जवळच WAL-G आहे, ज्याला माहित आहे की WAL च्या पुढील काही शंभर मेगाबाइट्समध्ये आपल्याला विशिष्ट पृष्ठांची आवश्यकता असेल आणि त्याच वेळी ते उबदार होऊ लागतात. एकाधिक डिस्क प्रवेश सुरू करते जेणेकरून ते समांतरपणे कार्यान्वित केले जातील. हे SSD ड्राइव्हवर चांगले कार्य करते, परंतु, दुर्दैवाने, हे हार्ड ड्राइव्हसाठी पूर्णपणे लागू नाही, कारण आम्ही केवळ आमच्या प्रॉम्प्टसह त्यात हस्तक्षेप करतो.

हे आता कोडमध्ये आहे.

अशी वैशिष्ट्ये आहेत जी आम्ही जोडू इच्छितो.

हे चित्र दर्शविते की WAL-डेल्टाला तुलनेने कमी वेळ लागतो. आणि हे दिवसभरात डेटाबेसमध्ये झालेले बदल वाचत आहे. आम्ही डब्ल्यूएएल-डेल्टा केवळ रात्रीच करू शकत नाही, कारण तो आता लोडचा महत्त्वपूर्ण स्रोत नाही. आम्ही दर मिनिटाला WAL-delta वाचू शकतो कारण ते स्वस्त आहे. एका मिनिटात आपण क्लस्टरमध्ये झालेले सर्व बदल स्कॅन करू शकतो. आणि याला "झटपट वाल-डेल्टा" म्हटले जाऊ शकते.

मुद्दा असा आहे की जेव्हा आम्ही क्लस्टर पुनर्संचयित करतो, तेव्हा आम्ही कथांची संख्या कमी करतो ज्या आम्हाला अनुक्रमे रोल अप कराव्या लागतात. म्हणजेच, PostgreSQL रोल करणारी WAL चे प्रमाण कमी केले पाहिजे, कारण यास बराच वेळ लागतो.

पण एवढेच नाही. जर आम्हाला माहित असेल की काही ब्लॉक बॅकअप सुसंगततेच्या बिंदूवर बदलले जातील, तर आम्ही ते भूतकाळात बदलू शकत नाही. म्हणजेच, आता आमच्याकडे WAL-डेल्टा फॉरवर्डिंगचे फाइल-बाय-फाइल ऑप्टिमायझेशन आहे. याचा अर्थ असा की, उदाहरणार्थ, मंगळवारी एखादे टेबल पूर्णपणे हटवले गेले असेल किंवा काही फायली टेबलमधून पूर्णपणे हटवल्या गेल्या असतील, तर जेव्हा डेल्टा सोमवारी आणि शनिवारचा pg_basebackup पुनर्संचयित केला जाईल, तेव्हा आम्ही हा डेटा तयार करणार नाही.

आम्हाला हे तंत्रज्ञान पृष्ठ स्तरापर्यंत वाढवायचे आहे. म्हणजेच, जर फाइलचा काही भाग सोमवारी बदलला, परंतु बुधवारी अधिलिखित केला जाईल, तर गुरुवारी एखाद्या बिंदूवर पुनर्संचयित करताना, आम्हाला पृष्ठांच्या पहिल्या काही आवृत्त्या डिस्कवर लिहिण्याची आवश्यकता नाही.

पण ही अजूनही एक कल्पना आहे जी आपल्यामध्ये सक्रियपणे चर्चा केली जात आहे, परंतु ती अद्याप संहितेपर्यंत पोहोचलेली नाही.

आम्हाला WAL-G मध्ये आणखी एक वैशिष्ट्य बनवायचे आहे. आम्‍हाला ते एक्स्टेंसिबल बनवायचे आहे कारण आम्‍हाला वेगवेगळ्या डेटाबेसला सपोर्ट करण्‍याची आवश्‍यकता आहे आणि त्‍याच प्रकारे बॅकअप व्‍यवस्‍थापनाशी संपर्क साधण्‍याची आमची इच्छा आहे. परंतु समस्या अशी आहे की MySQL API पूर्णपणे भिन्न आहेत. MySQL मध्ये, PITR भौतिक WAL लॉगवर आधारित नाही, तर binlog वर आधारित आहे. आणि आमच्याकडे MySQL मध्ये अशी संग्रहण प्रणाली नाही जी काही बाह्य प्रणालीला सांगेल की हा बिनलॉग पूर्ण झाला आहे आणि संग्रहित करणे आवश्यक आहे. आम्हाला डेटाबेससह क्रॉनमध्ये कुठेतरी उभे राहून काही तयार आहे का ते तपासावे लागेल?

आणि त्याच प्रकारे, MySQL पुनर्संचयित करताना, अशी कोणतीही रीस्टोर कमांड नाही जी सिस्टमला सांगू शकेल की मला अशा आणि अशा फाइल्सची आवश्यकता आहे. तुम्ही तुमच्या क्लस्टरची पुनर्बांधणी सुरू करण्यापूर्वी, तुम्हाला कोणत्या फाइल्सची आवश्यकता आहे हे जाणून घेणे आवश्यक आहे. तुम्हाला कोणत्या फाईल्सची आवश्यकता असेल याचा अंदाज तुम्ही स्वतः घ्यावा. परंतु या समस्या कशा प्रकारे तरी दूर केल्या जाऊ शकतात. (स्पष्टीकरण: MySQL आधीच समर्थित आहे)

अहवालात, मला त्या प्रकरणांबद्दल देखील बोलायचे होते जेव्हा WAL-G तुमच्यासाठी योग्य नाही.

तुमच्याकडे सिंक्रोनस प्रतिकृती नसल्यास, शेवटचा विभाग संरक्षित केला जाईल याची WAL-G हमी देत ​​नाही. आणि जर संग्रहण इतिहासाच्या शेवटच्या काही विभागांच्या मागे राहिल्यास, तो धोका आहे. सिंक्रोनस प्रतिकृती नसल्यास, मी WAL-G वापरण्याची शिफारस करणार नाही. तरीही, हे मुख्यत्वे क्लाउड इंस्टॉलेशनसाठी डिझाइन केलेले आहे, जे सिंक्रोनस प्रतिकृतीसह उच्च उपलब्धता समाधान सूचित करते, जे वचनबद्ध केलेल्या शेवटच्या बाइट्सच्या सुरक्षिततेसाठी जबाबदार आहे.

मी अनेकदा लोकांना WAL-G आणि WAL-E दोन्ही एकाच वेळी चालवण्याचा प्रयत्न करताना पाहतो. WAL-G WAL-E वरून फाइल पुनर्संचयित करू शकते आणि WAL-E मध्ये बनवलेला बॅकअप पुनर्संचयित करू शकते या अर्थाने आम्ही बॅकवर्ड सुसंगततेचे समर्थन करतो. परंतु या दोन्ही प्रणाली समांतर वॉल-पुश वापरत असल्याने ते एकमेकांकडून फाईल्स चोरण्यास सुरुवात करतात. आम्ही WAL-G मध्ये त्याचे निराकरण केल्यास, ते अद्याप WAL-E मध्येच राहील. WAL-E मध्ये, ते संग्रहण-स्थिती पाहते, पूर्ण झालेल्या फायली पाहते आणि संग्रहित करते, तर इतर प्रणालींना ही WAL फाइल अस्तित्वात आहे हे कळणार नाही, कारण PostgreSQL दुसऱ्यांदा संग्रहित करण्याचा प्रयत्न करणार नाही.

WAL-G बाजूने आम्ही येथे काय निराकरण करणार आहोत? आम्ही PostgreSQL ला कळवणार नाही की ही फाईल समांतरपणे हस्तांतरित केली गेली आहे आणि जेव्हा PostgreSQL आम्हाला ती संग्रहित करण्यास सांगेल, तेव्हा आम्हाला आधीच कळेल की या मोड-टाइमसह आणि या md5 सह अशी फाइल आधीच संग्रहित केली गेली आहे आणि आम्ही फक्त PostgreSQL म्हणू - ठीक आहे, काहीही न करता सर्वकाही तयार आहे.

परंतु ही समस्या WAL-E बाजूने निश्चित केली जाण्याची शक्यता नाही, त्यामुळे WAL-G आणि WAL-E दोन्हीमध्ये फाइल संग्रहित करणारी आर्काइव्ह कमांड तयार करणे सध्या अशक्य आहे.

याव्यतिरिक्त, अशी प्रकरणे आहेत जिथे WAL-G आता आपल्यासाठी योग्य नाही, परंतु आम्ही निश्चितपणे त्याचे निराकरण करू.

प्रथम, आमच्याकडे सध्या अंगभूत बॅकअप सत्यापन नाही. आमच्याकडे बॅकअप किंवा पुनर्प्राप्ती दरम्यान सत्यापन नाही. अर्थात, हे क्लाउडमध्ये लागू केले जाते. परंतु हे फक्त क्लस्टर पुनर्संचयित करून, पूर्व-तपासणीद्वारे लागू केले जाते. मी वापरकर्त्यांना ही कार्यक्षमता देऊ इच्छितो. परंतु पडताळणी करून, मी असे गृहीत धरतो की WAL-G मध्ये क्लस्टर पुनर्संचयित करणे आणि ते सुरू करणे आणि स्मोक चाचण्या चालवणे शक्य होईल: pg_dumpall ते /dev/null आणि amcheck इंडेक्स पडताळणी.

सध्या WAL-G मध्ये WAL कडून एक बॅकअप पुढे ढकलण्याचा कोणताही मार्ग नाही. म्हणजेच, आम्ही काही विंडोला समर्थन देतो. उदाहरणार्थ, शेवटचे सात दिवस संचयित करणे, शेवटचे दहा बॅकअप संचयित करणे, शेवटचे तीन पूर्ण बॅकअप संचयित करणे. बर्‍याचदा लोक येतात आणि म्हणतात: "आम्हाला नवीन वर्षात काय घडले याचा बॅकअप हवा आहे आणि आम्हाला ते कायमचे ठेवायचे आहे." WAL-G अद्याप हे करू शकत नाही. (टीप - हे आधीच निश्चित केले गेले आहे. अधिक वाचा - मध्ये बॅकअप-मार्क पर्याय https://github.com/wal-g/wal-g/blob/master/PostgreSQL.md)

आणि आमच्याकडे PITR प्रमाणित करताना सर्व शाफ्ट विभागांसाठी पृष्ठ चेकसम आणि अखंडता तपासण्या नाहीत.

या सगळ्यातून मी गुगल समर ऑफ कोडसाठी एक प्रोजेक्ट ठेवला आहे. जर तुम्ही हुशार विद्यार्थी ओळखत असाल ज्यांना Go मध्ये काहीतरी लिहायचे असेल आणि एका कंपनीकडून “G” अक्षरासह अनेक हजार डॉलर्स मिळवायचे असतील तर त्यांना आमच्या प्रकल्पाची शिफारस करा. मी या प्रकल्पासाठी मार्गदर्शक म्हणून काम करेन, ते ते करू शकतात. जर विद्यार्थी नसतील तर मी ते घेईन आणि उन्हाळ्यात ते स्वतः करेन.

आणि आमच्याकडे इतर अनेक लहान समस्या आहेत ज्यांवर आम्ही हळूहळू काम करत आहोत. आणि काही विचित्र गोष्टी घडतात.

उदाहरणार्थ, तुम्ही WAL-G ला रिकामा बॅकअप दिल्यास, तो खाली पडेल. उदाहरणार्थ, जर तुम्ही त्याला सांगितले की त्याला रिकाम्या फोल्डरचा बॅकअप घ्यायचा आहे. pg_control फाइल तेथे नसेल. आणि तो विचार करेल की त्याला काहीतरी समजत नाही. सिद्धांतानुसार, या प्रकरणात आपल्याला साधन कसे वापरावे हे समजावून सांगण्यासाठी वापरकर्त्यास एक सामान्य संदेश लिहिण्याची आवश्यकता आहे. परंतु हे प्रोग्रामिंगचे वैशिष्ट्य नाही तर चांगल्या, सुगम भाषेचे वैशिष्ट्य आहे.

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

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

आणि आम्हाला काळजी करणारी मुख्य गोष्ट म्हणजे आम्हाला शक्य तितक्या डॉकर एकत्रीकरण चाचण्या हव्या आहेत ज्या विविध परिस्थिती तपासतात. आत्ता आम्ही फक्त मूलभूत परिस्थितींची चाचणी घेत आहोत. प्रत्येक कमिटवर, परंतु आम्ही सपोर्ट करत असलेल्या सर्व कार्यक्षमता कमिट-बाय-कमिट तपासू इच्छितो. विशेषतः, उदाहरणार्थ, आम्हाला PostgreSQL 9.4-9.5 साठी पुरेसा सपोर्ट असेल. आम्ही त्यांना समर्थन देतो कारण समुदाय PostgreSQL ला समर्थन देतो, परंतु आम्ही सर्व काही तुटलेले नाही याची खात्री करण्यासाठी कमिट-बाय-कमिट तपासत नाही. आणि मला असे वाटते की हा एक गंभीर धोका आहे.

आमच्याकडे यांडेक्स डेटाबेस व्यवस्थापनामध्ये एक हजाराहून अधिक क्लस्टरवर WAL-G कार्यरत आहे. आणि ते दररोज अनेकशे टेराबाइट डेटाचा बॅकअप घेते.

आमच्या कोडमध्ये आमच्याकडे भरपूर TODO आहेत. तुम्हाला कार्यक्रम करायचा असेल तर या, आम्ही पुल विनंत्यांची वाट पाहत आहोत, आम्ही प्रश्नांची वाट पाहत आहोत.

प्रश्न

शुभ संध्या! धन्यवाद! माझा अंदाज असा आहे की जर तुम्ही WAL-delta वापरत असाल, तर तुम्ही कदाचित पूर्ण-पानाच्या लेखनावर जास्त अवलंबून असाल. आणि असल्यास, तुम्ही चाचण्या चालवल्या का? सुंदर आलेख दाखवलात. FPW बंद केल्यास ते किती सुंदर होईल?

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

अहवालाबद्दल धन्यवाद! माझे दोन प्रश्न आहेत. पहिला प्रश्न असा आहे की टेबलस्पेसचे काय होईल?

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

आणि दुसरा प्रश्न. तुम्ही अगदी सुरुवातीलाच म्हणालात की WAL-G हे गृहीत धरते की ते एकटेच काम करते आणि कोणत्याही रॅपरची गरज नाही. मी स्वतः रॅपर्स वापरतो. ते का वापरले जाऊ नये?

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

शुभ संध्या! अहवालाबद्दल धन्यवाद! GPG डिक्रिप्शनसह कार्य करण्यासाठी आम्ही WAL-G मिळवू शकलो नाही. हे सामान्यपणे एनक्रिप्ट करते, परंतु डिक्रिप्ट करू इच्छित नाही. हे असे काहीतरी आहे जे आमच्यासाठी कार्य करत नाही? परिस्थिती निराशाजनक आहे.

GitHub वर एक समस्या तयार करा आणि चला ते शोधूया.

म्हणजेच, तुम्हाला याचा सामना करावा लागला नाही?

त्रुटी अहवालाचे एक वैशिष्ट्य आहे की जेव्हा WAL-G ला ती कोणत्या प्रकारची फाइल आहे हे समजत नाही, तेव्हा ते विचारते: "कदाचित ती एनक्रिप्टेड आहे?" कदाचित समस्या अजिबात एन्क्रिप्शन नाही. मला या विषयावरील लॉगिंग सुधारायचे आहे. त्याचा उलगडा झाला पाहिजे. आम्ही सध्या या विषयावर या अर्थाने काम करत आहोत की सार्वजनिक आणि खाजगी की मिळवण्याची प्रणाली कशी व्यवस्थापित केली जाते हे आम्हाला खरोखर आवडत नाही. कारण आम्ही बाह्य GPG म्हणतो जेणेकरून ते आम्हाला त्याची कळ देते. आणि मग आम्ही या की घेतो आणि त्या अंतर्गत GPG मध्ये हस्तांतरित करतो, जे उघडलेले PGP आहे, जे आमच्यासाठी WAL-G मध्ये संकलित केले जाते आणि तेथे आम्ही एन्क्रिप्शन म्हणतो. या संदर्भात, आम्ही प्रणाली सुधारू इच्छितो आणि Libsodium एन्क्रिप्शन (आवृत्ती 0.2.15 मध्ये जोडलेले) समर्थन करू इच्छितो. अर्थात, डीकोडिंगने कार्य केले पाहिजे, चला ते शोधूया - आपल्याला दोन शब्दांपेक्षा अधिक लक्षणांची आवश्यकता आहे. तुम्ही कधीतरी स्पीकरच्या खोलीत जमू शकता आणि सिस्टम पाहू शकता. (बाह्य GPG शिवाय PGP एन्क्रिप्शन - v0.2.9)

नमस्कार! अहवालाबद्दल धन्यवाद! माझे दोन प्रश्न आहेत. मला pg_basebackup आणि WAL लॉग इन दोन प्रदाते करण्याची विचित्र इच्छा आहे, म्हणजे मला एक क्लाउड आणि दुसरा करायचा आहे. हे करण्याचा काही मार्ग आहे का?

हे आता अस्तित्वात नाही, परंतु ही एक मनोरंजक कल्पना आहे.

मी फक्त एका प्रदात्यावर विश्वास ठेवत नाही, मला दुसर्‍यामध्ये तेच हवे आहे, फक्त बाबतीत.

कल्पना मनोरंजक आहे. तांत्रिकदृष्ट्या, हे अंमलात आणणे अजिबात कठीण नाही. कल्पना हरवण्यापासून रोखण्यासाठी, मी तुम्हाला GitHub वर समस्या तयार करण्यास सांगू शकतो?

होय नक्कीच.

आणि मग, जेव्हा विद्यार्थी Google समर ऑफ कोडवर येतात, तेव्हा आम्ही त्यांना प्रकल्पात जोडू जेणेकरून त्यांच्याकडून अधिक मिळवण्यासाठी अधिक काम होईल.

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

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

SLA नाही? ते त्यांच्यासाठी लिहिलेले नाहीत का की ते स्वतःला कसे त्रास देऊ देतात?

मुद्दा असा आहे की जे लोक हा प्रश्न घेऊन येतात त्यांची स्वतःची तिजोरी असते. म्हणजेच, Amazon किंवा Google Cloud किंवा Yandex Object Storage वरून कोणीही येत नाही.

कदाचित प्रश्न यापुढे आपल्यासाठी नाही?

या प्रकरणात येथे प्रश्न कोणाला महत्त्वाचा नाही. हे कसे हाताळायचे याबद्दल काही कल्पना असल्यास, ते WAL-G मध्ये करूया. परंतु याला कसे सामोरे जावे याबद्दल मला अद्याप कोणतीही चांगली कल्पना नाही. काही ऑब्जेक्ट स्टोरेज आहेत जे बॅकअपच्या यादीला वेगळ्या प्रकारे समर्थन देतात. तुम्ही त्यांना वस्तूंची यादी करण्यास सांगा आणि ते तेथे फोल्डर जोडतात. WAL-G हे पाहून घाबरले - येथे एक प्रकारची गोष्ट आहे जी फाइल नाही, मी ती पुनर्संचयित करू शकत नाही, याचा अर्थ बॅकअप पुनर्संचयित केला गेला नाही. म्हणजेच, खरं तर, तुमच्याकडे पूर्णपणे पुनर्संचयित क्लस्टर आहे, परंतु ते तुम्हाला एक चुकीची स्थिती परत करते कारण ऑब्जेक्ट स्टोरेजने काही विचित्र माहिती परत केली आहे जी त्याला पूर्णपणे समजली नाही.

ही मेल क्लाउडमध्ये घडणारी गोष्ट आहे.

आपण पुनरुत्पादन तयार करू शकत असल्यास ...

हे सातत्याने पुनरुत्पादित केले जाते ...

जर पुनरुत्पादन असेल, तर मला वाटते की आम्ही पुन्हा प्रयत्न करण्याच्या धोरणांसह प्रयोग करू आणि पुन्हा प्रयत्न कसा करायचा आणि क्लाउडला आपल्याकडून काय आवश्यक आहे हे समजून घेऊ. कदाचित ते आमच्यासाठी तीन कनेक्शनवर स्थिर असेल आणि कनेक्शन खंडित होणार नाही, तर आम्ही काळजीपूर्वक तीनपर्यंत पोहोचू. कारण आता आम्ही कनेक्शन खूप लवकर सोडतो, म्हणजे जर आम्ही 16 थ्रेड्ससह पुनर्प्राप्ती सुरू केली, तर पहिल्या पुन्हा प्रयत्नानंतर 8 थ्रेड, 4 थ्रेड, 2 थ्रेड आणि एक असेल. आणि मग ती फाईल एका प्रवाहात खेचते. जर काही जादुई मूल्ये असतील जसे की 7,5 धागे पंपिंगसाठी सर्वोत्तम आहेत, तर आम्ही त्यावर राहू आणि आणखी 7,5 धागे बनवण्याचा प्रयत्न करू. येथे एक कल्पना आहे.

अहवालाबद्दल धन्यवाद! WAL-G सह कार्य करण्यासाठी संपूर्ण कार्यप्रवाह कसा दिसतो? उदाहरणार्थ, जेव्हा पृष्ठांवर डेल्टा नसतो तेव्हा मूर्ख प्रकरणात. आणि आम्ही प्रारंभिक बॅकअप घेतो आणि काढून टाकतो, नंतर आम्ही चेहरा निळा होईपर्यंत शाफ्ट संग्रहित करतो. येथे, मला समजल्याप्रमाणे, एक ब्रेकडाउन आहे. काही ठिकाणी तुम्हाला पृष्ठांचा डेल्टा बॅकअप घ्यावा लागेल, म्हणजे काही बाह्य प्रक्रिया हे चालवित आहे किंवा हे कसे घडते?

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

म्हणजेच, प्रत्येक वेळी जेव्हा आम्ही WAL-G लाँच करतो तेव्हा तो पूर्ण बॅकअप घेण्याचा प्रयत्न करतो?

नाही, आम्ही WAL-G चालवतो आणि तुमची धोरणे परवानगी देत ​​असल्यास ते डेल्टा बनवण्याचा प्रयत्न करते.

ढोबळपणे सांगायचे तर, जर तुम्ही ते प्रत्येक वेळी शून्याने चालवले, तर ते pg_basebackup सारखे वागेल का?

नाही, ते अजूनही जलद चालेल कारण ते कॉम्प्रेशन आणि समांतरता वापरते. Pg_basebackup तुमच्या शेजारी शाफ्ट ठेवेल. WAL-G असे गृहीत धरते की आपण संग्रहण कॉन्फिगर केले आहे. आणि जर ते कॉन्फिगर केले नसेल तर ते चेतावणी जारी करेल.

Pg_basebackup शाफ्टशिवाय चालवता येतो.

होय, मग ते जवळजवळ सारखेच वागतील. Pg_basebackup फाइल सिस्टमवर कॉपी करते. तसे, आमच्याकडे एक नवीन वैशिष्ट्य आहे ज्याचा मी उल्लेख करायला विसरलो. आम्ही आता pg_basebackup वरून फाईल सिस्टीमवर बॅकअप घेऊ शकतो. याची गरज का आहे हे मला माहित नाही, परंतु ते तेथे आहे.

उदाहरणार्थ, CephFS वर. प्रत्येकजण ऑब्जेक्ट स्टोरेज कॉन्फिगर करू इच्छित नाही.

होय, कदाचित म्हणूनच त्यांनी या वैशिष्ट्याबद्दल प्रश्न विचारला जेणेकरून आम्ही ते करू शकू. आणि आम्ही ते केले.

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

या फॉर्म्युलेशनमध्ये, हा एक कठीण प्रश्न आहे. होय, आम्ही समर्थन करतो, परंतु ही कार्यक्षमता अद्याप कोणत्याही प्रकाशनात समाविष्ट केलेली नाही. म्हणजेच, सर्व पूर्व-रिलीझ यास समर्थन देतात, परंतु प्रकाशन आवृत्त्या तसे करत नाहीत. ही कार्यक्षमता आवृत्ती 0.2 मध्ये जोडली गेली. आम्ही सर्व ज्ञात दोषांचे निराकरण केल्यावर ते निश्चितपणे लवकरच सोडले जाईल. परंतु सध्या हे केवळ प्री-रिलीझमध्येच केले जाऊ शकते. प्री-रिलीझमध्ये दोन बग आहेत. WAL-E पुनर्प्राप्तीसह समस्या, आम्ही त्याचे निराकरण केलेले नाही. आणि नवीनतम प्री-रिलीझमध्ये डेल्टा-बॅकअपबद्दल बग जोडला गेला. म्हणून, आम्ही प्रत्येकाने रिलीझ आवृत्त्या वापरण्याची शिफारस करतो. प्री-रिलीझमध्ये आणखी बग नसल्याबरोबर, आम्ही असे म्हणू शकतो की आम्ही Google क्लाउड, S3-सुसंगत गोष्टी आणि फाइल स्टोरेजला सपोर्ट करतो.

नमस्कार, अहवालाबद्दल धन्यवाद. जसे मला समजले आहे, WAL-G ही एक प्रकारची केंद्रीकृत प्रणाली आहे जसे की बारमेन? या दिशेने वाटचाल करण्याची तुमची योजना आहे का?

समस्या अशी आहे की आपण या दिशेपासून दूर गेलो आहोत. WAL-G बेस होस्टवर, क्लस्टर होस्टवर आणि क्लस्टरमधील सर्व होस्टवर राहतो. जेव्हा आम्ही अनेक हजार क्लस्टर्समध्ये गेलो तेव्हा आमच्याकडे अनेक बारटेंडर इंस्टॉलेशन्स होत्या. आणि प्रत्येक वेळी त्यांच्यामध्ये काहीतरी वेगळे होते, ही एक मोठी समस्या आहे. कारण त्यांची दुरुस्ती करणे आवश्यक आहे, तुम्हाला हे समजून घेणे आवश्यक आहे की कोणत्या क्लस्टर्समध्ये आता बॅकअप नाहीत. बॅकअप सिस्टमसाठी भौतिक हार्डवेअरच्या दिशेने WAL-G विकसित करण्याची माझी योजना नाही. समाजाला इथे काही कार्यक्षमता हवी असेल तर माझी अजिबात हरकत नाही.

आमच्याकडे संघ आहेत जे स्टोरेजसाठी जबाबदार आहेत. आणि आम्हाला इतके चांगले वाटते की ते आम्ही नाही, की आमच्या फायली जिथे सुरक्षित आहेत तिथे काही खास लोक आहेत. विशिष्ट संख्येच्या फायलींचे नुकसान सहन करण्यासाठी ते तेथे सर्व प्रकारचे हुशार कोडिंग करतात. ते नेटवर्क बँडविड्थसाठी जबाबदार आहेत. जेव्हा तुमच्याकडे बारटेंडर असेल, तेव्हा तुम्हाला अचानक कळेल की एकाच सर्व्हरवर भरपूर रहदारी असलेले छोटे डेटाबेस जमा झाले आहेत. तुमच्याकडे त्यावर खूप जागा आहे असे दिसते, परंतु काही कारणास्तव नेटवर्कद्वारे सर्वकाही बसत नाही. हे उलटे होऊ शकते. तेथे बरेच नेटवर्क आहेत, प्रोसेसर कोर आहेत, परंतु येथे डिस्क नाहीत. आणि काहीतरी गडबड करण्याच्या या गरजेने आम्हाला कंटाळा आला आणि आम्ही या वस्तुस्थितीकडे वळलो की डेटा स्टोरेज ही एक वेगळी सेवा आहे, ज्यासाठी वेगळे विशेष लोक जबाबदार आहेत.

P.S एक नवीन आवृत्ती प्रसिद्ध झाली आहे 0.2.15, ज्यामध्ये तुम्ही .walg.json कॉन्फिगरेशन फाइल वापरू शकता, जी डीफॉल्टनुसार पोस्टग्रेस होम डिरेक्टरीमध्ये असते. तुम्ही बॅश स्क्रिप्ट सोडू शकता. उदाहरण .walg.json या अंकात आहे https://github.com/wal-g/wal-g/issues/545

व्हिडिओ:

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