עבור לתוכן
Alex Kovalev

איך לתקן טבלת MySQL שקרסה בוורדפרס

מה המשמעות של "table is marked as crashed" בוורדפרס, שורת ה-SQL האחת שבדרך כלל מתקנת את זה, ומה עושים כשהיא לא.

2דקות קריאה

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

Table ’./database_name/wp_options’ is marked as crashed and last (automatic?) repair failed

שימו לב לסימן השאלה ב-”(automatic?)”. אפילו MySQL לא בטוח מה הוא ניסה לעשות. בתרגום חופשי: טבלה נכתבה רק חצי, MySQL כבר לא סומך עליה, והתיקון שלו עצמו לא עבד.

מה זה בעצם אומר “טבלה שקרסה”?

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

  • השרת נגמר לו מקום בדיסק באמצע כתיבה
  • הפעלה מחדש בלתי צפויה של השרת או הפסקת חשמל
  • בעיות חומרה בכונן האחסון
  • תהליך ה-MySQL נהרג במהלך עדכון

MySQL שם לב, מסמן את הטבלה כ”crashed” ומנסה לתקן אותה בעצמו. כשגם זה נכשל, אתם מקבלים את השגיאה שלמעלה, ועכשיו התור שלכם.

איך מזהים את הבעיה

אם האתר לא נותן לכם שום דבר מועיל (שלי לא נתן), תשאלו את MySQL ישירות:

CHECK TABLE wp_options;

אם הטבלה פגומה, תראו סטטוס כמו Table is marked as crashed בתוצאות.

התיקון

הריצו את פקודת ה-SQL הזאת דרך phpMyAdmin או הלקוח שלכם ל-MySQL:

REPAIR TABLE wp_options USE_FRM;

MyISAM · מסומנת כקורסת

Server version: 8.0.36 MySQL Community Server - GPL
mysql> SELECT option_value FROM wp_options WHERE option_name = 'siteurl';
ERROR 144 (HY000): Table './database_name/wp_options' is marked as crashed and last (automatic?) repair failed
תורכם. בדקו, תקנו, בדקו שוב. אחר כך העבירו ל-InnoDB ונסו לשבור שוב.

הדגל USE_FRM אומר ל-MySQL לבנות מחדש את מבנה הטבלה באמצעות קובץ ה-.frm (הגדרת הטבלה), גם אם קובץ האינדקס פגום. זה אגרסיבי יותר מתיקון רגיל ועובד כאשר תיקון אוטומטי נכשל.

הערה עבור MySQL 8.0+: אין שם יותר קבצי .frm, אבל USE_FRM עדיין עובד: הוא בונה מחדש את כותרת האינדקס ממילון הנתונים. נסו קודם REPAIR TABLE wp_options; רגיל, כי USE_FRM גם מאפס את מונה ה-AUTO_INCREMENT.

אתם אמורים לראות פלט שמאשר שהתיקון הצליח:

TableOpMsg_typeMsg_text
database.wp_optionsrepairstatusOK

טיפים למניעה

  • עקבו אחרי מקום פנוי בדיסק — רוב הקריסות קורות כשלשרת נגמר המקום
  • השתמשו ב-InnoDB — היא מתמודדת עם קריסות בהרבה יותר חן מ-MyISAM
  • גיבויים סדירים — לפעמים פגיעה הורסת נתונים שאפילו repair לא יכול לשחזר

כשתיקון לא מספיק

אם גם REPAIR TABLE נכשל, נשארתם עם שחזור מגיבוי או בנייה מחדש של הטבלה מאפס. ו-wp_options זה המקום שבו וורדפרס שומר את כתובת האתר, את התוספים הפעילים ואת הגדרות התבנית, אז “מאפס” זה לא אחר צהריים כיפי. תעשו גיבויים. לא בכדי צ’קליסט האבטחה לוורדפרס מתחיל בהם.


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

תגובות

התגובות נשמרות ב-GitHub Discussions (דרך giscus), אז כדי להצטרף לשיחה צריך חשבון GitHub.

אצייץ לך כשיעלה פוסט חדש

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

מעדיפים קורא RSS? יש פיד RSS.

© Alex Kovalev. כל הזכויות שמורות. · מדיניות פרטיות