הגדרת גיבוי חם של MySQL עם Percona XtraBackup

גיבוי MySQL עם Percona XtraBackup: מה נשבר

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

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

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

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

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

מה נותן גיבוי חם: אפקט מדיד

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

חלון הגיבוי מתכווץ פי כמה

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

זמן השחזור — עשרות דקות במקום שעות

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

נעלם סוג התקלות «גיבוי קיים, אבל לא עולה»

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

מצבי גיבוי ודחיסה: השוואת אפשרויות

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

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

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

הטמעת Percona XtraBackup: שלבי עבודה הנדסית

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

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

תצורות, סכמות ונהלי שחזור למסד נתונים

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

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

מקרה בוחן: החזרת מסד בדקות במקום שעות

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

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

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

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

מדדים לפני ואחרי: חלון הגיבוי הצטמצם מ-4-5 שעות ל-12 דקות, שחזור מלא — מ-6 שעות ל-9 דקות, שיעור הגיבויים שנפרסים בהצלחה עלה מ-70% ל-100%. נעלם סוג שלם של תקלות «ארכיון קיים, אבל לא עולה»: אם גיבוי לא עובר בדיקה, התורן לומד על כך באותו לילה, ולא ברגע התקלה.

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

במה שונה גיבוי חם מגיבוי לוגי: מה לבחור

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

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

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

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

ספקות טכניים: עקביות, עומס, בדיקות

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

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

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

האם אפשר לשחזר לא את כל המסד, אלא טבלה אחת?

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

כמה גיבויים להחזיק ואיפה?

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

איך לוודא שהגיבוי ניתן לשחזור?

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

נדבר על המשימה: מה להכין לשיחה

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

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

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