Tailscale אישרה כי פגם בן 16 שנים במנגנון ה-Write-Ahead Logging (WAL) של SQLite עלול להשחית מסדי נתונים בשקט, והחברה עבדה עם המפתחים של SQLite כדי להוציא תיקון בגרסה 3.46.1. הגילוי חשוב מכיוון ששירותים מודרניים רבים עדיין מריצים את SQLite במצב WAL, והשחתה שלא מזוהה עלולה למחוק נתוני קונפיגורציה ולשבש צמתי רשת.

כיצד הבאג חמק?

הבאג התקיים במנגנון ה-WAL מאז 2010. אינטראקציה נדירה בין דפוסי גישה בעלי ריבוי תהליכים גבוה (high-concurrency) לבין התנהגויות מסוימות של מערכת הקבצים גרמה להשחתת נתונים שקטה, ובדיקות תקינות (health checks) סטנדרטיות פספסו אותה.

מהנדסי Tailscale הבחינו לראשונה בכמה צמתים שמאבדים את המצב השמור שלהם ללא הודעות שגיאה ברורות. בדיקות (probes) ששואלות "האם מסד הנתונים פעיל?" המשיכו להחזיר הצלחה, אך רשומות קונפיגורציה נעלמו. שחזור הבעיה דרש כלים מותאמים אישית שהעמיסו על נתיב ה-WAL וכוונו את תזמון מערכת הקבצים, וזו הסיבה שהבעיה נותרה חבויה במשך יותר מעשור.

מי צריך לדאוג?

  • כל אפליקציה שמריצה את SQLite עם WAL מופעל, במיוחד כאשר תהליכים (processes) או threads מרובים כותבים בו-זמנית.
  • פריסות על מערכות קבצים לא סטנדרטיות או מבוססות רשת, שבהן שיהוי (latency) ומטמון (caching) מגבירים את מקרי הקצה של התזמון.
  • שירותי תשתית המתייחסים לקובץ SQLite שנראה תקין כערובה לשלמות הנתונים (data integrity).

צעדי הפחתת סיכונים

  1. שדרוג SQLite – עברו לגרסה 3.46.1 ומעלה; הבאג ב-WAL תוקן שם.
  2. הרצת בדיקות תקינות – בצעו מדי פעם את הפקודה PRAGMA integrity_check; או את הפקודה המהירה יותר PRAGMA quick_check; כדי לוודא את המבנים הפנימיים של מסד הנתונים.
  3. ביקורת על השימוש ב-WAL – סרקו מאגרי קוד עבור הגדרות journal_mode=WAL והחליטו האם רמת הריבוי (concurrency) מצדיקה אותן.
  4. חיזוק הניטור – הוסיפו בדיקות המשוות דפוסי נתונים צפויים או ספירת שורות, במקום רק לאשר נגישות.
  5. גיבוי רציף – השתמשו בכלים כמו Litestream המשכפלים שינויים ב-SQLite בזמן אמת, ומספקים רשת ביטחון אם השחתת נתונים חומקת מהזיהוי.

מה הלקח מהמקרה הזה?

  • באגים ישנים יכולים לצוף תחת עומסים חדשים – ככל ששירותים גדלים (scale), דפוסים שהיו פעם נדירים הופכים לנפוצים, וחושפים פגמים ישנים.
  • השחתה שקטה מסוכנת יותר מקריסה – קריסה מחייבת הפעלה מחדש ובדרך כלל מפעילה התראות; אובדן נתונים שקט יכול לעבור מבלי שיבחינו בו במשך שבועות.
  • ניתוחי אירועים (post-mortems) פתוחים עוזרים לאקו-סיסטם – הדיווח המפורט של Tailscale סיפק לצוותים אחרים את המידע שהם היו צריכים כדי לבקר את הפריסות שלהם במהירות.

מה לעקוב אחריו בהמשך

Tailscale עבדה עם צוות SQLite כדי להבטיח שתיקון יהיה מוכן לפני ששיתפו את החדשות.

שורה תחתונה: באג שהתקיים מבלי שיבחינו בו במשך 16 שנים צף מחדש מכיוון שעומסי עבודה מודרניים דחפו את SQLite בדרכים שמפתחי המקור שלו מעולם לא דמיינו. עדכון הספרייה, הרצת בדיקות תקינות ושיפור יכולת התצפית (observability) הם הדרכים המהירות ביותר להתגונן מפני כשלים נסתרים דומים.