הניסיון הראשון שלי בשחזור מסד נתונים Postgres לאחר כשל (דף לא חוקי בבלוק 4123007 של relatton base/16490)

אני רוצה לשתף אתכם בחוויה המוצלחת הראשונה שלי בשחזור מסד נתונים Postgres לפונקציונליות מלאה. הכרתי את Postgres DBMS לפני חצי שנה, לפני כן לא היה לי ניסיון בניהול מסדי נתונים כלל.

אני עובד כמהנדס DevOps למחצה בחברת IT גדולה. החברה שלנו מפתחת תוכנה לשירותי עומס גבוה, ואני אחראי על ביצועים, תחזוקה ופריסה. קיבלתי משימה סטנדרטית: לעדכן אפליקציה בשרת אחד. האפליקציה כתובה ב-Django, במהלך העדכון מתבצעות העברות (שינויים במבנה בסיס הנתונים), ולפני תהליך זה אנו לוקחים dump בסיס נתונים מלא דרך תוכנת pg_dump הרגילה, ליתר ביטחון.

אירעה שגיאה בלתי צפויה בעת ביצוע 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

חרק "דף לא חוקי בבלוק" מדבר על בעיות ברמת מערכת הקבצים, וזה רע מאוד. בפורומים שונים הוצע לעשות ואקום מלא עם אפשרות אפס_דפים_פגומים לפתור את הבעיה הזאת. ובכן, בואו ננסה...

מתכוננים להחלמה

אזהרה! הקפד לקחת גיבוי Postgres לפני כל ניסיון לשחזר את מסד הנתונים שלך. אם יש לך מכונה וירטואלית, עצור את מסד הנתונים וצלם תמונת מצב. אם לא ניתן לצלם תמונת מצב, עצור את מסד הנתונים והעתק את התוכן של ספריית Postgres (כולל קבצי wal) למקום בטוח. העיקר בעסק שלנו הוא לא להחמיר את המצב. לקרוא זה.

מכיוון שמסד הנתונים בדרך כלל עבד בשבילי, הגבלתי את עצמי ל-dump רגיל של מסד נתונים, אך לא כללתי את הטבלה עם נתונים פגומים (אפשרות -T, --exclude-table=TABLE ב-pg_dump).

השרת היה פיזי, אי אפשר היה לצלם תמונת מצב. הגיבוי הוסר, בואו נמשיך.

בדיקת מערכת קבצים

לפני שננסה לשחזר את מסד הנתונים, עלינו לוודא שהכל בסדר עם מערכת הקבצים עצמה. ובמקרה של טעויות, תקן אותן, כי אחרת אתה יכול רק להחמיר את המצב.

במקרה שלי, מערכת הקבצים עם מסד הנתונים הייתה מורכבת "/srv" והסוג היה ext4.

עצירת מסד הנתונים: systemctl עצור [מוגן בדוא"ל] ובדוק שמערכת הקבצים אינה בשימוש על ידי אף אחד וניתן לבטל אותה באמצעות הפקודה לסוף:
lsof +D /srv

נאלצתי גם לעצור את מסד הנתונים של redis, מכיוון שהוא גם משתמש "/srv". בשלב הבא התנתקתי / srv (umount).

מערכת הקבצים נבדקה באמצעות כלי השירות e2fsck עם המתג -f (כפה בדיקה גם אם מערכת הקבצים מסומנת נקייה):

לאחר מכן, באמצעות כלי השירות dumpe2fs (sudo dumpe2fs /dev/mapper/gu2—sys-srv | grep בדק) תוכל לוודא שהבדיקה אכן בוצעה:

e2fsck אומר שלא נמצאו בעיות ברמת מערכת הקבצים ext4, מה שאומר שאתה יכול להמשיך לנסות לשחזר את מסד הנתונים, או יותר נכון לחזור אל ואקום מלא (כמובן, אתה צריך להעלות את מערכת הקבצים בחזרה ולהפעיל את מסד הנתונים).

אם יש לך שרת פיזי, הקפד לבדוק את מצב הדיסקים (via smartctl -a /dev/XXX) או בקר RAID כדי לוודא שהבעיה אינה ברמת החומרה. במקרה שלי, ה-RAID התברר כ"חומרה", אז ביקשתי מהמנהל המקומי לבדוק את מצב ה-RAID (השרת היה במרחק כמה מאות קילומטרים ממני). הוא אמר שלא היו שגיאות, מה שאומר שאנחנו בהחלט יכולים להתחיל בשיקום.

ניסיון 1: אפס_דפים_פגומים

אנו מתחברים למסד הנתונים באמצעות psql עם חשבון בעל זכויות משתמש-על. אנחנו צריכים משתמש-על, כי... אוֹפְּצִיָה אפס_דפים_פגומים רק הוא יכול לשנות. במקרה שלי זה postgres:

psql -h 127.0.0.1 -U postgres -s [שם_בסיס הנתונים]

אפשרות אפס_דפים_פגומים נדרש על מנת להתעלם משגיאות קריאה (מאתר 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 כברירת מחדל).

ניסיון 2: אינדקס מחדש

העצה הראשונה מגוגל לא עזרה. אחרי כמה דקות של חיפוש מצאתי את הטיפ השני - להכין רנדקס שולחן פגום. ראיתי את העצה הזו במקומות רבים, אבל היא לא עוררה אמון. בוא נעשה אינדקס מחדש:

reindex table ws_log_smevlog

רנדקס הושלם ללא בעיות.

אבל זה לא עזר, ואקום מלא קרס עם שגיאה דומה. מכיוון שאני רגיל לכישלונות, התחלתי לחפש עוד עצות באינטרנט ונתקלתי במשהו מעניין למדי מאמר.

ניסיון 3: SELECT, LIMIT, 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

בבוקר החלטתי לבדוק איך הדברים מתנהלים. להפתעתי גיליתי שאחרי 20 שעות רק 2% מהנתונים נסרקו! לא רציתי לחכות 50 יום. עוד כישלון מוחלט.

אבל לא ויתרתי. תהיתי למה הסריקה ארכה כל כך הרבה זמן. מהתיעוד (שוב ב-postgrespro) גיליתי:

OFFSET מציין לדלג על מספר השורות שצוין לפני תחילת הפלט של שורות.
אם צוינו גם OFFSET וגם LIMIT, המערכת מדלגת תחילה על שורות ה-OFFSET ולאחר מכן מתחילה לספור את השורות עבור אילוץ LIMIT.

בעת שימוש ב-LIMIT, חשוב להשתמש גם בסעיף ORDER BY כך ששורות התוצאה יוחזרו בסדר מסוים. אחרת, תת-קבוצות בלתי צפויות של שורות יוחזרו.

ברור שהפקודה לעיל הייתה שגויה: ראשית, לא היה סדר לפי, התוצאה עלולה להיות שגויה. שנית, Postgres תחילה היה צריך לסרוק ולדלג על שורות OFFSET, ועם הגדלת OFFSET הפרודוקטיביות תרד עוד יותר.

ניסיון 4: קח dump בצורת טקסט

ואז עלה במוחי רעיון מבריק לכאורה: קח dump בצורת טקסט ונתח את השורה האחרונה שהוקלטה.

אבל ראשית, בואו נסתכל על מבנה הטבלה. ws_log_smevlog:

במקרה שלנו יש לנו טור "תְעוּדַת זֶהוּת", שהכיל את המזהה (המונה) הייחודי של השורה. התוכנית הייתה כזו:

1. אנחנו מתחילים לקחת dump בצורת טקסט (בצורה של פקודות sql)
2. בנקודת זמן מסוימת, ה-dump יופסק עקב שגיאה, אך קובץ הטקסט עדיין יישמר בדיסק
3. אנו מסתכלים בסוף קובץ הטקסט, ובכך אנו מוצאים את המזהה (מזהה) של השורה האחרונה שהוסרה בהצלחה

התחלתי לקחת dump בצורת טקסט:

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

ה-dump, כצפוי, הופסק עם אותה שגיאה:

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

בהמשך הדרך זנב הסתכלתי על קצה המזבלה (זנב -5 ./my_dump.dump) גילה שהמזבלה נקטעה בקו עם id 186 525. "אז הבעיה היא בקנה אחד עם id 186 526, זה שבור, וצריך למחוק אותו!" - חשבתי. אבל, ביצוע שאילתה למסד הנתונים:
«בחר * מתוך ws_log_smevlog שבו id=186529"התברר שהכל בסדר עם הקו הזה... גם שורות עם מדדים 186 - 530 עבדו ללא בעיות. עוד "רעיון מבריק" נכשל. מאוחר יותר הבנתי למה זה קרה: כשמוחקים ומשנים נתונים מטבלה, הם לא נמחקים פיזית, אלא מסומנים כ"טופלים מתים", ואז מגיע ואקום אוטומטי ומסמן שורות אלו כמחוקות ומאפשר שימוש חוזר בשורות אלו. כדי להבין, אם הנתונים בטבלה משתנים ו-autovacuum מופעל, אז הם לא מאוחסנים ברצף.

ניסיון 5: SELECT, FROM, WHERE 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 נשלח לקונסולה) ומודפסת שורה המכילה את השגיאה (תודה ל-||, מה שאומר שה-select היה בעיות (קוד ההחזרה של הפקודה אינו 0)).

היה לי מזל, יצרו לי אינדקסים בשטח id:

המשמעות היא שמציאת קו עם המזהה הרצוי לא אמורה לקחת הרבה זמן. בתיאוריה זה אמור לעבוד. ובכן, בוא נריץ את הפקודה פנימה tmux ובוא נלך לישון.

עד הבוקר גיליתי שנצפו כ-90 ערכים, שהם קצת יותר מ-000%. תוצאה מצוינת בהשוואה לשיטה הקודמת (5%)! אבל לא רציתי לחכות 2 יום...

ניסיון 6: SELECT, FROM, WHERE 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

פתח 16 חלונות בהפעלת tmux והפעל את הפקודות:

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

להפתעתי, הערכים נמחקו ללא בעיות גם ללא אפשרות אפס_דפים_פגומים.

ואז התחברתי למסד הנתונים, עשיתי ואקום מלא (אני חושב שלא היה צורך לעשות זאת), ולבסוף הסרתי בהצלחה את הגיבוי באמצעות pg_dump. המזבלה נלקחה ללא שגיאות! הבעיה נפתרה בצורה כל כך מטופשת. השמחה לא ידעה גבול, אחרי כל כך הרבה כישלונות הצלחנו למצוא פתרון!

תודות ומסקנה

כך התברר הניסיון הראשון שלי בשחזור מסד נתונים אמיתי של Postgres. אני אזכור את החוויה הזו עוד הרבה זמן.

ולבסוף, ברצוני לומר תודה ל-PostgresPro על תרגום התיעוד לרוסית ועבור קורסים מקוונים בחינם לחלוטין, מה שעזר מאוד במהלך ניתוח הבעיה.

מקור: www.habr.com