ניהול MySQL/MariaDB: התקנה, תצורה, אופטימיזציה

מה נשבר בניהול MySQL עם גידול העומס

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

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

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

את יומן השאילתות האיטיות ופרופיל העומס מנתחים בכלים כמו pt-query-digest מתוך ערכת Percona — רואים איזו שאילתה מחזיקה את הנעילה ומי מואט בגללה.

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

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

מה משתנה לאחר כיול: זמן תגובה, זמן השבתה, עמידות לתקלות

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

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

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

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

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

מצבי עבודה של המסד: איזו אפשרות מתאימה למשימה שלכם

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

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

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

כיצד מתבצעת ההטמעה: מביקורת ועד מסירה

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

1. ביקורת מסד. מנתחים פרמטרים של השרת, מבנה טבלאות, קצב גידול הנתונים, סטטיסטיקת שאילתות איטיות והיסטוריית נעילות. בפלט — רשימת צווארי בקבוק לפי עדיפות: מה מדרדר כעת, ומה יתגלה עם הגידול.
2. סכימת פריסה. מגדירים טופולוגיה: צומת אחת או ראשי עם רפליקות, כיצד מתחלקת הקריאה, היכן נשמרים העתקים. את הסכימה מתאמים לפני ההתקנה — לשנות אותה אחר כך יקר יותר מאשר לפצל עומס מיד.
3. כיול לפרופיל העומס. מחשבים מאגרים ומטמונים, מגבלות חיבורים, מצב רישום יומן וכתיבה לדיסק עבור פרופיל ספציפי: טרנזקציות קצרות, שאילתות אנליטיות ארוכות או זרימה מעורבת.
4. בדיקה תחת עומס. מריצים תרחיש קרוב לפרודקשן: שיאי כתיבה, שאילתות דיווח, חיבורים בו-זמניים. מסתכלים לא על ממוצעים אלא על זנבות — לפיהם רואים מתי המשתמש מבחין בהאטה.
5. בדיקת שחזור. פורסים העתק על צומת נפרד ומודדים את הזמן עד למצב עבודה תוך השלמה לנקודת הכשל. כל עוד השחזור לא תורגל באופן חי, הגיבוי נחשב לא מאומת.
6. נוהל ומסירה. קובעים ניטור מדדי מפתח, ספי התראות, סדר עבודות מתוכננות ועדכון תצורות, ומבצעים הדרכת צוות בתרחישים אמיתיים.

תוצרי ההטמעה: תצורות, סכימות, נהלים

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

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

• קובצי תצורה — הקונפיגורציה הראשית של השרת תחת בקרת גרסאות, עם פרופילים לפי תפקיד הצומת (מאסטר, רפליקה, צומת לקריאה בלבד) והערות מדוע הפרמטר הוגדר דווקא כך.
• סכימת פריסה — טופולוגיית הצמתים וזרימות הנתונים: לאן האפליקציה כותבת, כיצד מתפשטת הרפליקציה, היכן נקודת ההפרדה בין קריאה לכתיבה, מה יקרה עם אובדן כל צומת.
• מדיניות גישה ותפקידים — מטריצת הרשאות: חשבונות שירות עם סט ההרשאות המינימלי הנדרש, נפרדים לרפליקציה ולניטור, חשבון מפעיל לקריאה בלבד; סודות נשמרים במנהל סיסמאות ולא בקונפיגים.
• נוהל גיבוי — מה ובאיזו תדירות נלקח (העתק מלא בתוספת יומני שינויים), תקופת שמירה, רוטציה, בדיקת שחזור חובה בעמדה נפרדת, ולא «יש גיבוי, אז זה עובד».
• הוראות שחזור — סדר שלב-אחר-שלב: עצירת כתיבה מצד האפליקציה, פריסת העתק, השלמה לנקודה הרצויה לפי יומנים, בדיקת שלמות והשוואת טבלאות מפתח.
• פעולות שגרה — החלפת צומת ראשי, חיבור רפליקה חדשה, שינוי מבנה טבלאות במסד חי, הידרדרות עקב עומס: מה לעשות ובאיזה סדר.
• מפת נראות — אילו מדדים נאספים, אילו ספים נחשבים מדאיגים, למי ולאן מגיעה התראה.

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

מקרה בוחן בניהול MySQL: ייצבנו מסד של חנות מקוונת

הפרויקט — חנות מקוונת עם מבצעים עונתיים: בשיא, עגלת הקניות והשלמת ההזמנה החלו להמתין למסד. על MySQL רצו גם הוויטרינה, גם ממשק הניהול וגם דוחות השיווק. שיעור השאילתות האיטיות עד סוף היום עמד על 12-14%, אתחולי חירום קרו 5-6 פעמים בשבוע, והשחזור לאחר נפילה ארך כ-40 דקות.

מה מצאנו

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

מה שינינו

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

תוצאה לפני ואחרי

שיעור השאילתות האיטיות — מ-12-14% ל-0.3%. זמן השחזור — מ-40 דקות ל-4. אתחולי חירום — חמישה-שישה בשבוע במקום אפס ברבעון האחרון. עומס השיא של המבצע עמד בפי שניים מהשיא הקודם בלי גידול בזמן התגובה של הוויטרינה.

מסד עצמאי או מנוהל: מה לבחור לפי הפרופיל שלכם

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

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

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

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

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

שאלות שמהנדסים שואלים לפני תחילת העבודה

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

תיקחו על עצמכם מסד שכבר פרוס?

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

כיצד לוודא שהגיבוי אכן ישוחזר?

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

מי אחראי לעדכוני אבטחה?

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

מה כוללת העברת הידע?

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

נדון במשימה: ננתח את התצורה ונחזור עם תוכנית

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

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

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