🥇विफलता के बाद पोस्टग्रेज डेटाबेस को पुनर्प्राप्त करने का मेरा पहला अनुभव (रिलैटन बेस/4123007 के ब्लॉक 16490 में अमान्य पृष्ठ)

मैं आपके साथ पोस्टग्रेज डेटाबेस को पूर्ण कार्यक्षमता में पुनर्स्थापित करने का अपना पहला सफल अनुभव साझा करना चाहता हूं। मैं आधे साल पहले पोस्टग्रेस डीबीएमएस से परिचित हुआ; इससे पहले मुझे डेटाबेस प्रशासन में कोई अनुभव नहीं था।

मैं एक बड़ी आईटी कंपनी में सेमी-डेवऑप्स इंजीनियर के रूप में काम करता हूं। हमारी कंपनी उच्च-लोड सेवाओं के लिए सॉफ्टवेयर विकसित करती है, और मैं प्रदर्शन, रखरखाव और तैनाती के लिए जिम्मेदार हूं। मुझे एक मानक कार्य दिया गया था: एक सर्वर पर एक एप्लिकेशन को अपडेट करना। एप्लिकेशन 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

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

पुनर्प्राप्ति की तैयारी

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

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

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

फ़ाइल सिस्टम जाँच

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

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

डेटाबेस रोकना: systemctl बंद करो [ईमेल संरक्षित] और जांचें कि फ़ाइल सिस्टम किसी के द्वारा उपयोग में नहीं है और कमांड का उपयोग करके अनमाउंट किया जा सकता है एलसोफे:
एलएसओएफ +डी /एसआरवी

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

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

अगला, उपयोगिता का उपयोग करना Dumpe2fs (sudo Dume2fs /dev/mapper/gu2—sys-srv | ग्रेप की जाँच की गई) आप सत्यापित कर सकते हैं कि चेक वास्तव में किया गया था:

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

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

प्रयास 1: शून्य_क्षतिग्रस्त_पृष्ठ

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

psql -h 127.0.0.1 -U पोस्टग्रेज -s [डेटाबेस_नाम]

विकल्प शून्य_क्षतिग्रस्त_पेज पढ़ने की त्रुटियों को अनदेखा करने के लिए आवश्यक (पोस्टग्रेसप्रो वेबसाइट से):

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

हम विकल्प को सक्षम करते हैं और तालिकाओं का पूर्ण वैक्यूम करने का प्रयास करते हैं:

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_टोस्ट - पोएटग्रेज़ में "लंबा डेटा" संग्रहीत करने के लिए एक तंत्र यदि यह एक पृष्ठ पर फिट नहीं होता है (डिफ़ॉल्ट रूप से 8kb)।

प्रयास 2: पुनः अनुक्रमणिका

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

reindex table ws_log_smevlog

अनुक्रमणः बिना किसी समस्या के पूरा हुआ.

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

प्रयास 3: चयन करें, सीमित करें, ऑफ़सेट करें

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

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

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

लेकिन मैंने हार नहीं मानी. मुझे आश्चर्य हुआ कि स्कैनिंग में इतना समय क्यों लगा। दस्तावेज़ीकरण से (फिर से पोस्टग्रेसप्रो पर) मुझे पता चला:

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

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

जाहिर है, उपरोक्त आदेश गलत था: सबसे पहले, कोई नहीं था द्वारा आदेश, परिणाम ग़लत हो सकता है। दूसरे, पोस्टग्रेज़ को सबसे पहले 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 के अनुरूप है, यह टूटा हुआ है, और इसे हटाने की जरूरत है!" - मैंने सोचा। लेकिन, डेटाबेस से एक क्वेरी बनाना:
«ws_log_smevlog से * चुनें जहां id=186529"यह पता चला कि इस लाइन के साथ सब कुछ ठीक था... 186 - 530 सूचकांक वाली पंक्तियाँ भी बिना किसी समस्या के काम करती थीं। एक और "शानदार विचार" विफल हो गया। बाद में मुझे समझ आया कि ऐसा क्यों हुआ: किसी तालिका से डेटा हटाते और बदलते समय, उन्हें भौतिक रूप से हटाया नहीं जाता है, बल्कि "मृत टुपल्स" के रूप में चिह्नित किया जाता है, फिर आता है ऑटोवैक्यूम और इन पंक्तियों को हटाए गए के रूप में चिह्नित करता है और इन पंक्तियों को पुन: उपयोग करने की अनुमति देता है। समझने के लिए, यदि तालिका में डेटा बदलता है और ऑटोवैक्यूम सक्षम है, तो यह क्रमिक रूप से संग्रहीत नहीं होता है।

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

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

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 / बातिल, लेकिन यदि SELECT कमांड विफल हो जाता है, तो त्रुटि टेक्स्ट मुद्रित होता है (stderr कंसोल पर भेजा जाता है) और त्रुटि वाली एक पंक्ति मुद्रित होती है (|| के लिए धन्यवाद, जिसका अर्थ है कि चयन में समस्याएं थीं (कमांड का रिटर्न कोड) 0 नहीं है)).

मैं भाग्यशाली था, मेरे पास फ़ील्ड पर इंडेक्स बनाए गए थे id:

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

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

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

ग्राहक के पास डेटाबेस के लिए समर्पित एक उत्कृष्ट सर्वर था: डुअल-प्रोसेसर इंटेल Xeon E5-2697 v2, हमारे स्थान पर लगभग 48 धागे थे! सर्वर पर लोड औसत था; हम बिना किसी समस्या के लगभग 20 थ्रेड डाउनलोड कर सकते थे। रैम भी पर्याप्त थी: 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 कमांड को अलग से चलाया:

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 पंक्तियाँ पुनः प्राप्त करें। परिणामस्वरूप, टीम इस प्रकार परिवर्तित हो गई:

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 चरण के साथ समस्याग्रस्त रिकॉर्ड के साथ अपनी सीमा को देखते हैं और आईडी की पहचान करते हैं:

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

मुझे आश्चर्य हुआ कि विकल्प के बिना भी प्रविष्टियाँ बिना किसी समस्या के हटा दी गईं शून्य_क्षतिग्रस्त_पेज.

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

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

वास्तविक पोस्टग्रेज़ डेटाबेस को पुनर्स्थापित करने का मेरा पहला अनुभव इस प्रकार निकला। यह अनुभव मुझे लंबे समय तक याद रहेगा.

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

स्रोत: www.habr.com