👩🏽‍🍳 👨🏾‍🏭 👨‍👧‍👧 PostgreSQL स्ट्रीमिंग प्रतिकृति में डिबगिंग और समस्या निवारण ↘️ 👨🏼‍🎤 👖

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

Highload ++ 2017 में एलेक्सी लेसोव्स्की ( @lesovsky ) ने बताया कि अंतर्निहित और तीसरे पक्ष के टूल का उपयोग करके विभिन्न प्रकार की समस्याओं का निदान कैसे करें और उन्हें कैसे ठीक करें । कटौती के तहत, इस रिपोर्ट का डिकोडिंग, एक सर्पिल सिद्धांत पर बनाया गया है: सबसे पहले, हम सभी संभावित नैदानिक उपकरणों को सूचीबद्ध करते हैं, फिर सामान्य समस्याओं को सूचीबद्ध करने और उनका निदान करने के लिए आगे बढ़ते हैं, फिर देखते हैं कि क्या आपातकालीन उपाय किए जा सकते हैं, और अंत में मौलिक रूप से समस्या से कैसे निपटें।

स्पीकर के बारे में : डाटा एग्रेट के डेटाबेस प्रशासक अलेक्सी लेसोव्स्की। PostgreSQL में एलेक्सी के पसंदीदा विषयों में से एक है प्रतिकृति प्रतिकृति और आंकड़ों के साथ काम करना, इसलिए Highload ++ 2017 की रिपोर्ट समर्पित थी कि कैसे आँकड़ों का उपयोग करके समस्याओं का पता लगाया जाए और उन्हें हल करने के लिए कौन से तरीकों का उपयोग किया जाए।

योजना

थोड़ा सा सिद्धांत, या कैसे प्रतिकृति PostgreSQL में काम करता है
समस्या निवारण उपकरण या क्या PostgreSQL और समुदाय है
समस्या निवारण के मामले:
- समस्याओं: उनके लक्षण और निदान
- समाधान
- उपाय किए जाएं ताकि ये समस्याएं उत्पन्न न हों।

यह सब क्यों? यह आलेख आपको स्ट्रीमिंग प्रतिकृति को बेहतर ढंग से समझने में मदद करेगा, अप्रिय घटनाओं के लिए प्रतिक्रिया समय को कम करने के लिए समस्याओं को जल्दी से खोजने और ठीक करने का तरीका जानें।

सिद्धांत की बिट

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

लेन-देन लॉग को दो तरीकों से आबाद किया जा सकता है:

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

सबसे महत्वपूर्ण बात, स्ट्रीमिंग प्रतिकृति इस लेन-देन लॉग पर आधारित है। हमारे पास कई स्ट्रीमिंग प्रतिकृति सदस्य हैं:

मास्टर जहां सभी परिवर्तन होते हैं;
कई प्रतिकृतियां जो मास्टर से लेनदेन लॉग को स्वीकार करती हैं और इन सभी परिवर्तनों को अपने स्थानीय डेटा पर पुन: पेश करती हैं। यह स्ट्रीमिंग प्रतिकृति है।

यह याद रखने योग्य है कि ये सभी लेनदेन लॉग $ DATADIR में pg_xlog निर्देशिका में संग्रहीत हैं - मुख्य DBMS डेटा फ़ाइलों के साथ निर्देशिका। PostgreSQL के 10 वें संस्करण में, इस निर्देशिका का नाम बदलकर pg_wal / कर दिया गया था, क्योंकि यह pg_xlog / के लिए बहुत सी जगह लेने के लिए असामान्य नहीं है, और डेवलपर्स या प्रशासक जो अनजाने में लॉग के साथ इसे भ्रमित करते हैं, लापरवाही से इसे हटा देते हैं और सब कुछ खराब हो जाता है।

PostgreSQL में कई पृष्ठभूमि सेवाएं हैं जो स्ट्रीमिंग प्रतिकृति में शामिल हैं। चलो उन्हें ऑपरेटिंग सिस्टम के दृष्टिकोण से देखते हैं।

मास्टर की ओर से - वाल सेंडर प्रक्रिया। यह एक ऐसी प्रक्रिया है जो प्रतिकृति के लिए लेनदेन लॉग भेजता है, प्रत्येक प्रतिकृति का अपना वाल सेंडर होगा।
प्रतिरूप, बदले में, वाल रिसीवर प्रक्रिया को चलाता है, जो वाल सेंडर से नेटवर्क कनेक्शन पर लेन-देन लॉग प्राप्त करता है और उन्हें स्टार्टअप प्रक्रिया से गुजरता है।
स्टार्टअप प्रक्रिया लॉग्स को पढ़ती है और डेटा निर्देशिका पर उन सभी परिवर्तनों को पुन: उत्पन्न करती है जो लेनदेन लॉग में दर्ज किए जाते हैं।

योजनाबद्ध रूप से, यह कुछ इस तरह दिखता है:

परिवर्तन वाल बफ़र्स को लिखा जाता है, जो तब लेनदेन लॉग को लिखा जाएगा;
लॉग pg_wal / निर्देशिका में भंडारण में हैं;
वाल सेंडर भंडार से लॉग को पढ़ता है और उन्हें नेटवर्क पर प्रसारित करता है;
Wal Receiver अपने संग्रहण में प्राप्त करता है और संग्रहीत करता है - स्थानीय pg_wal / में;
स्टार्टअप प्रक्रिया वह सब कुछ पढ़ती है जो स्वीकार किया जाता है और पुन: पेश करता है।

योजना सरल है। स्ट्रीम प्रतिकृति काफी मज़बूती से काम करती है और कई वर्षों से इसका उत्कृष्ट शोषण किया गया है।

समस्या निवारण उपकरण

आइए देखें कि स्ट्रीमिंग प्रतिकृति के साथ आने वाली समस्याओं की जांच करने के लिए समुदाय और पोस्टग्रेक्यूएल कौन से उपकरण और उपयोगिताओं की पेशकश करते हैं।

तीसरे पक्ष के उपकरण

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

शीर्ष पैकेज से। शीर्ष के प्रतिस्थापन के रूप में, आप किसी भी उपयोगिताओं जैसे कि टॉप, हॉप और जैसे का उपयोग कर सकते हैं। वे समान कार्यक्षमता प्रदान करते हैं।

शीर्ष की मदद से हम देखते हैं: प्रोसेसर (सीपीयू), औसत लोड (लोड औसत) और मेमोरी और स्वैप स्पेस उपयोग का उपयोग।

iostat sysstat और iotop से। ये उपयोगिताओं ऑपरेटिंग सिस्टम में प्रक्रियाओं द्वारा डिस्क डिवाइसेस और I / O के उपयोग को दर्शाती हैं।

Iostat की मदद से हम देखते हैं: भंडारण उपयोग, इस समय कितने iops, उपकरणों पर थ्रूपुट, I / O (विलंबता) के लिए अनुरोध करते समय क्या देरी होती है। यह विस्तृत जानकारी procfs फाइल सिस्टम से ली गई है और उपयोगकर्ता को दृश्य रूप में प्रदान की गई है।

निकस्टैट केवल नेटवर्क इंटरफेस के लिए, आईओसैट का एक एनालॉग है। इस उपयोगिता में आप इंटरफेस का उपयोग देख सकते हैं।

निकस्टैट का उपयोग करते हुए, हम देखते हैं: इसी तरह, इंटरफ़ेस का उपयोग, इंटरफेस पर होने वाली कुछ त्रुटियां, थ्रूपुट भी एक बहुत ही उपयोगी उपयोगिता है।

pgCenter केवल PostgreSQL के साथ काम करने के लिए एक उपयोगिता है। यह एक शीर्ष-जैसे इंटरफ़ेस में PostgreSQL आँकड़े दिखाता है, और आप इसमें स्ट्रीमिंग प्रतिकृति से संबंधित आँकड़े भी देख सकते हैं।

PgCenter की सहायता से हम देखते हैं: प्रतिकृति पर आँकड़े। आप प्रतिकृति अंतराल देख सकते हैं, किसी तरह इसका मूल्यांकन कर सकते हैं, और भविष्य के काम की भविष्यवाणी कर सकते हैं।

perf "भूमिगत खटखटाने" के कारणों की गहन जांच के लिए एक उपयोगिता है, जब ऑपरेशन में PostgreSQL स्तर पर अजीब समस्याएं होती हैं।

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

समस्या निवारण के दौरान उत्पन्न होने वाली परिकल्पनाओं का परीक्षण करने के लिए इन सभी उपयोगिताओं की आवश्यकता होती है - कहां और क्या धीमा हो जाता है, कहां और क्या आपको ठीक करने की आवश्यकता है, जांच करें। ये उपयोगिताएँ यह सुनिश्चित करने में मदद करती हैं कि हम सही रास्ते पर हैं।

एंबेडेड उपकरण

खुद PostgreSQL क्या पेश करता है?

सिस्टम के विचार

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

काफी कुछ सिस्टम व्यू हैं। प्रतिकृति प्रतिकृति के साथ काम करने और समस्याओं की जांच करने के लिए, हमें केवल आवश्यकता है: pg_stat_replication, pg_stat_wal_receiver, pg_stat_dat डेटाबेस, pg_stat_datat_conflicts, और सहायक pg_stat_activity और pg_stat_archiver।

उनमें से कुछ हैं, लेकिन यह सेट जांचने के लिए पर्याप्त है कि क्या कोई समस्या है या नहीं।

हेल्पर कार्य

सहायक कार्यों का उपयोग करके, आप सांख्यिकीय प्रणाली अभ्यावेदन से डेटा ले सकते हैं और उन्हें अपने लिए अधिक सुविधाजनक रूप में बदल सकते हैं। सहायक कार्य भी केवल कुछ टुकड़े हैं।

pg_current_wal_lsn () (pg_current_xlog_location () का पुराना एनालॉग) सबसे आवश्यक फ़ंक्शन है जो आपको लेन-देन लॉग में वर्तमान स्थिति देखने की अनुमति देता है। लेन-देन लॉग डेटा का एक निरंतर अनुक्रम है। इस फ़ंक्शन का उपयोग करके, आप अंतिम बिंदु देख सकते हैं, उस स्थिति को प्राप्त कर सकते हैं जहां लेनदेन लॉग बंद हो गया है।
pg_last_wal_receive_lsn (), pg_last_xlog_receive_location () उपरोक्त का एक समान कार्य है, केवल प्रतिकृतियों के लिए। प्रतिकृति लेनदेन लॉग प्राप्त करता है, और आप अंतिम प्राप्त लेनदेन लॉग स्थिति देख सकते हैं;
pg_wal_lsn_diff (), pg_xlog_location_diff () एक और उपयोगी कार्य है। हम उसे लेन-देन लॉग से दो स्थिति देते हैं, और वह अलग दिखाती है - बाइट्स में इन दो बिंदुओं के बीच की दूरी। यह फ़ंक्शन बाइट्स में मास्टर और प्रतिकृतियों के बीच अंतराल को निर्धारित करने के लिए हमेशा उपयोगी होता है।

फ़ंक्शन की पूरी सूची psql मेटा-कमांड के साथ प्राप्त की जा सकती है: \ df * (वाल | x lsn | स्थान) *।

आप इसे psql में टाइप कर सकते हैं और उन सभी कार्यों को देख सकते हैं, जो चलते हैं, xlog, Isn, location होते हैं। लगभग 20-30 ऐसे कार्य होंगे, और वे लेनदेन लॉग पर विभिन्न जानकारी भी प्रदान करते हैं। मेरा सुझाव है कि आप खुद को परिचित करें।

Pg_waldump उपयोगिता

संस्करण 10.0 से पहले, इसे pg_xlogdump कहा जाता था। Pg_waldump उपयोगिता की आवश्यकता तब होती है जब हम लेन-देन लॉग के सेगमेंट में देखना चाहते हैं, यह पता करें कि वहां कौन से संसाधन रिकॉर्ड मिले, और पोस्टग्रेक्यूएल ने वहां क्या लिखा, यानी अधिक विस्तृत अध्ययन के लिए।

10.0 संस्करण में, सभी सिस्टम व्यू, फ़ंक्शंस, और यूटिलिटीज जिनमें ज़्लॉग शब्द शामिल था, उनका नाम बदल दिया गया। शब्दों के स्थान और स्थान की सभी घटनाओं को क्रमशः वाल और एलएसएन द्वारा प्रतिस्थापित किया गया था। यही काम pg_xlog निर्देशिका के साथ किया गया जो pg_wal निर्देशिका बन गई।

Pg_waldump उपयोगिता बस XLOG खंडों की सामग्री को मानव-पठनीय प्रारूप में डिकोड करती है। आप देख सकते हैं कि PostgreSQL के काम के दौरान सेगमेंट लॉग में तथाकथित संसाधन रिकॉर्ड क्या गिरते हैं, जो अनुक्रमित और हीप फाइलें बदल दी गईं, स्टैंड-बाय के लिए क्या जानकारी मिली। इस प्रकार, pg_waldump का उपयोग करके बहुत सारी जानकारी देखी जा सकती है।

लेकिन एक डिस्क्लेमर है जो आधिकारिक दस्तावेज में लिखा गया है: pg_waldump जब पोस्टग्रेएसक्यू चल रहा है तो थोड़ा गलत डेटा दिखा सकता है (जब सर्वर चल रहा हो तो गलत परिणाम दे सकता है - जो भी इसका मतलब है)

आप कमांड का उपयोग कर सकते हैं:

pg_waldump -f - /wal_10 \ $(psql -qAtX - "select pg_walfile_name(pg_current_wal_lsn())")

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

समस्या निवारण के मामले

यहां हम सबसे आम समस्याओं को देखते हैं जो सलाहकारों के व्यवहार में उत्पन्न होती हैं, क्या लक्षण हो सकते हैं और उनका निदान कैसे किया जा सकता है:

प्रतिकृति लैग सबसे आम समस्या है । अभी हाल ही में, हमने ग्राहक के साथ पत्राचार किया था:

- हमने दो सर्वरों के बीच मास्टर-स्लेव प्रतिकृति को तोड़ा है।

- लैग 2 घंटे का पता चला, pg_dump शुरू हुआ।

- ठीक है, मैं देख रहा हूं। हमारे अनुमेय अंतराल क्या है?

- 16 घंटे max_standby_streaming_delay पर।

- इस अंतराल के पार होने पर क्या होगा? हॉर्लिंग सायरन?

- नहीं, लेन-देन पीटा जाएगा, और वाल रोल फिर से शुरू होगा।

हमें हर समय प्रतिकृति के साथ समस्याएं हैं, और लगभग हर हफ्ते हम उन्हें हल करते हैं।

Pg_wal / निर्देशिका की सूजन जहां लेन-देन लॉग सेगमेंट संग्रहीत हैं, एक समस्या है जो कम बार होती है। लेकिन इस मामले में तत्काल कार्रवाई करना आवश्यक है ताकि प्रतिकृतियां गिरने पर समस्या आपातकालीन स्थिति में न बदल जाए।

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

पुनर्प्राप्ति प्रक्रिया: 100% CPU उपयोग - प्रतिकृतियों पर लेनदेन लॉग को पुनर्प्राप्त करने की प्रक्रिया में प्रोसेसर समय का 100% लगता है। यह भी एक दुर्लभ स्थिति है, लेकिन यह अप्रिय है, क्योंकि प्रतिकृति अंतराल में वृद्धि की ओर जाता है और आम तौर पर जांच करना मुश्किल होता है।

प्रतिकृति लैग

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

ऐसी समस्याओं की तलाश कैसे करें?

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

Pg_stat_replication के 10 वें संस्करण में, अतिरिक्त फ़ील्ड दिखाई दिए जो विज़ार्ड पर पहले से ही समय अंतराल दिखाते हैं, इसलिए यह विधि पहले से ही पुरानी है, लेकिन, फिर भी, इसका उपयोग किया जा सकता है।

एक छोटा सा गड्ढा है। यदि लंबे समय तक विज़ार्ड पर कोई लेनदेन नहीं होता है, और यह लेनदेन लॉग उत्पन्न नहीं करता है, तो अंतिम फ़ंक्शन एक बढ़ती हुई अंतराल दिखाएगा। वास्तव में, प्रणाली बस बेकार है, इस पर कोई गतिविधि नहीं है, लेकिन निगरानी में हम देख सकते हैं कि अंतराल बढ़ रहा है। यह गड्ढा याद रखने लायक है।

दृश्य इस प्रकार है।

इसमें प्रत्येक वाल सेंडर और कई क्षेत्रों की जानकारी है जो हमारे लिए महत्वपूर्ण हैं। यह मुख्य रूप से client_addr है - जुड़ा हुआ प्रतिकृति का नेटवर्क पता (आमतौर पर एक आईपी पता) और lsn फ़ील्ड का एक सेट (पुराने संस्करणों में इसे स्थान कहा जाता है), मैं उनके बारे में थोड़ा आगे बात करूंगा।

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

एक नियम के रूप में, मैं इस अनुरोध का उपयोग करता हूं।

यह सबसे जटिल प्रश्न नहीं है जो pg_stat_replication अधिक सुविधाजनक, समझने योग्य प्रारूप में प्रिंट करता है। यहाँ मैं निम्नलिखित कार्यों का उपयोग करता हूं:

pg_wal_lsn_diff () पढ़ने के लिए अंतर । लेकिन मुझे क्या लगता है कि क्या अंतर है? हमारे पास कई फ़ील्ड हैं - sent_lsn, write_lsn, flush_lsn, replay_lsn। वर्तमान और पिछले क्षेत्र के बीच के अंतर की गणना करके, हम सटीक रूप से समझ सकते हैं कि हम कहाँ पर पिछड़ गए, जहाँ वास्तव में अंतराल होता है।
pg_current_wal_lsn () , जो लेन-देन लॉग की वर्तमान स्थिति दिखाता है। यहां हम लॉग में वर्तमान स्थिति और भेजे गए एक के बीच की दूरी को देखते हैं - कितने लेनदेन लॉग उत्पन्न किए गए लेकिन भेजे नहीं गए।
sent_lsn , write_lsn - यह कितना प्रतिकृति में भेजा जाता है, लेकिन रिकॉर्ड नहीं किया जाता है। यही है, यह अब नेटवर्क पर कहीं स्थित है, या यह एक प्रतिकृति द्वारा प्राप्त किया गया था, लेकिन अभी तक नेटवर्क बफ़र्स से डिस्क स्टोरेज तक नहीं लिखा गया है।
write_lsn, flush_lsn - यह लिखा है, लेकिन fsync कमांड द्वारा जारी नहीं किया गया था - जैसे कि लिखा गया है, लेकिन ऑपरेटिंग सिस्टम के पेज-कैश में रैम में कहीं स्थित हो सकता है। जैसे ही हम fsync करते हैं, डेटा डिस्क के साथ सिंक्रनाइज़ हो जाता है, लगातार स्टोरेज के लिए हो जाता है और सब कुछ विश्वसनीय लगता है।
replay_lsn, flush_lsn - डेटा डंप, fsync निष्पादित, लेकिन प्रतिकृति नहीं।
current_wal_lsn और replay_lsn कुल अंतराल का एक प्रकार है जिसमें सभी पिछले स्थान शामिल हैं।

कुछ उदाहरण

ऊपर 10.6.6.8 प्रतिकृति को हाइलाइट किया गया है। उसके पास एक लंबित है , उसने कुछ लेन-देन लॉग उत्पन्न किए, लेकिन वे अभी भी नहीं भेजे गए हैं और मास्टर पर झूठ बोलते हैं। सबसे अधिक संभावना है, नेटवर्क के प्रदर्शन के साथ किसी प्रकार की समस्या है। हम इसे निकस्टैट उपयोगिता का उपयोग करके सत्यापित करेंगे।

हम निकस्टैट लॉन्च करेंगे, इंटरफ़ेस का उपयोग देखेंगे, अगर वहां कोई समस्या और त्रुटियां हैं। तो हम इस परिकल्पना का परीक्षण कर सकते हैं।

राइट लैग ऊपर चिह्नित है। वास्तव में, यह अंतराल काफी दुर्लभ है, मैं लगभग इसे बड़े होने के लिए नहीं देखता हूं। समस्या डिस्क के साथ हो सकती है, और हम iostat या iotop उपयोगिता का उपयोग करते हैं - हम डिस्क स्टोरेज के उपयोग को देखते हैं, जिसे I / O प्रक्रियाओं द्वारा बनाया जाता है, और फिर हमें पता चलता है कि क्यों।

फ्लश और रीप्ले लैग्स - सबसे अधिक बार लैग तब होता है जब प्रतिकृति पर डिस्क डिवाइस के पास मास्टर से आने वाले सभी परिवर्तनों को खोने का समय नहीं होता है।

इसके अलावा iostat और iotop उपयोगिताओं के साथ हम देखते हैं कि डिस्क उपयोग और ब्रेक क्यों होता है।

और अंतिम Total_lag निगरानी प्रणालियों के लिए एक उपयोगी मीट्रिक है। यदि हमारा थ्रेशोल्ड total_lag पार हो गया है, तो निगरानी में एक चेकबॉक्स उठाया जाता है, और हम जांच करना शुरू करते हैं कि वहां क्या हो रहा है।

परिकल्पना परीक्षण

अब आपको यह पता लगाने की आवश्यकता है कि किसी विशेष समस्या की जांच कैसे करें। मैंने पहले ही कहा कि अगर यह एक नेटवर्क अंतराल है, तो हमें यह जांचने की आवश्यकता है कि क्या नेटवर्क के साथ सब कुछ क्रम में है।

अब लगभग सभी होस्टर्स 1 जीबी / एस या यहां तक कि 10 जीबी / एस प्रदान करते हैं, इसलिए एक भरा हुआ बैंडविड्थ सबसे अधिक संभावना नहीं है । एक नियम के रूप में, आपको त्रुटियों को देखने की आवश्यकता है। निकस्टैट में इंटरफेस पर त्रुटियों के बारे में जानकारी है, आप यह पता लगा सकते हैं कि ड्राइवरों के साथ समस्याएं हैं, या तो नेटवर्क कार्ड के साथ या केबल के साथ।

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

सबसे पहले, हम शीर्ष या pg_stat_activity के माध्यम से पुनर्प्राप्ति देरी और प्रतिकृति संघर्षों को देखते हैं: कौन सी प्रक्रिया चल रही है, कौन से अनुरोध चल रहे हैं, उनके निष्पादन का समय, वे कितने समय से चल रहे हैं। यदि ये कुछ लंबे प्रश्न हैं, तो हम देखते हैं कि वे लंबे समय तक काम क्यों करते हैं, उन्हें शूट करें, उन्हें समझें और उन्हें अनुकूलित करें - हम स्वयं प्रश्नों की जांच करेंगे।

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

और बेशक pg_wal_lsn_diff () अंतराल निर्धारित करने के लिए और निर्धारित करें कि हमारे पास विशेष रूप से अंतराल कहां है - नेटवर्क पर, डिस्क पर या प्रोसेसर पर।

समाधान के विकल्प

नेटवर्क / संग्रहण समस्याएँ

यहां सब कुछ काफी सरल है, लेकिन कॉन्फ़िगरेशन के दृष्टिकोण से, यह आमतौर पर हल नहीं होता है। आप कुछ नट्स को कस सकते हैं, लेकिन सामान्य तौर पर 2 विकल्प हैं:

वर्कलोड की जाँच करें

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

हार्डवेयर अपग्रेड करें

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

वसूली में देरी

यदि हमारे पास लंबे अनुरोधों के कारण किसी भी प्रकार की प्रतिकृति संघर्ष है, जिसके परिणामस्वरूप रिप्ले लैग में वृद्धि होती है, तो सबसे पहले हम लंबे अनुरोधों को शूट करते हैं जो प्रतिकृति पर चलते हैं, क्योंकि वे लेनदेन लॉग के प्लेबैक में देरी करते हैं।

यदि लंबी क्वेरीज़ स्वयं SQL क्वेरी की गैर-समानता से संबंधित हैं (हमें यह पता चलता है कि EXPLAIN ANALYZE का उपयोग करके पता चलता है), तो आपको बस इस क्वेरी को अलग तरीके से देखने और इसे फिर से लिखने की आवश्यकता है। या प्रश्नों की रिपोर्टिंग के लिए एक अलग प्रतिकृति को कॉन्फ़िगर करने का विकल्प है। यदि हम कोई रिपोर्ट बनाते हैं जो लंबे समय तक काम करती है, तो उन्हें एक अलग प्रतिकृति के लिए प्रस्तुत करने की आवश्यकता होती है।

अभी भी इंतजार करने का विकल्प बाकी है । यदि हमारे पास कुछ किलोबाइट्स के स्तर पर या यहां तक कि मेगाबाइट्स के दसियों प्रकार के अंतराल हैं, लेकिन हमें लगता है कि यह स्वीकार्य है, हम बस अनुरोध पूरा होने का इंतजार करते हैं और अंतराल खुद को हल करेगा। यह भी एक विकल्प है, और अक्सर ऐसा होता है कि यह स्वीकार्य है।

उच्च मात्रा वाल

यदि हम बड़ी मात्रा में लेन-देन लॉग बनाते हैं, तो हमें प्रति यूनिट समय इस मात्रा को कम करने की आवश्यकता होती है, ताकि प्रतिकृति को कम लेनदेन लॉग को चबाने की आवश्यकता हो।

यह आमतौर पर कॉन्फ़िगरेशन के माध्यम से किया जाता है । फुल_पेज_ राइट्स = ऑफ पैरामीटर सेट करने में आंशिक समाधान। यह विकल्प लेनदेन लॉग में बदलते पृष्ठों की पूरी छवियों की रिकॉर्डिंग को चालू / बंद करता है। इसका मतलब यह है कि जब हमारे पास एक चेकपॉइंट (CHECKPOINT) लिखने का सेवा संचालन था, तो अगली बार जब हम साझा बफ़र्स क्षेत्र में कुछ डेटा ब्लॉक बदलते हैं, तो इस पृष्ठ की पूरी छवि, और न केवल परिवर्तन स्वयं, लेनदेन लॉग पर जाएंगे। एक ही पृष्ठ के बाद के सभी परिवर्तनों के साथ, लेन-देन लॉग में केवल परिवर्तन लॉग किए जाएंगे। और इसलिए अगली चौकी पर।

चेकपॉइंट के बाद, हम पृष्ठ की पूरी छवि रिकॉर्ड करते हैं, और यह रिकॉर्ड किए गए लेनदेन लॉग की मात्रा को प्रभावित करता है। यदि समय की प्रति यूनिट बहुत अधिक चौकियों हैं, तो मान लें कि प्रति घंटे 4 चौकियां की जाती हैं, और बहुत सारे पूर्ण पृष्ठ चित्र होंगे, यह एक समस्या होगी। आप पूर्ण चित्रों की रिकॉर्डिंग को अक्षम कर सकते हैं और यह वाल की मात्रा को प्रभावित करेगा। लेकिन फिर, यह एक आधा उपाय है।

नोट: फुल_पेज_ राइट्स को निष्क्रिय करने की सिफारिश को सावधानी से विचार किया जाना चाहिए, क्योंकि लेखक रिपोर्ट के दौरान यह स्पष्ट करना भूल गया कि एक पैरामीटर को अक्षम करने से कुछ परिस्थितियों में, आपातकालीन स्थितियों (फ़ाइल सिस्टम या इसके लॉग को नुकसान, ब्लॉक को आंशिक रूप से लिखना आदि) हो सकता है। संभावित भ्रष्ट डेटाबेस फ़ाइलें। इसलिए, सावधान रहें, पैरामीटर को अक्षम करने से आपातकालीन स्थितियों में डेटा भ्रष्टाचार का खतरा बढ़ सकता है।

एक और आधा उपाय चौकियों के बीच अंतराल को बढ़ाने के लिए है । डिफ़ॉल्ट रूप से, चेकपॉइंट हर 5 मिनट में किया जाता है, और यह काफी सामान्य है। एक नियम के रूप में, इस अंतराल को 30-60 मिनट तक बढ़ाया जाता है - यह काफी स्वीकार्य समय है जिसके लिए सभी गंदे पृष्ठ डिस्क के लिए सिंक्रनाइज़ होने का प्रबंधन करते हैं।

लेकिन मुख्य समाधान, ज़ाहिर है, हमारे कार्यभार को देखने के लिए - वहां किस तरह के भारी ऑपरेशन चल रहे हैं, डेटा को बदलने के साथ जुड़े हुए हैं, और, शायद, इन परिवर्तनों को बैचों में करने की कोशिश करें।

मान लीजिए कि हमारे पास एक मेज है, हम उससे कई मिलियन रिकॉर्ड हटाना चाहते हैं। सबसे अच्छा विकल्प एक अनुरोध के साथ एक बार में इन लाखों को हटाना नहीं है, लेकिन उन्हें 100-200 हजार के पैक में तोड़ना है ताकि, पहले, वाल के छोटे वॉल्यूम उत्पन्न होते हैं, दूसरे, वैक्यूम में हटाए गए डेटा से गुजरने का समय होता है, और इसलिए अंतराल ऐसा नहीं था बड़ा और आलोचनात्मक।

सूजन pg_wal /

अब, आइए बात करते हैं कि आप कैसे पा सकते हैं कि pg_wal / directory सूज गया है।

सिद्धांत रूप में, PostgreSQL हमेशा कुछ कॉन्फ़िगरेशन फ़ाइलों के स्तर पर अपने लिए एक इष्टतम स्थिति में रखता है, और, एक नियम के रूप में, इसे कुछ सीमाओं से ऊपर नहीं बढ़ना चाहिए।

एक पैरामीटर है max_wal_size, जो अधिकतम मूल्य निर्धारित करता है। प्लस में वाल_की_सेल्स पैरामीटर है - एक अतिरिक्त संख्या में सेगमेंट जो कि प्रतिकृति के लिए मास्टर स्टोर करता है यदि प्रतिकृति अचानक लंबे समय तक अनुपलब्ध है।

Max_wal_size और wal_keep_seolutions के योग की गणना करके, हम मोटे तौर पर अनुमान लगा सकते हैं कि pg_wal / directory कितनी जगह लेगी। यदि यह तेजी से बढ़ता है और गणना मूल्य की तुलना में बहुत अधिक जगह लेता है, तो इसका मतलब है कि कुछ समस्या है, और आपको इसके बारे में कुछ करने की आवश्यकता है।

ऐसी समस्याओं का पता कैसे लगाएं?

लिनक्स ऑपरेटिंग सिस्टम पर, डु -श कमांड है । हम केवल मूल्य की निगरानी कर सकते हैं और मॉनिटर कर सकते हैं कि हमारे पास कितने लेनदेन लॉग हैं; एक गणना लेबल रखें, वह कितना बकाया है और वह वास्तव में कितना लेता है, और किसी तरह संख्याओं में परिवर्तन का जवाब देता है।

एक अन्य स्थान जिसे हम देखते हैं वह है pg_replication_slots और pg_stat_archiver दृश्य । Pg_wal / बहुत सी जगह लेने के सबसे सामान्य कारणों में प्रतिकृति स्लॉट्स या टूटी हुई आर्काइविंग को भुला दिया जाता है। अन्य कारणों में भी एक जगह है, लेकिन मेरे अभ्यास में वे बहुत दुर्लभ थे।

और, निश्चित रूप से, PostgreSQL लॉग में हमेशा त्रुटियाँ होती हैं जो संग्रह कमांड के साथ जुड़ी होती हैं। दुर्भाग्य से, pg_wal / overflow से संबंधित कोई अन्य कारण नहीं होंगे। हम वहां केवल संग्रह त्रुटियों को पकड़ सकते हैं।

समस्याओं के लिए विकल्प:

भारी CRUD - भारी डेटा रिफ्रेश ऑपरेशन - भारी INSERT, DELETE, UPDATE, कई मिलियन पंक्तियों को बदलने के साथ जुड़े। यदि PostgreSQL को इस तरह के ऑपरेशन को करने की आवश्यकता है, तो यह स्पष्ट है कि बड़ी मात्रा में लेनदेन लॉग उत्पन्न होगा। इसे pg_wal / में संग्रहीत किया जाएगा, और इससे अधिग्रहीत स्थान बढ़ जाएगा। यही है, फिर से, जैसा कि मैंने पहले कहा, यह केवल उन्हें पैक में तोड़ने के लिए, और पूरे सरणी को नहीं, बल्कि प्रत्येक को 100, 200, 300 हजार अपडेट करने के लिए अच्छा अभ्यास है।

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

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

लेकिन समय बीत जाता है, कोई भी स्लॉट से नहीं जुड़ता है, लेनदेन लॉग जमा होते हैं, और कुछ बिंदु पर वे 90% स्थान पर कब्जा कर लेते हैं। हमें यह पता लगाने की जरूरत है कि यह क्या है, क्यों इतनी जगह ली जाती है। एक नियम के रूप में, इस भूल गए और अप्रयुक्त स्लॉट को बस हटाने की जरूरत है, और समस्या हल हो जाएगी। लेकिन उस पर और बाद में।

एक अन्य विकल्प एक टूटी हुई आर्काइव_कैंड हो सकता है। जब हमारे पास किसी प्रकार का बाहरी लेन-देन लॉग रिपॉजिटरी होता है जिसे हम आपदा वसूली कार्यों के लिए रखते हैं, तो एक संग्रह कमांड आमतौर पर स्थापित किया जाता है, कम अक्सर pg_receivexlog सेट किया जाता है। आर्काइव_कमांड में पंजीकृत कमांड अक्सर या तो एक अलग कमांड या कुछ स्क्रिप्ट होती है जो pg_wal / से ट्रांजेक्शन लॉग के सेगमेंट को लेती है और इसे आर्काइव स्टोरेज में कॉपी करती है।

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

यदि आर्काइव कमांड ने 0 के आउटपुट के साथ काम किया है, तो इस बारे में एक संदेश लॉग को लिखा जाएगा, और खंड pg_wal / directory में रहेगा। जब तक हमें पता नहीं चलेगा कि हमारी आर्काइव टीम टूट चुकी है, तब तक सेगमेंट जमा हो जाएंगे , और जगह भी खत्म हो जाएगी।

आपातकालीन उपायों का सेट (100% प्रयुक्त स्थान):

1. CRUD , — pg_terminate_backend().
- , , , .. , pg_wal/, .

2. root — reserved space ratio (ext filesystems).
ext ext 5%. , , 5% — . , , 1% , tune2fs -m 1. PostgreSQL , . 100% .

3. (LVM, ZFS,...).
LVM ZFS, LVM ZFS, , , . , .

4. — , , HE pg_wal/ .
, , , . ! PostgreSQL , . , , , .

, pg_xlog/ pg_wal/ — log , , , , - — !

, 100% CPU, .

workload . , ? , - , -. : , tablespace, tablespace.

. , , , , , , . — .

checkpoints_segments/max_wal_size, wal_keep_segments . , , — 10-20 wal_keep_segments, max_wal_size. , . PostgreSQL pg_wal/ .

pg_replication_slots — . , , — . , , . .

WAL, , pg_stat_archiver , . , , , , .

checkpoint . , , . , PostgreSQL . , checkpoint .

, , — . - , . , .

— PostgreSQL :

User was holding shared bufer pin for too long.
User query might have needed to see row versions that must be removed.
User was holding a relation lock for too long.
User was or might have been using table space that must be dropped.
User transaction caused bufer deadlock with recovery.
User was connected to a database that must be dropped.

2 — , , . : , , . ( 30 ), PostgreSQL — .

. , , . - , timeout . — ALTER, , .

. , tablespace , tablespace. , , - — .

?

pg_stat_databases, pg_stat_databases_conflicts . , . , .

, . , . , . , , , .

?

, — :

max_standby_streaming_delay ( ). , . .
hot_stadby_feedback ( /). , vacuum - , . bloat . , , , hot_stadby_feedback .
DBA — . , . , , , - , .
, , , , DBA — , , . max_standby_streaming_delay . , . , , , . — , .

Recovery process: 100% CPU usage

, , , 100% . , , 100%. , pg_stat_replication, , replay, , .

:

top — — 100% CPU usage recovery process;
pg_stat_replication — , , .

, . , :

perf top/record/report ( debug—);
GDB;
pg_waldump.

, , . workload, . , , PostgreSQL shared buffers ( ). .

निर्णय

, . - workload, - , - : « , - ».

pgsql-hackers , pgsql-bugs , , . , .

— - , , .

परिणाम

. , , , .

. , , , , , — .

, , — . , , , .

, , — , , .

उपयोगी लिंक

PostgreSQL official documentation — The Statistics Collector
PostgreSQL Mailing Lists ( general , performance , hackers )
PostgreSQL-Consulting company blog

, Highload++ Siberia , 25 26 . , , .

MySQL ClickHouse.
, Oracle.
निकोले गोलोव आपको बताएंगे कि कैसे लेनदेन को लागू करना है अगर पैसा एक सेवा में है, दूसरे में सेवाएं, और प्रत्येक सेवा का अपना अलग आधार है।
यूरी नसेरेतिनोव विस्तार से बताएंगे कि वीके को क्लिकहाउस की आवश्यकता क्यों है, कितना डेटा संग्रहीत है, और बहुत कुछ।

PostgreSQL स्ट्रीमिंग प्रतिकृति में डिबगिंग और समस्या निवारण