บั๊ก SQLite อายุ 16 ปี ทำให้ Tailscale ขัดข้องหลายครั้งในปีที่ผ่านมา

การให้บริการเครือข่ายแบบ peer‑to‑peer ของ Tailscale ต้องเผชิญกับการหยุดทำงานหลายครั้งตั้งแต่ปลายปีที่ผ่านมา หลังจากสอบสวนเป็นเวลาเกือบหกเดือน ทีมวิศวกรเปิดเผยว่าเหตุหลักคือข้อบกพร่องในระบบจัดการฐานข้อมูล SQLite ที่ซ่อนอยู่มานานกว่า 16 ปี การค้นพบนี้ไม่เพียงอธิบายสาเหตุของความขัดข้อง แต่ยังชี้ให้เห็นถึงความเสี่ยงที่อาจเกิดขึ้นเมื่อใช้งานซอฟต์แวร์ระดับพื้นฐานในลักษณะการกำหนดค่าที่ไม่ได้มาตรฐาน

Overview

Tailscale ทำงานบนโปรโตคอล WireGuard VPN เพื่อเชื่อมต่ออุปกรณ์ต่าง ๆ เข้าเป็นเครือข่ายเมชเสมือนที่เรียกว่า “tailnet” ระบบจัดเก็บข้อมูลของ tailnet ทั้งหมดอยู่ในไฟล์ฐานข้อมูล SQLite หนึ่งไฟล์ซึ่งทำหน้าที่บันทึกสถานะและการกำหนดค่าแต่ละอุปกรณ์ การเลือกใช้ SQLite มาจากความนิยม ความเชื่อถือได้สูง และความง่ายต่อการปรับใช้งาน ซึ่งทีมวิศวกรของ Tailscale ได้เริ่มใช้ตั้งแต่ปี 2022

ฐานข้อมูลนี้ถูกสำรองเป็น “snapshot” ทุกหลายนาทีโดยทำการคัดลอกไฟล์ SQLite ทั้งหมดแล้วอัปโหลดไปยัง S3 bucket ของ Amazon Web Services การออกแบบนี้ช่วยให้การกู้คืนข้อมูลทำได้อย่างรวดเร็วเมื่อต้องเผชิญกับเหตุขัดข้องใด ๆ

Incident Timeline

ในเดือนสิงหาคม 2025 ทีมงานเริ่มตรวจพบว่าการสำรองฐานข้อมูลหลายครั้งแสดงผลลัพธ์ว่าไฟล์ SQLite เสียหายโดยไม่มีสาเหตุที่ชัดเจน การตรวจสอบเบื้องต้นไม่พบการเปลี่ยนแปลงโค้ดระดับต่ำหรืออัปเดตซอฟต์แวร์ใด ๆ ที่อาจเป็นตัวกระตุ้น

ทีมวิศวกรของ Tailscale ได้ทำการรวบรวมข้อมูลเหตุการณ์ต่อเนื่องหลังจากแต่ละครั้งที่เกิดข้อผิดพลาด พร้อมเพิ่มเครื่องมือ diagnostic ใหม่หลายชุด เพื่อลดขอบเขตสาเหตุลง แต่ก็ยังไม่สามารถจำลองหรือค้นพบจุดบกพร่องได้

จนกระทั่งเมื่อทำงานร่วมกับทีมดูแล SQLite พวกเขาใช้ “virtual file system shim” ที่พัฒนาขึ้นใหม่เพื่อบันทึกกิจกรรมของระบบไฟล์เสมือนอย่างละเอียด ซึ่งเป็นเครื่องมือที่ได้รับเงินทุนสนับสนุนจาก Tailscale เอง

Technical Root Cause

ผลการวิเคราะห์เผยว่า ปัญหามาจากข้อบกพร่องที่เรียกว่า WAL‑Reset bug ในโหมด **Write‑Ahead Log (WAL) ของ SQLite ซึ่งทำงานเป็น “hopper” ชั่วคราวสำหรับข้อมูลใหม่ ก่อนที่จะถ่ายโอนไปยังไฟล์ฐานข้อมูลหลัก

เมื่อมีหลายการเชื่อมต่อเปิดอยู่บนไฟล์เดียวกันและกระบวนการ checkpoint พยายามคัดลอกหน้า (pages) จาก WAL ไปยังฐานข้อมูลหลัก หากมีการเขียนข้อมูลเกิดขึ้นในช่วงเวลาที่ checkpoint กำลังทำงาน หน้าที่ของ checkpoint จะสับสนคิดว่าหน้าเหล่านั้นได้ถูกคัดลอกแล้วแม้ว่ายังไม่ได้ ทำให้หน้าดังกล่าวหายไปโดยถาวรและทำให้ฐานข้อมูลเสียรูปแบบต่อเนื่อง

ข้อบกพร่องนี้มีเงื่อนไขเฉพาะที่ต้องเปิดใช้งาน WAL mode และมีการเชื่อมต่อหลายอันพร้อมกัน จึงเป็นเหตุผลที่เกิดขึ้นได้ยากในสภาพแวดล้อมปกติ แต่การที่ Tailscale ควบคุมกระบวนการ checkpoint ด้วยตนเองเพื่อให้สำรองข้อมูลทำงานเร็วและสม่ำเสมอ ทำให้ระบบเข้าสู่เงื่อนไขที่หายากนี้

Fix and Mitigation

ทีม SQLite ได้เพิ่มโค้ดใหม่ในซอร์สโค้ดเพื่อลองจำลองสถานการณ์ดังกล่าว และปล่อยเวอร์ชันที่แก้ไขข้อบกพร่องพร้อมคำแนะนำให้ผู้ใช้ทำการอัปเดตทันที เวอร์ชันที่ได้รับการปรับปรุงแล้วเริ่มมีตั้งแต่ 3.7.0 (ออกในเดือนกรกฎาคม 2010) ถึงรุ่นล่าสุดของ SQLite

สำหรับ Tailscale ทีมงานได้ยุติการควบคุม checkpoint ด้วยตนเองและกลับไปใช้กลไกอัตโนมัติของ SQLite อีกครั้ง นอกจากนี้ยังปรับกระบวนการสำรองให้ทำในโหมดที่ไม่เปิดใช้งาน WAL หรือจำกัดจำนวนการเชื่อมต่อพร้อมกันบนไฟล์ฐานข้อมูลเดียว

• อัปเดต SQLite เป็นเวอร์ชันที่แก้ไขแล้ว
• ปิดการใช้ manual checkpoint ในระบบ Tailscale
• ตรวจสอบให้แน่ใจว่าไม่มีหลาย connection เปิดพร้อมกันในโหมด WAL

Implications for Developers

เหตุการณ์นี้ย้ำเตือนให้นักพัฒนาตระหนักว่าซอฟต์แวร์ที่ดูเหมือน “นิ่งและเชื่อถือได้” อย่าง SQLite ก็อาจมีบัคซ่อนเร้นที่อาจก่อให้เกิดผลกระทบร้ายแรงเมื่อใช้งานในลักษณะที่แตกต่างจากการตั้งค่ามาตรฐาน การปรับเปลี่ยนพารามิเตอร์ระบบ เช่น การควบคุม checkpoint ด้วยตนเอง ควรทำอย่างระมัดระวังและต้องมีการทดสอบเชิงลึก

บทเรียนสำคัญอีกประการคือความจำเป็นในการติดตามและอัปเดตซอฟต์แวร์ฐานข้อมูลอย่างสม่ำเสมอ รวมถึงการใช้เครื่องมือ diagnostic ที่เหมาะสมเมื่อพบปัญหาที่ไม่สามารถอธิบายได้ การทำงานร่วมกับชุมชนผู้พัฒนา (เช่น ทีม SQLite) สามารถเร่งกระบวนการแก้ไขและลดความเสี่ยงต่อระบบในระยะยาว

Summary

การหยุดทำงานของ Tailscale ในปีที่ผ่านมาได้รับสาเหตุจากข้อบกพร่อง WAL‑Reset ของ SQLite ที่ซ่อนอยู่มานานกว่า 16 ปี การอัปเดตฐานข้อมูลและการเปลี่ยนแปลงวิธีจัดการ checkpoint ทำให้ระบบกลับสู่ภาวะปกติ บทเรียนสำคัญคือควรหลีกเลี่ยงการปรับแต่งพารามิเตอร์พื้นฐานของซอฟต์แวร์โดยไม่เข้าใจผลกระทบอย่างละเอียด.