הנה סיפור נאה – הגיע אלי בעל עסק לפרויקט הצלה – האתר שלו נפל ולא הצליח לקום ומי שניסה להכנס אליו קיבל שגיאת מסד נתונים של וורדפרס.
לסיפור על תיקון התקלה יש ערך ואני כותב אותו גם בשביל עצמי (כדי שאזכר בפעם הבאה) וגם אולי למי שירצה ללמוד איך מבצעים אנליזה וטיפול לבעיה לא מאוד טריוויאלית.
בדיקת האתר
האתר היה על שרת יעודי לא מנוהל. למרבה הצער, בונה האתר שהעביר אותו לשם לא היה מיומן מספיק בסיסטם ועשה שם כמה שגיאות. האתר החל להיות מאוד איטי בתקופה האחרונה ולאחר כמה ניסיונות פתרון של בונה האתרים הוא הפסיק לעבוד ובונה האתר התפוגג כמובן ברגע שהיה קשה. הלקוח, בעל עסק שנשען משמעותית על המכירות באתר, הגיע אלי במצב בעייתי ולמרבה המזל היה לי פנאי לסייע.
האתר כלל לא עבד כשניגשתי אליו וסבל ממסך לבן ואיכותי. פתרון בעיית המסך הלבן הוא קל יחסית (לחיצה על הקישור מציגה איך פותרים אותו). אבל מייד כשבעיית המסך הלבן נפתרה, גיליתי את שגיאת Cannot connect to Database.
כאשר התקלה הזו מופיעה, הדבר הראשון שאנו בודקים זה מה קרה למסד הנתונים. במקרה הזה השרת המנוהל הפעיל את MariaDB שזהה ל-MySQL. הדבר הראשון שעשיתי זה להתחבר למסד הנתונים באמצעות פקודת mysql כדי לרחרח מה קורה שם. הקלדתי mysql:
מה שקיבלתי זה שגיאה איכותית:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
השגיאה הזו אומרת בעצם שהשירות לא באוויר. אם אתם מקבלים אותה, כדאי לבצע ריסטארט למסד הנתונים באמצעות: sudo service mysql restart.
למרבה הצער קיבלתי שגיאה. טוב, זה מסביר למה הוורדפרס לא הצליח להתחבר למסד הנתונים. כי הוא לא למעלה.
השגיאה הזו היא שגיאה כללית, אבל כן יש בה מידע איך לחפש בלוגים. חלק מהאנשים (גם אני כמובן) יפנו לעולם הגדול של גוגל ויתחילו לחפש לפי פלט השגיאה הזו. שזה דבר לא טוב, כי יש המון שגיאות שיכולות לגרום לשגיאה כללית. הדרך היחידה היא לחפש בלוגים ולנסות להבין מה קרה פה.
איך קוראים את הלוגים? כמה נוח שיש בפלט השגיאה עצמה את הדרך:
systemctl status mysql.service -l
קיבלתי המון לוגים. הלוגים האלו עלולים לבלבל כי יש בהם המון מידע וגם המון שגיאות. בדרך כלל מה שמעניין אותנו זו השגיאה הראשונה. כי מה שקורה הוא שיש שגיאה ואז היא גוררת המון שגיאות אחרות. במקרה הזה השגיאה הראשונה היתה:
Failed to start LSB: start and stop MariaDB.
לא היה יותר מדי מידע אבל זה היה מספיק כדי להבין שאין פה איזו בעית סיסטם, מישהו אחר שמפריע/רוכב על הפורט או משהו דומה. אם יש שגיאה כזו – השלב הבא הוא לבדוק את הלוגים של השירות שנפל. במקרה הזה MariaDB. את הלוגים של מסד הנתונים אנו רואים ב:
cat /var/log/mariadb/mariadb.log
איך ידעתי פשוט חיפשתי בגוגל איפה הלוגים נמצאים ואיפה אפשר לראות אותם.
גם פה – ערימות של מידע והמון שגיאות. הלכתי לשגיאה הראשונה ושם היה כתוב:
2020-06-11 3:40:18 0 [ERROR] mysqld: Can't lock aria control file '/var/lib/mysql/aria_log_control' for exclusive use, error: 11. Will retry for 30 seconds
בדרך כלל כשיש בעיות עם lock file, זה אומר שיש לנו בעיית מקום. גם גיגול של השגיאה הזו מראה שזה החשוד המיידי.
בעיית המקום
נורא קל לשכוח, וכשאני אומר קל לשכוח אני מתכוון לזה שאני שוכח – ששרתים הם בעצם מחשבים לכל דבר. גם מחשבים וירטואלים הם מחשבים שמוקצים להם משאבים ובכללם גם משאבי מקום. ומקום בהארדיסק, יודע כל מי שגדל בשנות התשעים המאוחרות, יכול להגמר.
איך בודקים את זה? עם פקודת df -H וזה מה שקיבלתי:
כשאין מקום בהארדיסק, קבצים לא יכולים להיווצר – במקרה הזה קובץ ה-lock של מסד הנתונים. ואז מסד הנתונים לא יכול להתרומם. השלב הבא הוא לנסות להבין איך לעזאזל מערכת של וורדפרס אכלה 85 ג׳יגהביט. בשביל זה אני צריך פקודה אחרת: du.
הפקודה מראה את כל התיקיות והקבצים שיש ב */ – כלומר ב-root.
sudo du -shxc /*
וכך בעצם אפשר לבדוק מה קורה ב-var עם הפקודה
sudo du -shxc /var/*
ולראות את התיקיות העמוסות ולהכנס לכל אחת מהן. כך ראיתי שרוב העומס נמצא בתיקית www. בדיקה מהירה שם עם
sudo du -shxc /var/www/*
הראתה לי שהבעיה היא בכלל ב-vhost העמוסה. וכך בסוף הבנתי שכל העומס מתרכז בקובץ הלוגים:
/var/www/vhosts/THE-SITE.COM/logs
במקרה הזה בחרתי קובץ לוג שאני לא צריך, העתקתי אותו אלי עם scp ומחקתי אותו. ובום. 5 ג׳יגה השתחררו ואז sudo service mysql star הצליח. הבעיה נפתרה.
ראשית בעל העסק היה מאושר מכך שהאתר שלו חזר לפעולה. פתאום כל מיני דברים הסתדרו לו – האיטיות של האתר, הכשלון בלהעלות קבצים ולעשות פעולות – דברים שבונה האתר שלו ניסה לפתור באמצעים משונים ולא באמצעות בדיקה מקיפה. הקש ששבר את גב השרת הוא ריסטארט לשרת ואז מסד הנתונים פשוט לא עלה בגלל המקום.
עכשיו בעצם העבודה האמיתית מתחילה – להבין למה בדיוק הלוגים הצטברו בלי שיש תהליך שמוחק חלק מהם ואם יש בעיות אחרות שנגרמו מהסיפור הזה. קישרתי את בעל העסק לבונת אתרים שאני סומך עליה (רויטל סלומון שהיא בונת אתרים מצוינת) והמשכתי להתנדנד לי בערסל.
2 תגובות
האמת, שבשביל לוג מלא של סרביס, עדיף
journalctl -u mysql.service
בסטטוס תקבל רק את השורות האחרונות.
שרת שלא הוגדר כיאות – צריך להגדיר נכון את logrotate בכרון לריצה יומית. (לא קשור לניהול שרת, קשור ללינוקס).
בונה שרתים שלא מתמצא בלינוקס ככל הנראה לא ידע להפעיל את זה. (תעביר את החלק הראשון בלי החלק המעליב לגברת ששלחת אותו אליה, אולי היא לא יודעת את זה).