הגדרת גיבוי MongoDB באמצעות Percona Backup for MongoDB

גיבוי MongoDB נשבר: ניתוח באמצעות Percona Backup for MongoDB

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

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

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

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

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

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

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

Percona Backup for MongoDB משנה את שני המדדים. יומן הפעולות הרציף נשמר בנפרד מהעותק המלא, ולכן נקודת השחזור זזה לדקות לפני הכשל, ולא ללוח הזמנים האחרון.

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

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

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

גיבוי לוגי, פיזי וזרימה: מה לבחור

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

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

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

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

ב-Percona Backup for MongoDB כל ארבעת המצבים מופעלים בקבוצת פקודות אחת, וניתן לשלב אותם בלוח זמנים אחד:

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

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

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

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

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

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

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

ניתוח מקרה הטמעה: שחזור בדקות במקום בשעות

איך זה היה מסודר לפני

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

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

מה שינו

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

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

מה לעשות אם הגיבוי כבר מוגדר בסקריפט עצמאי?

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

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

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

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

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

ספקות טכניים: יומנים, חלונות, תאימות גרסאות

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

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

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

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

מה יקרה להעתקה אם הרפליקה פיגרה או צומת נפל?

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

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

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

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

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