גיבוי MariaDB: היכן נשברת העתקה חמה
העתקה חמה נלקחת בלי לעצור את השירות — והיא נשברת לא ברגע ההעתקה, אלא ברגע השחזור. תרחיש אופייני: הכלי שמבצע את ההעתקה, לשם עקביות, תופס לזמן קצר נעילת כתיבה על טבלאות.
בבסיס נתונים בגודל עשרות גיגה-בייט מדובר בדקות שבהן האפליקציה לא כותבת: תור החיבורים גדל, וחלק מהשאילתות נופלות בגלל timeout.
ברגע שמסירים את הנעילה כדי לא להפיל את השירות, ההעתקה הופכת לא-עקבית. גיבוי חם MariaDB במצב של טרנזקציה אחת (--single-transaction) נותן חתך עקבי רק לטבלאות טרנזקציוניות, ובאותה סכימה שכנות זו לזו גם טבלאות ללא טרנזקציות — הן נקראות ברגע אחר.
בהעתקה מופיעות הזמנות בלי שורות ומפתחות זרים לתוך הריק: השחזור עובר פורמלית, אבל הנתונים לא מסתדרים.
המלכודת השנייה — ההעתקה לא זוכרת את הנקודה שבה היא נלקחה. לשחזור לנקודת זמן שרירותית דרושה עמדה עקבית ביומן השינויים; בלעדיה שחזור האירועים מוביל את בסיס הנתונים למקום הלא נכון. העתקה ארוכה מנפחת בדרך אגב גם את היומן: המקום בדיסק נגמר לפני שההעתקה מוכנה — והשרת שבשימוש נופל.
והעיקר: העתקה שמעולם לא שוחזרה אינה גיבוי, אלא ארכיון באיכות לא ידועה. בדיקת שלמות של גיבוי נעשית רק בהרצה מלאה של שחזור על סטנד נפרד: השוואת סכומי ביקורת של טבלאות מפתח, התאמת שורות וקשרים חיצוניים, יומן שגיאות נקי לאחר העלייה. אנחנו מפרקים איך זה נסגר — מבחירת מצב ההעתקה ועד נוהל בדיקות קבועות.
מה נותן גיבוי חם ללא עצירת השירות
חלון אי-הזמינות מתכווץ לשניות
ההעתקה נלקחת משרת פעיל: התהליך קורא קבצי נתונים ויומן טרנזקציות בלי לחסום כתיבה — הזמנות, תשלומים ודוחות ממשיכים כרגיל. נעילה נדרשת רק לתיעוד העמדה ביומן, כלומר לשברירי שנייה, ולא לשעות של חלון לילה.
וכך גיבוי ללא עצירת בסיס הנתונים מפסיק להיות אירוע בלוח השנה: אפשר לתזמן אותו בכל שעה, ולא רק בחלון שבו כולם ישנים.
שחזור בעשרות דקות
לא dump נפרס, אלא העתקה פיזית: הקבצים חוזרים למקומם, והיומן מגלגל את השינויים עד לנקודת הזמן הרצויה. המדד העיקרי כאן הוא הזמן עד להעלאת בסיס הנתונים למצב עבודה, והוא יורד משעות לעשרות דקות, משום שאין צורך להריץ מחדש את כל ההכנסות. חזרה למצב שלפני ריליס כושל הופכת לפעולה שגרתית ולא למשמרת לילה בחירום.
ההעתקה עקבית לרגע ההעתקה
המשימה אינה רק לשמור טבלאות, אלא לקבל חתך לא-סותר: הנתונים והיומן מתאימים לאותה נקודה. בלעדי זה השחזור מניב מפתחות זרים שבורים ופערים בין טבלאות שאחר כך מחפשים ביד. העקביות מוגדרת ברמת הנוהל, ולא נבדקת בעיניים של תורן — ולכן ההעתקה ראויה לשימוש מיד.
שליטה בהעתקות בלי בדיקות ידניות
תזמון, רוטציה ובדיקת שחזוריות מתבצעים אוטומטית: ההעתקה נפרסת בקביעות בסביבה מבודדת ומושווית למצב הצפוי. זה מסיר סוג כשל של "יש העתקה, אבל היא לא שמישה", שצף בדרך כלל ברגע הכי לא מתאים.
בנוסף, עלויות האחסון מפסיקות לגדול בלי בקרה — סטים ישנים מפונים לפי מדיניות, ונקודות שחזור טריות נשארות זמינות.
השוואת גישות: dump לוגי, snapshot של volume, רפליקה
שלוש גישות סוגרות משימות שונות, והבחירה נקבעת לא לפי הרגל של הצוות, אלא לפי נפח בסיס הנתונים, החלון המותר ונקודת השחזור הנדרשת. dump לוגי של בסיס נתונים נקרא בעין, עובר בין גרסאות ופלטפורמות, אבל בנפחים גדולים הוא נמתח לשעות ומחמם את הדיסק באופן מורגש.
snapshot של volume אחסון נלקח בשניות, אך בלי השהיית כתיבה עקבית מראש הוא נותן סט דפים לא-עקבי, שלעתים פשוט לא עולה.
רפליקה לגיבוי מעבירה את העומס מבסיס הנתונים הראשי: ההעתקה נלקחת מהצומת המפגר, והשרת הפרודקשן לא מרגיש בכך. גיבוי אינקרמנטלי משלים כל אחת מהסכמות — סט מלא יומי בגודל עשרות גיגה-בייט לא נכנס לא לחלון ולא לאחסון.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| dump לוגי של בסיס נתונים | בסיסי נתונים קטנים ובינוניים, מיגרציות, ייצוא סלקטיבי של טבלאות בודדות | הזמן גדל ליניארית עם הנפח; עומס על הדיסק והמעבד; השחזור ארוך באותה מידה |
| snapshot של volume אחסון | בסיסי נתונים גדולים על volume ייעודי, חלון צר, צריך image מלא בדקות | דרושה נקודה עקבית (נעילת כתיבה קצרה); ה-volume כבול לשרת ולאחסון |
| רפליקה לגיבוי | פרודקשן בעומס גבוה, כשאסור להאט את בסיס הנתונים הראשי | דרושים שרת ומקום נפרדים; הפיגור של הרפליקה נשלט בנפרד, אחרת ההעתקה תתברר כמיושנת |
בפועל משלבים בין הסכמות: סט מלא פעם בשבוע, אינקרמנט יומי, וכתיבה רציפה של היומן הבינארי נותנת שחזור מדויק לנקודת זמן — חזרה לא להעתקת הלילה, אלא לדקה שלפני התקלה. איזה שילוב יתאים לכם תלוי בנפח ובחלון ההשבתה המותר — וזה מה שאנחנו מפרקים בהתחלה.
סדר היישום: מהאאודיט ועד למסירה לתפעול
מסלול היישום של גיבוי MariaDB זהה לשרת בודד ולסכמה עם רפליקות: קודם מתעדים מה צריך להשתחזר ובאיזו תדירות, אחר כך מגדירים את לקיחת ההעתקות והאחסון, ורק לאחר שחזור תרגול מוצלח מעבירים את המערכת לתפעול.
- אאודיט של הגיבוי. מפרקים את המשימות הקיימות ואת התוצאה בפועל, את קצב הגדילה של בסיס הנתונים, את מרווח המקום, ואת הרשאות הקריאה מהרפליקות. מתעדים סיכונים: העתקה מהמאסטר מפריעה לכתיבה, השלמות לא נבדקת, העתקה יחידה יושבת על אותו volume כמו הנתונים.
- סכמת גיבוי של בסיס הנתונים. בוחרים צירוף: snapshot מלא עם mariabackup, אינקרמנטים לפי דפים שהשתנו, ויומנים בינאריים לשחזור לנקודת זמן. מתאמים יעדי נקודת שחזור וזמן שחזור, עומק אחסון וייצוא מחוץ לשרת.
- הגדרת תזמון ההעתקות. פורסים את המשימות לחלונות עומס נמוך ולוקחים העתקות מהרפליקה, כדי לא להתחרות עם המאסטר על פעולות דיסק. מגדירים רוטציה, בקרת קוד החזרה של המשימה והתראה בעת כשל.
- שחזור ניסוי. פורסים העתקות על סטנד נפרד ומודדים את זמן השחזור האמיתי — של בסיסי הנתונים בשלמותם ושל טבלה בודדת. משווים סכומי ביקורת ומריצים בדיקות על הנתונים המשוחזרים: שגיאות בסכימה צפות כאן, ולא בזמן תקלה.
- מסירה לתפעול. מוסרים נהלים: מה ומתי מגובים, היכן נשמר, מי ואיך משחזר, ואיך קוראים התראות ניטור. מבצעים שחזור תרגול בכוחות המשמרת התורנית שלכם ונשארים בתמיכה לפי לוח זמנים.
המערך בסיום: קונפיגורציות, סכמות, נהלים
המערך נבנה כך שהמשמרת התורנית תפעל לפיו בלעדינו: קונפיגורציות שכבר עובדות על סטנדים ובמערכת הפרודקשן, בתוספת מסמכים שמסבירים כל החלטה שהתקבלה. להלן מה שנשאר בדיוק אצל הצוות שלכם לאחר המסירה.
- קונפיגורציות גיבוי עובדות לפי כל בסיס נתונים: תזמון, סט אובייקטים, מצב לקיחת העתקות ללא עצירת כתיבה, פרמטרים של דחיסה והצפנה — אותו סט עובר גם על הסטנדים וגם על סביבת הפרודקשן.
- סכמת מערך הגיבוי: אילו צמתים משתתפים, היכן מאוחסנות ההעתקות, איך מופרדים האתר הראשי והאתר החיצוני, ומה קורה בכשל של אחד מאמצעי האחסון.
- מדיניות אחסון העתקות: עומק לפי סוגים — יומיים, שבועיים, חודשיים, כללי הארכה ומחיקה, וצמידה לחלונות רגולציה, כדי שנפח המאגר לא יגדל בלי בקרה.
- נוהל שחזור בסיס הנתונים: סדר שלב-אחר-שלב עם נקודות שחזור מלא וחלקי, זמן חזרה צפוי לפעילות, והשוואת נתונים מחייבת לאחר העלייה.
- תפקידי גישה להעתקות ויומן פעולות: מי לוקח העתקה, מי קורא, מי משחזר; הגישה לנתוני פרודקשן מופרדת למערך נפרד.
- תיעוד הגיבוי: תיאורים, דיאגרמות ורשימות ביקורת יושבים במאגר הקוד לצד הקונפיגורציות ומנוהלים בגרסאות יחד איתן.
- יומני בדיקות השחזור: תאריכים, מה הועלה, פערים, זמן בפועל — הוכחה שההעתקה חיה ולא סתם קובץ באחסון.
מקרה בוחן: שחזור בסיס נתונים לאחר כשל צומת
מה היה לפני השינויים
אצל הלקוח — חנות אינטרנט בעומס כתיבה גבוה אל MariaDB. dump לילי נלקח מאותו צומת ששירת את העומס, נשמר על מחיצה שכנה, ומעולם לא שוחזר. בדיקת שמישות עברה בערך מחצית מההעתקות: חלקן נקטעו בייצוא, חלקן לא התאימו בסכומי ביקורת — וגילו על כך ברגע התקלה.
כשהצומת כשל, שחזרו להעתקה של הלילה הקודם: אבדו בערך יממה של הזמנות ותיקוני קטלוג, וההעלאה ארכה יותר משש שעות.
מה שינו ומה נהיה
ההעתקות עברו לאחסון נפרד והפכו חמות — השירות לא נעצר בזמן ההעתקה. העתקה מלאה פעם בשבוע, חתכים אינקרמנטליים בתדירות גבוהה יותר, ובנוסף יומן שינויים רציף: חזרה אפשרית לכל נקודה בתוך היממה.
כל העתקה נפרסת אוטומטית על סטנד נפרד ומושווית לפי סכומי ביקורת של טבלאות, ולכן השמישות מאושרת בעובדת השחזור, ולא בסימון ביומן המשימה. כל הארכיונים עוברים בדיקה — כאלה שאינם שמישים נפסלים ונלקחים מחדש, ולא נכנסים להיסטוריה.
זמן השחזור הצטמצם משש שעות לעשרות דקות: עולה ההעתקה המלאה האחרונה, ומעליה מגלגלים את היומן. כשל צומת הפסיק להיות סוג של תקלה עם אובדן נתונים — הפער מנקודת השחזור המאושרת האחרונה נמדד בדקות.
מערך הגיבוי הפך לעמיד בפני כשלים: יציאה מכלל פעולה של אחסון או צומת אינה מפסיקה את לקיחת ההעתקות, והשלמות על הסטנד המשוחזר נבדקת לפני מעבר תעבורת הפרודקשן.
במה שונה MariaDB backup מרפליקציה?
רפליקה והעתקת גיבוי פותרות משימות שונות. רפליקציה היא זרם שינויים רציף: היא מפחיתה עומס קריאה ומאפשרת לעבור לצומת אחר תוך דקות. אבל היא לא שומרת היסטוריה — כל שינוי, כולל שגוי, מיושם על הרפליקה כמעט מיידית.
DELETE בלי תנאי או UPDATE עם WHERE שנשכח יתפשטו לכל הרפליקות תוך שניות. רפליקה מושהית בפיגור של כמה שעות נותנת חלון הצלה, אבל רק אם הבחינו בשגיאה בתוך החלון הזה, והיא לא מגנה מפני השחתה שהתחילה קודם.
שחזור לנקודת זמן אפשרי רק מהעתקה. snapshot של MariaDB שנלקח עם mariadb-backup על שרת פעיל, בתוספת יומנים בינאריים, נותן היסטוריית שינויים מלאה. אנחנו פורסים את ה-snapshot ומריצים את היומנים עד לעמדה או לתווית הזמן הרצויה — עד לשאילתה ששברה הכול. כך עובדת חזרה של נתונים שנמחקו: בסיס הנתונים חוזר למצב של שנייה לפני התקלה.
יש סוג כשל שהרפליקה לא סוגרת: מחיקת טבלאות והשחתה לוגית על הצומת הראשי, כשל אחסון, ודרישת אאודיט להציג נתונים לתאריך מסוים. בנוסף, הרפליקה לעתים קרובות יושבת באותו ארון ובאותו חשבון — תקלה סוחפת גם אותה. את ההעתקות אנחנו מוציאים למערך נפרד.
שורה תחתונה: רפליקציה וגיבוי משלימים זה את זה — הראשונה אחראית לזמינות, השני אחראי לשחזור. את שני המערכים בודקים על סטנד בדיקות, ולא ברגע התקלה.
שאלות טכניות נפוצות על גיבוי
העתקה חמה נלקחת מצומת פעיל: ה-snapshot קורא קבצי נתונים ויומן טרום-טרנזקציות, והעקביות מושגת בזכות ריבוי גרסאות — קוראים לא חוסמים כתיבות. איסור כתיבה נדרש רק לתיעוד העמדה ביומן השכפול, והעומס מצטמצם לקריאה מהדיסק.
ההעתקה תכביד על בסיס הנתונים הפרודקשן?
ההוצאה העיקרית היא קריאת דפים וקריאה חוזרת של שינויים במחזור, והעומס נופל על הדיסק והמטמון. אנחנו מגבילים את המקביליות וקובעים עדיפות קלט/פלט נמוכה מזו של האפליקציה. ההעתקה נמשכת שעות, וזמן התגובה של השאילתות לא משתנה.
צריך לעצור את האפליקציה?
לא. מצב חם עובד על צומת חי, ובסכמות עם רפליקציה לוקחים את ההעתקה מהרפליקה — המאסטר לא נפגע. השבתה נדרשת רק ל-dump לוגי לא-עקבי.
כמה מקום יתפסו ההעתקות?
העתקה מלאה דומה לנפח הנתונים, ואילו האינקרמנט — רק דפים שהשתנו. את השרשרת מקפלים להעתקה מלאה חדשה, וגרסאות ישנות מפונים לפי תקופת האחסון — והגדילה של הנפח צפויה.
איך לבדוק שההעתקה שמישה?
ההעתקה תקפה רק לאחר פריסה: בדיקה אוטומטית מעלה instance נפרד, מיישמת את היומן, משווה סכומי ביקורת ומריצה שאילתות על טבלאות מפתח. שחזור לנקודה נבדק לפי יומן הטרנזקציות.
כבר מוגדר אצלנו גיבוי — מה לשנות?
בודקים מה נעשה כיום: dump לפי תזמון, snapshot בכלי וירטואליזציה או רפליקה בלי יומנים. עונים על השאלה מאיזו העתקה בסיס הנתונים ישתחזר בזמן סביר; אם אין בהירות — מוסיפים בדיקת שמישות ואחסון מנוהל.
נדבר על המשימה: מה נדרש להערכת מערך הגיבוי
דיון במשימה עם מהנדס מתחיל בעובדות על המערך, ולא במשאלות — אחרת ההערכה הופכת למזלג. להלן נתוני פתיחה לחישוב העבודה, שמסירים חלק גדול מהשאלות כבר בהתחלה. אם משהו חסר, נגיד באיזו פקודה להסתכל על זה במערכת פעילה.
- טופולוגיה: שרת בודד, מאסטר עם סלייבים או קלאסטר — מזה תלוי אם ניקח dump לוגי או העתקה פיזית.
- נפח בסיסי הנתונים ופרופיל הכתיבה: גודל הנתונים, חלק השינויים היומי, חלונות פעילות מינימלית.
- יעדי שחזור: לאיזו נקודת זמן מותר לאבד נתונים ובכמה זמן בסיס הנתונים חייב לחזור לפעילות.
- דרישות לעקביות: צריך snapshot עקבי של כל הטבלאות או שמספיקה חזרה לפי היומן לשנייה הרצויה.
- היכן לאחסן את ההעתקות: דיסק מקומי, אחסון רשתי או מערך נפרד, עם מדיניות אחסון ועומק רוטציה.
- הרשאות והצפנה: היכן נשמרים המפתחות, מי מקבל גישה להעתקות, והאם נדרש אאודיט של פעולות.
- מה כבר קיים: נהלים נוכחיים, סקריפטים, תזמונים וסטנד שאפשר לתרגל עליו שחזור.
לאחר מכן אנחנו חוזרים עם הערכת עבודה לגיבוי ותוכנית יישום הגיבוי: הרכב המשימות, סדר, נקודות בדיקה ומה יידרש מצדכם. בנפרד נדבר על ליווי מערך הגיבוי — ניטור, רוטציה של העתקות ותרגולי שחזור קבועים, כדי שההעתקות לא יישארו "על הנייר".