Write-Ahead Log: איך מסדי נתונים מבטיחים Durability בלי לאבד נתונים

מאת צוות מדיה דיל · 25.06.2026 · טכנולוגיה · 5 דק׳

עקרון הכתיבה הסדרתית ללוג לפני עדכון הנתונים, Redo ו-Undo בשחזור מקריסה, Checkpoints, הבסיס ל-Replication ול-Change Data Capture.

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

העיקרון: לכתוב ללוג לפני שמעדכנים את הנתונים

עדכון ישיר של עמוד נתונים על הדיסק בכל טרנזקציה יקר מאוד — זה כרוך בכתיבה אקראית למיקומים שונים בקובץ, ובלחץ מתמיד על ה-cache. WAL הופך את זה לכתיבה סדרתית בלבד: כל שינוי נרשם כרשומה חדשה בסוף קובץ הלוג, שהוא הרבה יותר מהיר על כל סוגי האחסון. השינוי בפועל למבנה הנתונים העיקרי (ה-heap, ה-B-tree) קורה מאוחר יותר, ברקע, וממוזג בהדרגה — לא בכל טרנזקציה בנפרד.

Durability בלי לאבד נתונים בקריסה

כשטרנזקציה מאשרת COMMIT למשתמש, מסד הנתונים כבר כתב את הרשומה המתאימה ללוג ואישר שהיא הגיעה לדיסק (fsync) — זו ההבטחה של ה-D באות ACID. אם המסד קורס מיד אחרי, האתחול הבא קורא את הלוג מהנקודה האחרונה שאושרה כ"בטוחה" (checkpoint) ומריץ מחדש (redo) כל שינוי שנרשם אך לא הספיק להיכתב למבנה הראשי, ומבטל (undo) כל שינוי ששייך לטרנזקציה שלא הגיעה ל-COMMIT. כך המסד תמיד חוזר למצב עקבי, בלי לאבד עדכון שאושר ובלי להשאיר עדכון חלקי שלא אושר.

Checkpoints: לא לשמור את הלוג לנצח

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

הבסיס ל-Replication

ברגע שיש רצף מלא ומסודר של כל שינוי שקרה במסד, replication הופך לפשוט יחסית: replica מתחברת, מקבלת עותק התחלתי, ואז פשוט מנגנת (replay) את אותו זרם לוג שה-primary כבר כתב, בלי לחשב מחדש שום דבר. זו הסיבה שרוב מנגנוני ה-replication ב-Postgres וב-MySQL מבוססים ישירות על שידור ה-WAL או ה-binlog, ולא על מנגנון סנכרון נפרד — הלוג כבר מכיל את כל המידע הדרוש.

הבסיס ל-Change Data Capture

Change Data Capture בנוי על אותו עיקרון בדיוק: כלי כמו Debezium הוא בעצם עוד "replica" שקוראת מה-WAL, רק שבמקום להחיל את השינויים על מבנה נתונים מקומי היא הופכת כל רשומה לאירוע ומשדרת אותו החוצה. זו הסיבה ש-CDC לא דורש שום שינוי בקוד האפליקציה — הוא פשוט מצטרף כצרכן נוסף לזרם שכבר קיים ונכתב ממילא לכל טרנזקציה.

מחיר ה-WAL

הלוג עצמו הוא כתיבה נוספת לכל טרנזקציה, כך ש-durability מלאה עולה במחיר של throughput — הגדרות כמו synchronous_commit ב-Postgres מאפשרות לוותר על חלק מהערבות (למשל לא לחכות ל-fsync בכל commit בודד) תמורת מהירות, במחיר סיכון לאבד את הטרנזקציות האחרונות ממש בזמן קריסה. ברוב המערכות שבנויות סביב זמינות גבוהה הפשרה הזו נבחרת במודע ולא כברירת מחדל עיוורת.

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

תגיות: Write-Ahead Log · WAL · Durability · ACID · Replication · Checkpoint

← חזרה לבלוג · צור קשר