Tailscale איתרה באג WAL-Reset בן 16 שנה ב-SQLite

במשך חצי שנה חוותה שכבת הבקרה של Tailscale 19 מקרים נפרדים של שחיתות במסדי נתונים, שכולם נבעו מבאג יחיד עמוק בתוך SQLite. בפוסט מפורט בבלוג מסבירה החברה כיצד, יחד עם מפתחי הליבה של מסד הנתונים, איתרה ותיקנה את „באג WAL-Reset” — מירוץ נתונים נדיר שלהערכתם היה קיים ב-SQLite לפחות 16 שנה.

שארדים עם כותב יחיד וצ׳קפוינטים אגרסיביים

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

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

באג שאי אפשר לשחזר

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

באג ה-WAL-Reset

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

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