מה זו השגיאה Error establishing database connection, ומה היא מספרת על האתר שלכם?
במקום האתר מופיעה שורה אחת באנגלית: Error establishing database connection. אין תפריט, אין ניהול, ואין שום רמז נוסף. זו אחת ההודעות שהכי מפחידות בעלי אתרים, כי היא נשמעת כאילו כל התוכן נעלם. בפועל היא אומרת משהו צר בהרבה: הקוד של וורדפרס ניסה לדבר עם מסד הנתונים ולא קיבל מענה. זה נתק בין שני רכיבים, לא אובדן של תוכן. ההבחנה הזאת חשובה, כי היא קובעת מה עושים קודם. מי שמפרש את ההודעה כאובדן מידע ממהר לשחזר גיבוי, וזו בדיוק הפעולה שעלולה למחוק ימים של עבודה שלא היה צריך למחוק. במאמר הזה אני מפרט מה ההודעה באמת אומרת, שלוש שכבות שבודקים לפי סדר, ומה בודקים לפני שנוגעים בגיבוי.
תוכן העניינים 7 פרקים
מה ההודעה אומרת בפועל
אתר וורדפרס מורכב משני חלקים שיושבים בנפרד. הקבצים, שהם הקוד והתבנית והתוספים, ומסד הנתונים, שבו יושבים הפוסטים, הדפים, ההגדרות והמשתמשים. בכל טעינה של דף הקוד ניגש למסד הנתונים ושואל אותו שאלות.
ההודעה מופיעה כשהשיחה הזאת לא מתחילה. שלוש סיבות אפשריות, וכולן על אותו מישור: הקוד פונה לכתובת או לשם משתמש שאינם נכונים, שירות מסד הנתונים בשרת אינו פועל, או שהשרת עמוס ודוחה חיבורים נוספים.
שימו לב למה שלא נכלל ברשימה. ההודעה אינה אומרת שהמידע נמחק, ואינה אומרת שהאתר נפרץ. היא אומרת שאין חיבור. זו הסיבה שתיקון שגיאת Error establishing database connection מתחיל אצלי תמיד בבדיקת החיבור ולא בשחזור.
התוכן שלכם ברוב המקרים במקומו
אני מדגיש את זה כי הפאניקה היא הגורם שהכי הרבה פעמים הופך תקלה של חצי שעה לנזק אמיתי. ברוב המקרים שאני מטפל בהם, כל הנתונים נמצאים, והם חוזרים ברגע שהחיבור מתוקן.
יש מיעוט מקרים שבהם באמת יש נזק לטבלאות, בדרך כלל אחרי נפילת שרת פתאומית או אחרי שדיסק התמלא. גם אז מדובר בדרך כלל בטבלה אחת שדורשת תיקון, ולא בכל התוכן. וורדפרס כולל מנגנון תיקון פנימי, ובמקרים מורכבים יותר משתמשים בכלי שורת פקודה כדי לתקן טבלה ספציפית.
הסימן שמבדיל בין השניים פשוט: כשמדובר בבעיית חיבור, כל הדפים מציגים את אותה הודעה. כשמדובר בטבלה פגומה, לפעמים חלק מהאתר עובד וחלק לא, או שהניהול נטען חלקית. שווה לשים לב לזה לפני שמחליטים מה לעשות.
עוד סימן שעוזר: האם ההודעה מופיעה מיד או אחרי המתנה ארוכה. תשובה מיידית מצביעה בדרך כלל על פרטי חיבור שגויים, כי הדחייה מהירה. המתנה של כמה שניות ואז הודעה מצביעה על שרת שמנסה להתחבר ולא מצליח, כלומר עומס או שירות שאינו פועל. זה הפרש קטן שמכוון היטב.
שלוש שכבות, לפי סדר
אני עובד לפי סדר קבוע, מהזול לכיוון היקר, ומהבטוח לכיוון המסוכן.
שכבה ראשונה, פרטי החיבור. בקובץ ההגדרות של וורדפרס יושבים שם מסד הנתונים, שם המשתמש, הסיסמה וכתובת השרת. ארבעת הפרטים האלה חייבים להתאים למה שקיים בפאנל האחסון. הם משתנים בדרך כלל אחרי מעבר שרת, אחרי שכפול אתר לסביבת בדיקה, או אחרי שמישהו שינה סיסמה בפאנל ולא עדכן בקובץ.
שכבה שנייה, מצב השירות בשרת. יכול להיות שהכול מוגדר נכון ופשוט השירות אינו פועל, למשל אחרי אתחול או אחרי תקלה אצל ספק האחסון. במצב כזה גם אתרים אחרים על אותו שרת יציגו התנהגות דומה, וזו שאלה אחת לתמיכה של האחסון.
שכבה שלישית, מכסות ומשאבים. חשבונות אחסון מוגבלים במספר חיבורים בו זמנית, בנפח דיסק ובזיכרון. כשהמכסה נגמרת, חיבורים חדשים נדחים, וההתנהגות נראית אקראית: האתר עולה, נופל, ועולה שוב. דיסק מלא הוא חשוד קבוע כאן, ולעיתים קרובות הוא מתמלא מגיבויים ישנים שנשמרים על אותו שרת.
לשכבה השלישית שווה להוסיף נקודה מעשית: הרבה אתרים מגיעים למכסה לא בגלל תנועה אמיתית אלא בגלל סריקות. בוט שסורק עשרות דפים בשנייה מייצר עומס שנראה בדיוק כמו הצלחה שיווקית, וההבדל מתגלה רק בלוגים. אם התקלה חוזרת בשעות מסוימות, זה החשד הראשון שאני בודק.
מה בודקים לפני שנוגעים בגיבוי
שחזור גיבוי הוא כלי טוב במקום הנכון ובסדר הנכון. לפניו, ארבע בדיקות:
- האם ההודעה מופיעה גם בכתובת הניהול. אם שם מופיעה הודעה אחרת, זה מכוון לטבלה פגומה ולא לנתק חיבור.
- האם משהו השתנה: מעבר אחסון, שכפול, שינוי סיסמה, עדכון גדול או ייבוא נתונים.
- מה מצב הדיסק והמכסות בפאנל האחסון. זו בדיקה של דקה שפותרת חלק ניכר מהמקרים.
- האם יש אתרים נוספים על אותו חשבון, ומה מצבם.
ואם בכל זאת מגיעים לשחזור, שני כללים. ראשית, מגבים את המצב הנוכחי לפני השחזור, גם אם הוא נראה שבור, כי הוא מכיל את התוכן העדכני ביותר. שנית, בודקים מה תאריך הגיבוי ומה נוצר באתר אחרי אותו תאריך. הזמנות בחנות ותגובות הן הדברים שהכי הרבה פעמים אובדים בשחזור פזיז.
ואם האתר מסחרי, שווה להעלות דף המתנה זמני עוד לפני שמתחילים לתקן. עמוד סטטי קצר שמסביר שיש תקלה ונותן טלפון להזמנות שומר לכם לקוחות בשעה הקריטית, והוא לוקח חמש דקות להעלות. זה גם מוריד מכם את הלחץ לתקן מהר על חשבון תיקון נכון.
רשימת בדיקה מהירה
| מה רואים | מקור סביר | מה עושים |
|---|---|---|
| ההודעה בכל הדפים, כולל בניהול | פרטי חיבור או שירות שאינו פועל | השוואת פרטים מול פאנל האחסון |
| הופיע מיד אחרי מעבר שרת | כתובת שרת או שם משתמש | עדכון קובץ ההגדרות |
| מופיע ונעלם לסירוגין | מכסת חיבורים או עומס | בדיקת משאבים, איתור מה מעמיס |
| הניהול מציג הודעה אחרת | טבלה פגומה | תיקון טבלה ממוקד |
| גם אתרים אחרים באותו חשבון נפלו | תקלה בצד האחסון | פנייה לתמיכה של הספק |
| קדם לזה ייבוא או תוסף כבד | עומס על מסד הנתונים | צמצום, אינדוקס, ניקוי טבלאות |
הטבלה הזאת היא גם מה שאני מבקש מלקוח שכותב לי. עם שתי שורות מידע אפשר להגיע לאבחון תוך דקות, ובלעדיהן מתחילים מאפס.
עוד דבר שכדאי לאסוף לפני שפונים לעזרה: מתי בדיוק זה התחיל, האם מישהו נכנס לפאנל האחסון באותו יום, והאם יש התראה כלשהי מספק האחסון. שלושת הפרטים האלה מקצרים אבחון בצורה משמעותית, והם זמינים לכם ולא לי.
למה זה חוזר, ואיך עוצרים
כשהשגיאה מופיעה פעם אחת ונעלמת, ואז חוזרת אחרי שבוע, כמעט תמיד מדובר בעומס ולא בהגדרה שגויה. הגדרה שגויה שוברת את האתר לצמיתות עד שמתקנים אותה. עומס מתנהג בגלים.
הגורמים החוזרים שאני פוגש: אתר שגדל מעבר לחבילת האחסון שלו, תוסף שמריץ שאילתות כבדות בכל טעינה, טבלאות שהתנפחו לאורך שנים, ובוטים שסורקים את האתר בקצב גבוה. הטיפול משתנה לפי הגורם, וזו הסיבה שאבחון קודם לפעולה.
ההרגלים שמונעים חזרה: גיבוי יומי ששמור מחוץ לשרת, ניטור זמינות שמודיע ברגע שהאתר נופל, ניקוי תקופתי של טבלאות ושל גרסאות ישנות, ובדיקה של מצב הדיסק פעם בחודש. כל אלה נכללים בתחזוקת אתר וורדפרס, ₪250-₪950 חודשי לפני מע״מ, ולמי שמפעיל אתר מסחרי זה בדרך כלל זול יותר מתקלה אחת בשנה.
כמה עולה תיקון
תיקון השגיאה אצלי מתומחר מ-₪350 לתקלה, לפני מע״מ, והטיפול בפועל נמשך בדרך כלל בין שלושים לתשעים דקות. זה כולל אבחון בשלוש השכבות, תיקון, ובמקרה הצורך גם תיקון של טבלאות פגומות.
מה שמאריך: כשכבר בוצעו ניסיונות שחזור לא מתועדים, כשאין גישה לפאנל האחסון, וכשמסתבר שהמקור הוא עומס מתמשך שדורש טיפול רחב יותר ולא תיקון נקודתי. במקרים כאלה עדיף לטפל בשורש, אחרת אותה שיחה תחזור בעוד חודש.
מה שכן שווה להגיד על העלות ביחס לנזק: אתר שלא זמין אינו רק מפסיד פניות באותה שעה, הוא גם משאיר רושם אצל מי שכבר הכיר אתכם. בעסק שמקבל פניות דרך האתר, שעתיים של השבתה עולות בדרך כלל יותר מהתיקון עצמו, ולכן אני ממליץ לטפל מהר ולא לחכות ליום שאחרי.
אם האתר שלכם למטה עכשיו, שלחו לי צילום מסך של ההודעה ותגידו מה קרה לפני, ואגיד לכם לאיזו שכבה זה נראה שייך. אם זה מתגלה כתקלה מסוג אחר, כמו מסך לבן או שגיאת PHP, זה נכנס תחת פתרון תקלות WordPress, ₪350-₪1,500 לתקלה · חבילת חירום ₪2,500, לפני מע״מ, ואני אומר את זה מראש ולא אחרי. הכי מהיר דרך WhatsApp, או בטלפון 054-238-3789. דברו איתי בוואטסאפ ←
