יחידה 10: שחזור ממסדי נתונים

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

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

מערכות מסדי נתונים מודרניות נדרשות לספק שירות רציף ואמין. כשלים הם בלתי נמנעים, בין אם מדובר בכשל של טרנזקציה בודדת, קריסת מערכת (כגון הפסקת חשמל), או כשל בדיסק. מנגנוני השחזור נועדו להבטיח את תכונת ה-Durability (עמידות) מבין תכונות ה-ACID, כלומר, שברגע שטרנזקציה בוצעה בהצלחה (Committed), השינויים שלה יישארו קבועים במסד הנתונים, גם אם המערכת קורסת לאחר מכן. כמו כן, הם מבטיחים שטרנזקציות שלא בוצעו במלואן (Aborted) לא ישאירו אחריהן שינויים חלקיים או לא עקביים.

יומן הרישום (Log) - הלב הפועם של השחזור

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

מבנה רשומות היומן

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

• רשומת יומן (Log Record): תיעוד של אירוע או שינוי שבוצע במסד הנתונים, הכולל מידע כמו מזהה טרנזקציה, סוג פעולה (WRITE, COMMIT, ABORT), ערך ישן וערך חדש.
• מזהה טרנזקציה (Transaction ID).
• סוג הפעולה (לדוגמה: WRITE, COMMIT, ABORT, START).
• עבור פעולות WRITE: מזהה פריט הנתונים, הערך הישן (Before-Image), והערך החדש (After-Image).
• עבור פעולות COMMIT/ABORT: רק מזהה הטרנזקציה.

פרוטוקול Write-Ahead Logging (WAL)

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

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

אלגוריתמי שחזור מבוססי יומן

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

נקודות ביקורת (Checkpoints) - אופטימיזציה לתהליך השחזור

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

סוגי נקודות ביקורת

• נקודת ביקורת פשוטה (Simple Checkpoint): המערכת עוצרת את כל הפעילות, כותבת את כל הדפים המלוכלכים לדיסק, רושמת רשומת Checkpoint ביומן, וממשיכה בפעילות. זהו תהליך יקר שפוגע בזמינות.
• נקודת ביקורת "מטושטשת" (Fuzzy Checkpoint): גישה נפוצה יותר, שבה המערכת ממשיכה לפעול כרגיל בזמן יצירת נקודת הביקורת. רשומת ה-Checkpoint כוללת רשימה של טרנזקציות פעילות ודפים מלוכלכים. הדפים המלוכלכים נכתבים לדיסק ברקע, ואין צורך לעצור את כל הפעילות. זהו המנגנון המועדף במערכות מודרניות.

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

שאלות לדיון

• תארו תרחיש שבו מערכת מסד נתונים קורסת לאחר שטרנזקציה T1 ביצעה COMMIT וטרנזקציה T2 עדיין פעילה. הסבירו כיצד מנגנון שחזור מבוסס יומן (WAL) יטפל במצב זה, תוך פירוט שלבי ה-REDO וה-UNDO.
• הסבירו מדוע פרוטוקול WAL (Write-Ahead Logging) הוא קריטי לשחזור נתונים עקבי, ומה היו ההשלכות אם לא היה מיושם.
• כיצד תדירות יצירת נקודות ביקורת משפיעה על ביצועי המערכת בזמן פעולה רגילה ועל זמן השחזור לאחר קריסה? נמקו את תשובתכם.

נקודות לתשובת מודל

• לשאלה 1:
  • שלב הניתוח: סריקת היומן לאיתור T1 כ-Committed ו-T2 כ-Active.
  • שלב ה-REDO: יישום מחדש של כל השינויים של T1 (אם לא נכתבו לדיסק לפני הקריסה) ושל T2 (עד לנקודת הקריסה) כדי להביא את מסד הנתונים למצב שלפני הקריסה.
  • שלב ה-UNDO: ביטול השינויים של T2 (שלא הסתיימה בהצלחה) על ידי שחזור הערכים הישנים.
• לשאלה 2:
  • WAL מבטיח שרשומת יומן קודמת לשינוי בדיסק, ורשומת COMMIT קודמת ל-Commit בפועל.
  • ללא WAL, ייתכן ששינויים ייכתבו לדיסק לפני שהם מתועדים ביומן, או שטרנזקציה תוכר כ-Committed לפני שרשומת ה-Commit שלה סונכרנה לדיסק.
  • השלכות: אובדן נתונים של טרנזקציות שבוצעו, או השארת נתונים לא עקביים של טרנזקציות שלא בוצעו במלואן.
• לשאלה 3:
  • תדירות גבוהה:
    • ביצועים רגילים: עלולה לפגוע בביצועים עקב עומס כתיבה לדיסק (במיוחד ב-Simple Checkpoints) או עומס עיבוד (ב-Fuzzy Checkpoints).
    • זמן שחזור: מקצר משמעותית את זמן השחזור, מכיוון ששלב ה-Analysis וה-REDO מתחילים מנקודה קרובה יותר לקריסה.
  • תדירות נמוכה:
    • ביצועים רגילים: פחות עומס על המערכת בזמן פעולה רגילה.
    • זמן שחזור: מאריך את זמן השחזור, מכיוון שיש לסרוק חלק גדול יותר של היומן.
  • יש למצוא איזון אופטימלי בין תדירות נקודות הביקורת לבין דרישות הביצועים וזמן השחזור.