הגדרת גיבוי MySQL באמצעות mysqldump

למה mysqldump מפסיק להציל בבסיס נתונים שגדל

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

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

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

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

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

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

מה נותן גיבוי MySQL מנוהל

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

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

זמן שחזור צפוי

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

סוג כשל שהוסר: כשלי העתקה שקטים

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

mysqldump, עותק פיזי או רפליקה: במה לבחור

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

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

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

מגבלות הדאמפ הלוגי בטבלאות גדולות

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

מתי שיטה אחת אינה מספיקה

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

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

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

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

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

בדיקת שחזור על עותק בסביבת בדיקה

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

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

מה נשאר לצוות שלכם אחרי ההטמעה

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

סקריפטים ותצורות העתקה

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

תיעוד ותקנוני שחזור

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

מהפרקטיקה: שחזור בסיס נתונים של חנות אינטרנטית

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

איך זה היה: עותק קיים, השחזור לא נבדק

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

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

איך זה נהיה: שחזור לפי לוח זמנים ועל סביבת בדיקה

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

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

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

mysqldump כבר מוגדר, אבל השחזור לא נבדק?

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

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

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

הדאמפ עצמו נלקח במצב עקבי: --single-transaction עבור InnoDB והדגלים --routines --triggers --events, אחרת השחזור עובר פורמלית אבל חלק מהלוגיקה בסכמה חסרה.

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

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

ספקות טכניים נפוצים לגבי גיבוי MySQL

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

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

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

איך לאחסן ולבצע רוטציה של עותקים?

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

אפשר לקחת עותק מרפליקה?

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

מה לעשות עם טבלאות גדולות?

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

נדון במשימה שלכם בתחום הגיבוי

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

מה כדאי להכין לדיון במשימה:

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

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