💲 🚴 🤹🏼 किसी दुर्घटना के बाद एक पोस्टग्रेज डेटाबेस को पुनर्प्राप्त करने का मेरा पहला अनुभव (रिलेटन बेस / 16490 के ब्लॉक 4123007 में अमान्य पृष्ठ) 🏄 ✔️ 🐜

मैं Postgres डेटाबेस की पूर्ण कार्यक्षमता को पुनर्स्थापित करने में अपना पहला सफल अनुभव आपके साथ साझा करना चाहता हूं। मैं डेढ़ साल पहले Postgres DBMS से मिला, इससे पहले मुझे डेटाबेस प्रशासन का बिल्कुल भी अनुभव नहीं था।

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

डंप हटाते समय एक अप्रत्याशित त्रुटि हुई (पोस्टग्रेज संस्करण 9.5 है):

pg_dump: Oumping the contents of table “ws_log_smevlog” failed: PQgetResult() failed. pg_dump: Error message from server: ERROR: invalid page in block 4123007 of relatton base/16490/21396989 pg_dump: The command was: COPY public.ws_log_smevlog [...] pg_dunp: [parallel archtver] a worker process dled unexpectedly

त्रुटि "ब्लॉक में अमान्य पृष्ठ" फ़ाइल सिस्टम स्तर पर समस्याओं को इंगित करता है, जो बहुत खराब है। विभिन्न मंचों पर, उन्होंने इस समस्या को हल करने के लिए जीरो_डैमेज_पज विकल्प के साथ पूर्ण रिक्त स्थान बनाने का सुझाव दिया। खैर, popprobeum ...

वसूली की तैयारी

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

चूंकि डेटाबेस ने एक पूरे के रूप में मेरे लिए काम किया, इसलिए मैंने खुद को सामान्य डेटाबेस डंप तक सीमित कर दिया, लेकिन क्षतिग्रस्त डेटा (विकल्प -T, --exclude-table = pg_dump में तालिका) के साथ तालिका को बाहर कर दिया।

सर्वर भौतिक था, स्नैपशॉट लेना असंभव था। बैकअप हटा दिया जाता है, आगे बढ़ते हैं।

फाइल सिस्टम जांच

डेटाबेस को पुनर्स्थापित करने का प्रयास करने से पहले, आपको यह सुनिश्चित करने की आवश्यकता है कि सब कुछ फ़ाइल सिस्टम के साथ ही है। और त्रुटियों के मामले में, उन्हें सही करें, क्योंकि अन्यथा आप इसे केवल बदतर बना सकते हैं।

मेरे मामले में, डेटाबेस के साथ फाइल सिस्टम "/ srv" में लगाया गया था और प्रकार ext4 था।

हम डेटाबेस को रोकते हैं: systemctl stop postgresql@9.5-main.service को रोकते हैं और जांचते हैं कि फ़ाइल सिस्टम किसी के द्वारा उपयोग नहीं किया गया है और यह lsof कमांड का उपयोग करके अनमाउंट किया जा सकता है:
lsof + D / srv

मुझे अभी भी रेडिस डेटाबेस को रोकना पड़ा, क्योंकि इसने "/ srv" का भी उपयोग किया। इसके बाद, मैंने अनमाउंट / srv (umount) किया।

फ़ाइल सिस्टम की जाँच ई-विकल्प के साथ e2fsck उपयोगिता का उपयोग करके की गई थी ( फोर्स की जाँच भले ही फाइल सिस्टम साफ हो ):

इसके बाद, dipe2fs यूटिलिटी ( sudo dipe2fs / dev / mapper / gu2 - sys-srv। Grep check ) का उपयोग करके, आप सत्यापित कर सकते हैं कि चेक वास्तव में प्रदर्शन किया गया था:

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

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

प्रयास 1: zero_damaged_pages

हम सुपरक्यूलर अधिकारों के साथ psql खाते के माध्यम से डेटाबेस से जुड़ते हैं। हमें सुपरसुसर की बिल्कुल जरूरत है, क्योंकि केवल वह जीरो_डैमेज्ड_पैप्स विकल्प को बदल सकता है। मेरे मामले में, यह पोस्टग्रेज है:

psql -h 127.0.0.1 -U पोस्ट-एस [डेटाबेस_नाम]

शून्य त्रुटि (पोस्टग्रॉस्प्रो वेबसाइट से) को अनदेखा करने के लिए जीरो_डैमेजडैप विकल्प की आवश्यकता है:

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

विकल्प चालू करें और पूर्ण वैक्यूम टेबल बनाने का प्रयास करें:

 VACUUM FULL VERBOSE

दुर्भाग्य से, विफलता।

हमें एक समान त्रुटि का सामना करना पड़ा:

 INFO: vacuuming "“public.ws_log_smevlog” WARNING: invalid page in block 4123007 of relation base/16400/21396989; zeroing out page ERROR: unexpected chunk number 573 (expected 565) for toast value 21648541 in pg_toast_106070

pg_toast - Postgres में "लंबे डेटा" संग्रहीत करने के लिए तंत्र, यदि वे एक ही पृष्ठ (डिफ़ॉल्ट रूप से 8kb) पर फिट नहीं होते हैं।

प्रयास 2: reindex

पहले Google टिप ने मदद नहीं की। खोज के कुछ ही मिनटों के बाद, मुझे एक दूसरी टिप मिली - एक क्षतिग्रस्त टेबल को रेनडेक्स बनाने के लिए। मैं कई जगहों पर इस सलाह से मिला, लेकिन इससे आत्मविश्वास नहीं बढ़ा। रेनडेक्स करें:

 reindex table ws_log_smevlog

reindex समस्याओं के बिना पूरा किया।

हालाँकि, इससे कोई मदद नहीं मिली, VACUUM FULL एक समान त्रुटि के साथ दुर्घटनाग्रस्त हो गया। चूंकि मुझे विफलताओं के लिए इस्तेमाल किया गया था, मैंने आगे इंटरनेट पर सलाह लेनी शुरू कर दी और एक दिलचस्प लेख के रूप में आया।

प्रयास 3: का चयन करें, सीमा, OFFSET

ऊपर दिए गए लेख में लाइन लाइन को समस्याग्रस्त डेटा को देखने और हटाने का सुझाव दिया गया है। शुरू करने के लिए, सभी लाइनों को देखना आवश्यक था:

 for ((i=0; i<"Number_of_rows_in_nodes"; i++ )); do psql -U "Username" "Database Name" -c "SELECT * FROM nodes LIMIT 1 offset $i" >/dev/null || echo $i; done

मेरे मामले में, तालिका में 1,628,991 पंक्तियाँ थीं! एक अच्छे तरीके से, डेटा के विभाजन का ध्यान रखना आवश्यक था, लेकिन यह एक अलग चर्चा का विषय है। शनिवार का दिन था, मैंने इस आदेश को tmux में चलाया और सो गया:

 for ((i=0; i<1628991; i++ )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog LIMIT 1 offset $i" >/dev/null || echo $i; done

सुबह तक, मैंने यह जांचने का फैसला किया कि चीजें कैसे चल रही थीं। मेरे आश्चर्य के लिए, मैंने पाया कि 2 घंटे में केवल 2% डेटा स्कैन किया गया था! मैं 50 दिन इंतजार नहीं करना चाहता था। एक और पूर्ण विफलता।

लेकिन मैंने हार नहीं मानी। मुझे आश्चर्य हुआ कि स्कैन में इतना समय क्यों लगा। प्रलेखन से (फिर से पोस्टग्रॉस्प्रो पर) मुझे पता चला:

OFFSET लाइनों का उत्पादन शुरू करने से पहले निर्दिष्ट संख्या को छोड़ देने का संकेत देता है।
यदि OFFSET और LIMIT दोनों को निर्दिष्ट किया जाता है, तो सिस्टम पहले OFFSET लाइनों को छोड़ देता है और फिर LIMIT को सीमित करने के लिए लाइनों की गिनती शुरू करता है।

लिमिट का उपयोग करते समय, ORDER BY क्लॉज का उपयोग करना भी महत्वपूर्ण है ताकि परिणाम लाइनों को एक विशिष्ट क्रम में लौटाया जा सके। अन्यथा, स्ट्रिंग्स के अप्रत्याशित सबसेट वापस आ जाएंगे।

जाहिर है, उपरोक्त आदेश गलत था: सबसे पहले, इसके द्वारा कोई आदेश नहीं था, परिणाम गलत हो सकता है। दूसरे, Postgres को पहले OFFSET लाइनों को स्कैन और छोड़ना पड़ता था, और OFFSET में वृद्धि के साथ , प्रदर्शन और भी कम हो जाता था।

प्रयास 4: पाठ रूप में डंप को हटा दें

इसके अलावा, एक शानदार विचार मेरे दिमाग में आया: पाठ रूप में डंप को हटाने और अंतिम दर्ज की गई रेखा का विश्लेषण करने के लिए।

लेकिन पहले, आइए ws_log_smevlog तालिका संरचना को देखें :

हमारे मामले में, हमारे पास एक कॉलम "आईडी" है , जिसमें पंक्ति के लिए एक विशिष्ट पहचानकर्ता (काउंटर) था। योजना यह थी:

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

मैंने पाठ रूप में डंप को हटाना शुरू किया:

 pg_dump -U my_user -d my_database -F p -t ws_log_smevlog -f ./my_dump.dump

डंप डंप, जैसा कि अपेक्षित था, उसी त्रुटि के साथ बाधित किया गया था:

 pg_dump: Error message from server: ERROR: invalid page in block 4123007 of relatton base/16490/21396989

इसके अलावा, पूंछ के माध्यम से , मैंने डंप ( पूंछ -5 ./my_dump.dump ) के अंत में देखा और पाया कि डंप को आईडी 186 525 के साथ लाइन पर बाधित किया गया था। "तो, समस्या आईडी 186 526 के अनुरूप है, यह टूट गया है, और इसे हटाने की आवश्यकता है!" मैंने सोचा। लेकिन डेटाबेस के लिए एक अनुरोध करके:
" चयन करें * ws_log_smevlog से जहां id = 186529 " यह पता चला कि इस लाइन के साथ सब कुछ ठीक था ... सूचकांक 186 530 - 186 540 के साथ लाइनों ने भी समस्याओं के बिना काम किया। एक और "शानदार विचार" विफल रहा। बाद में, मुझे समझ में आया कि ऐसा क्यों हुआ: तालिका से डेटा को हटाने / बदलने के दौरान, उन्हें भौतिक रूप से हटा नहीं दिया जाता है, लेकिन "मृत टुपल्स " के रूप में चिह्नित किया जाता है, फिर ऑटोवैक्यूम आता है और इन लाइनों को हटाए गए के रूप में चिह्नित करता है और इन पंक्तियों के फिर से उपयोग की अनुमति देता है। समझने के लिए, यदि तालिका में डेटा को बदल दिया गया है और ऑटोवैक्यूम चालू है, तो उन्हें क्रमिक रूप से संग्रहीत नहीं किया जाता है।

प्रयास 5: का चयन करें, से, कहाँ आईडी =

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

 for ((i=1; i<1628991; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

अगर कोई नहीं समझता है, तो कमांड निम्नानुसार काम करती है: यह टेबल लाइन को लाइन द्वारा स्कैन करता है और stdout को / dev / null को भेजता है, लेकिन यदि SELECT कमांड विफल हो जाता है, तो एरर टेक्स्ट प्रदर्शित होता है (Stderr को कंसोल पर भेजा जाता है) और एक लाइन जिसमें एरर आउटपुट होता है (धन्यवाद, जो) इसका मतलब है कि चुनिंदा समस्याएं थीं (कमांड रिटर्न कोड 0 नहीं है)।

मैं भाग्यशाली था, मुझे आईडी फ़ील्ड पर अनुक्रमित किया गया था:

इसका मतलब है कि वांछित आईडी के साथ लाइन खोजने में अधिक समय नहीं लेना चाहिए। सिद्धांत रूप में, यह काम करना चाहिए। खैर, tmux में कमांड चलाएँ और सो जाएँ।

सुबह तक, मैंने पाया कि लगभग 90,000 रिकॉर्ड देखे गए, जो अभी 5% से अधिक है। पिछली विधि (2%) के साथ तुलना करने पर उत्कृष्ट परिणाम! लेकिन मैं 20 दिन इंतजार नहीं करना चाहता था ...

प्रयास 6: का चयन करें, से, कहाँ आईडी = = और आईडी <

डेटाबेस के तहत ग्राहक के लिए एक उत्कृष्ट सर्वर आवंटित किया गया था: हमारे प्रोसेसर में दोहरे प्रोसेसर इंटेल एक्सोन E5-2697 v2 थे , हमारे स्थान में 48 धागे थे! सर्वर लोड औसत था, हम बिना किसी समस्या के लगभग 20 धागे ले सकते थे। RAM भी पर्याप्त थी: 384 गीगाबाइट जितना!

इसलिए, कमांड को समानांतर करने की आवश्यकता है:

 for ((i=1; i<1628991; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

यहां एक सुंदर और सुरुचिपूर्ण स्क्रिप्ट लिखना संभव था, लेकिन मैंने समानांतर बनाने के लिए सबसे तेज़ तरीका चुना: मैन्युअल रूप से 0-1628991 रेंज को 100,000 रिकॉर्ड के अंतराल में तोड़ दें और फॉर्म के 16 आदेशों को अलग से चलाएं:

 for ((i=N; i<M; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

लेकिन यह सब नहीं है। सिद्धांत रूप में, डेटाबेस से जुड़ने में कुछ समय और सिस्टम संसाधन भी लगते हैं। 1,628,991 को जोड़ना बहुत उचित नहीं था, सहमत हूँ। इसलिए, चलो एक के बजाय एक कनेक्शन में 1000 पंक्तियां निकालें। परिणामस्वरूप, टीम इस में बदल गई:

 for ((i=N; i<M; i=$((i+1000)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done

Tmux सत्र में 16 विंडो खोलें और कमांड चलाएँ:

 1) for ((i=0; i<100000; i=$((i+1000)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done 2) for ((i=100000; i<200000; i=$((i+1000)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done … 15) for ((i=1400000; i<1500000; i=$((i+1000)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done 16) for ((i=1500000; i<1628991; i=$((i+1000)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done

एक दिन बाद, मुझे पहला परिणाम मिला! अर्थात् (मान XXX और ZZZ को संरक्षित नहीं किया गया है):

 ERROR: missing chunk number 0 for toast value 37837571 in pg_toast_106070 829000 ERROR: missing chunk number 0 for toast value XXX in pg_toast_106070 829000 ERROR: missing chunk number 0 for toast value ZZZ in pg_toast_106070 146000

इसका मतलब है कि हमारे पास एक त्रुटि वाली तीन लाइनें हैं। पहली और दूसरी समस्या रिकॉर्ड की आईडी 829,000 और 830,000 के बीच थी, तीसरे की आईडी 146,000 और 147,000 के बीच थी। इसके बाद, हमें सिर्फ समस्या के रिकॉर्ड का सही आईडी मान खोजना था। ऐसा करने के लिए, चरण 1 में समस्या रिकॉर्ड के साथ हमारी सीमा देखें और आईडी की पहचान करें:

 for ((i=829000; i<830000; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done 829417 ERROR: unexpected chunk number 2 (expected 0) for toast value 37837843 in pg_toast_106070 829449 for ((i=146000; i<147000; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done 829417 ERROR: unexpected chunk number ZZZ (expected 0) for toast value XXX in pg_toast_106070 146911

सुखद अंत

हमें समस्याग्रस्त रेखाएँ मिलीं। हम psql के माध्यम से डेटाबेस में जाते हैं और उन्हें हटाने की कोशिश करते हैं:

 my_database=# delete from ws_log_smevlog where id=829417; DELETE 1 my_database=# delete from ws_log_smevlog where id=829449; DELETE 1 my_database=# delete from ws_log_smevlog where id=146911; DELETE 1

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

फिर मैं डेटाबेस से जुड़ा, VACUUM FULL बनाया (मुझे लगता है कि ऐसा करना आवश्यक नहीं था), और आखिरकार pg_dump का उपयोग करके बैकअप को सफलतापूर्वक हटा दिया गया। डंप बिना किसी त्रुटि के अभिनय किया! इस तरह की बेवकूफी में समस्या हल हो गई। आनंद की कोई सीमा नहीं थी, इतनी असफलताओं के बाद हम एक समाधान खोजने में कामयाब रहे!

आभार और निष्कर्ष

यह एक वास्तविक Postgres डेटाबेस को पुनर्स्थापित करने में मेरा पहला अनुभव है। मैं इस अनुभव को लंबे समय तक याद रखूंगा।

और अंत में, मैं रूसी में अनुवादित प्रलेखन के लिए PostgresPro को धन्यवाद देना चाहता हूं और पूरी तरह से मुफ्त ऑनलाइन पाठ्यक्रमों के लिए जिसने समस्या के विश्लेषण के दौरान बहुत मदद की।