असफलता पछि पोस्टग्रेस डाटाबेस रिकभर गर्ने मेरो पहिलो अनुभव (relatton base/4123007 को ब्लक 16490 मा अमान्य पृष्ठ)

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

म एउटा ठूलो IT कम्पनीमा अर्ध-DevOps इन्जिनियरको रूपमा काम गर्छु। हाम्रो कम्पनीले उच्च-लोड सेवाहरूको लागि सफ्टवेयर विकास गर्दछ, र म कार्यसम्पादन, मर्मत र परिनियोजनको लागि जिम्मेवार छु। मलाई एउटा मानक कार्य दिइएको थियो: एउटा सर्भरमा एउटा अनुप्रयोग अद्यावधिक गर्न। अनुप्रयोग Django मा लेखिएको छ, अद्यावधिक माइग्रेसन को समयमा प्रदर्शन गरिन्छ (डेटाबेस संरचना मा परिवर्तन), र यो प्रक्रिया अघि हामी मानक pg_dump कार्यक्रम मार्फत एक पूर्ण डाटाबेस डम्प लिन्छ, केवल मामला मा।

डम्प (Postgres संस्करण 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

त्रुटि "ब्लकमा अवैध पृष्ठ" फाइल प्रणाली स्तरमा समस्याहरू बोल्छ, जुन धेरै खराब छ। विभिन्न फोरमहरूमा यो गर्न सुझाव दिइएको थियो पूर्ण भ्याकुम विकल्प संग zero_damaged_pages यो समस्या समाधान गर्न। खैर, प्रयास गरौं ...

रिकभरीको लागि तयारी गर्दै

ATTENTION! तपाइँको डाटाबेस पुनर्स्थापना गर्न कुनै पनि प्रयास गर्नु अघि पोस्टग्रेस ब्याकअप लिन निश्चित हुनुहोस्। यदि तपाईंसँग भर्चुअल मेसिन छ भने, डाटाबेस रोक्नुहोस् र स्न्यापसट लिनुहोस्। यदि स्न्यापसट लिन सम्भव छैन भने, डाटाबेस रोक्नुहोस् र पोस्टग्रेस डाइरेक्टरीका सामग्रीहरू (वाल फाइलहरू सहित) सुरक्षित ठाउँमा प्रतिलिपि गर्नुहोस्। हाम्रो व्यवसायमा मुख्य कुरा चीजहरू खराब बनाउनु हुँदैन। पढ्नुहोस् यसलाई.

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

सर्भर भौतिक थियो, स्न्यापसट लिन असम्भव थियो। ब्याकअप हटाइएको छ, अगाडि बढौं।

फाइल प्रणाली जाँच

डाटाबेस पुनर्स्थापना गर्ने प्रयास गर्नु अघि, हामीले फाइल प्रणालीमा सबै कुरा ठीक छ भनी सुनिश्चित गर्न आवश्यक छ। र गल्तीहरूको अवस्थामा, तिनीहरूलाई सुधार्नुहोस्, किनभने अन्यथा तपाईले चीजहरू खराब बनाउन सक्नुहुन्छ।

मेरो केसमा, डाटाबेसको साथ फाइल प्रणाली माउन्ट गरिएको थियो "/srv" र प्रकार ext4 थियो।

डाटाबेस रोक्दै: systemctl रोक्नुहोस् [ईमेल सुरक्षित] र जाँच गर्नुहोस् कि फाइल प्रणाली कसैद्वारा प्रयोगमा छैन र आदेश प्रयोग गरेर अनमाउन्ट गर्न सकिन्छ lsof:
lsof +D /srv

मैले रेडिस डाटाबेस पनि रोक्नु पर्यो, किनकि यो पनि प्रयोग गरिरहेको थियो "/srv"। अर्को मैले अनमाउन्ट गरें / srv (उमाउन्ट)।

फाइल प्रणाली उपयोगिता प्रयोग गरेर जाँच गरियो e2fsck स्विचको साथ -f (फाइल प्रणाली सफा चिन्ह लगाइएको भए पनि बल जाँच गर्नुहोस्):

अर्को, उपयोगिता प्रयोग गर्दै dumpe2fs (sudo dumpe2fs /dev/mapper/gu2—sys-srv | grep जाँच गरियो) तपाईंले जाँच वास्तवमा प्रदर्शन गरिएको थियो भनेर प्रमाणित गर्न सक्नुहुन्छ:

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

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

प्रयास 1: zero_damaged_pages

हामी psql मार्फत डाटाबेसमा जडान गर्छौं जसमा सुपर प्रयोगकर्ता अधिकारहरू छन्। हामीलाई सुपर प्रयोगकर्ता चाहिन्छ, किनकि... विकल्प zero_damaged_pages उहाँले मात्र परिवर्तन गर्न सक्नुहुन्छ। मेरो मामला मा यो postgres हो:

psql -h 127.0.0.1 -U postgres -s [database_name]

विकल्प zero_damaged_pages पढ्ने त्रुटिहरू बेवास्ता गर्न आवश्यक छ (postgrespro वेबसाइटबाट):

जब PostgreSQL ले भ्रष्ट पृष्ठ हेडर पत्ता लगाउँछ, यसले सामान्यतया त्रुटि रिपोर्ट गर्छ र हालको लेनदेन रद्द गर्दछ। यदि zero_damaged_pages सक्षम छ भने, प्रणालीले यसको सट्टा चेतावनी जारी गर्दछ, मेमोरीमा क्षतिग्रस्त पृष्ठलाई शून्य गर्छ, र प्रक्रिया जारी राख्छ। यो व्यवहारले डाटा नष्ट गर्छ, अर्थात् क्षतिग्रस्त पृष्ठमा सबै पङ्क्तिहरू।

हामी विकल्प सक्षम गर्छौं र तालिकाहरूको पूर्ण वैक्यूम गर्ने प्रयास गर्छौं:

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 - Poetgres मा "लामो डाटा" भण्डारण गर्न को लागी एक संयन्त्र यदि यो एक पृष्ठमा फिट छैन (पूर्वनिर्धारित रूपमा 8kb)।

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

Google को पहिलो सल्लाहले मद्दत गरेन। केहि मिनेटको खोजी पछि, मैले दोस्रो टिप फेला पारे - बनाउन reindex क्षतिग्रस्त तालिका। मैले धेरै ठाउँमा यो सल्लाह देखे, तर यसले आत्मविश्वासलाई प्रेरित गरेन। पुन: अनुक्रमणिका गरौं:

reindex table ws_log_smevlog

reindex समस्या बिना पूरा।

तर, यसले सहयोग गरेन, भ्याकुम फुल समान त्रुटि संग दुर्घटना भयो। म असफलताको बानी भएकोले, मैले इन्टरनेटमा सल्लाहको लागि थप हेर्न थालेँ र एक रोचक कुरा भेटें लेख.

प्रयास ३: चयन, सीमा, अफसेट

माथिको लेखले पङ्क्तिद्वारा तालिका पङ्क्ति हेर्न र समस्याग्रस्त डेटा हटाउन सुझाव दियो। पहिले हामीले सबै लाइनहरू हेर्न आवश्यक छ:

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 दिन पर्खन चाहन्न। अर्को पूर्ण असफलता।

तर मैले हार मानिन । मलाई किन स्क्यानिङले यति लामो समय लाग्यो भनेर सोचें। कागजातबाट (फेरि postgrespro मा) मैले फेला पारे:

OFFSET ले आउटपुट पङ्क्तिहरू सुरु गर्नु अघि पङ्क्तिहरूको निर्दिष्ट संख्या छोड्न निर्दिष्ट गर्दछ।
यदि OFFSET र LIMIT दुवै निर्दिष्ट गरिएको छ भने, प्रणालीले पहिले OFFSET पङ्क्तिहरू छोड्छ र त्यसपछि LIMIT अवरोधका लागि पङ्क्तिहरू गणना गर्न थाल्छ।

LIMIT प्रयोग गर्दा, ORDER BY खण्ड प्रयोग गर्नु पनि महत्त्वपूर्ण छ ताकि परिणाम पङ्क्तिहरू निश्चित क्रममा फर्काइन्छ। अन्यथा, पङ्क्तिहरूको अप्रत्याशित उपसेटहरू फर्काइनेछ।

जाहिर छ, माथिको आदेश गलत थियो: पहिले, त्यहाँ थिएन द्वारा क्रम, परिणाम गलत हुन सक्छ। दोस्रो, पोस्टग्रेसले पहिले स्क्यान गर्नुपर्‍यो र अफसेट पङ्क्तिहरू छोड्नुपर्‍यो, र बढ्दै जाँदा OFFSET उत्पादकता अझै घट्नेछ।

प्रयास ४: पाठ फारममा डम्प लिनुहोस्

त्यसपछि मेरो दिमागमा एक शानदार विचार आयो: पाठ फारममा डम्प लिनुहोस् र अन्तिम रेकर्ड गरिएको लाइनको विश्लेषण गर्नुहोस्।

तर पहिले, तालिकाको संरचनालाई हेरौं। ws_log_smevlog:

हाम्रो मामला मा हामी एक स्तम्भ छ "आईडी", जसमा पङ्क्तिको अद्वितीय पहिचानकर्ता (काउन्टर) समावेश छ। योजना यस्तो थियो:

1. हामी पाठ फारममा डम्प लिन सुरु गर्छौं (sql आदेशहरूको रूपमा)
2. समयको एक निश्चित बिन्दुमा, त्रुटिको कारण डम्प अवरोध हुनेछ, तर पाठ फाइल अझै डिस्कमा बचत हुनेछ।
3. हामी पाठ फाइलको अन्त्यमा हेर्छौं, यसैले हामीले अन्तिम रेखाको पहिचानकर्ता (आईडी) फेला पार्छौं जुन सफलतापूर्वक हटाइयो।

मैले पाठ फारममा डम्प लिन थाले:

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

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

प्रयास ५: SELECT, FROM, HERE id=

असफलताले हामीलाई बलियो बनाउँछ। तपाईंले कहिल्यै हार मान्नु हुँदैन, तपाईंले अन्त्यमा जानु पर्छ र आफू र आफ्नो क्षमताहरूमा विश्वास गर्नुपर्छ। त्यसोभए मैले अर्को विकल्प प्रयास गर्ने निर्णय गरें: केवल डाटाबेसमा सबै रेकर्डहरू एक-एक गरेर हेर्नुहोस्। मेरो तालिकाको संरचना थाहा पाउँदा (माथि हेर्नुहोस्), हामीसँग एउटा आईडी फिल्ड छ जुन अद्वितीय छ (प्राथमिक कुञ्जी)। हामीसँग तालिकामा 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 / null, तर यदि SELECT आदेश असफल भयो भने, त्रुटि पाठ छापिएको छ (stderr कन्सोलमा पठाइन्छ) र त्रुटि समावेश भएको लाइन छापिएको छ (धन्यवाद ||, जसको मतलब चयनमा समस्याहरू थिए (आदेशको फिर्ता कोड। ० होइन))।

म भाग्यमानी थिएँ, मैले फिल्डमा अनुक्रमणिकाहरू सिर्जना गरेको थिएँ id:

यसको मतलब इच्छित आईडीको साथ लाइन फेला पार्न धेरै समय लिनु हुँदैन। सिद्धान्तमा काम गर्नुपर्छ। ठीक छ, कमाण्ड भित्र चलाउनुहोस् tmux र ओछ्यानमा जाऔं।

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

प्रयास 6: SELECT, FROM, HERE id >= र id

ग्राहकसँग डेटाबेसमा समर्पित उत्कृष्ट सर्भर थियो: डुअल-प्रोसेसर Intel Xeon 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 आदेशहरू अलग-अलग चलाउनुहोस्:

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

मेरो आश्चर्यको लागि, प्रविष्टिहरू कुनै पनि समस्या बिना विकल्प बिना मेटाइयो zero_damaged_pages.

त्यसपछि मैले डाटाबेसमा जडान गरें, गरें भ्याकुम फुल (मलाई लाग्छ कि यो गर्न आवश्यक थिएन), र अन्तमा मैले सफलतापूर्वक ब्याकअप प्रयोग गरेर हटाएँ pg_dump। डम्प कुनै त्रुटि बिना लिइएको थियो! यस्तो मूर्ख तरिकाले समस्या हल भयो। खुशीको कुनै सीमा थिएन, धेरै असफलता पछि हामीले समाधान खोज्न सफल भयौं!

स्वीकृति र निष्कर्ष

यो कसरी एक वास्तविक Postgres डाटाबेस पुनर्स्थापना को मेरो पहिलो अनुभव बाहिर भयो। यो अनुभव म लामो समय सम्म सम्झनेछु।

र अन्तमा, म पोष्टग्रेसप्रोलाई रूसी र यसको लागि कागजात अनुवाद गर्नको लागि धन्यवाद भन्न चाहन्छु पूर्ण रूपमा नि: शुल्क अनलाइन पाठ्यक्रमहरू, जसले समस्याको विश्लेषण गर्दा धेरै मद्दत गर्यो।

स्रोत: www.habr.com