Tailscale Lacak Bug SQLite Berumur 16 Tahun yang Bikin Database Rusak

Tailscale baru-baru ini mempublikasikan laporan forensik teknis yang menggemparkan komunitas developer: mereka berhasil melacak bug penyebab korupsi database yang ternyata sudah bersembunyi di SQLite selama 16 tahun. Bug ini menjadi mimpi buruk bagi tim infrastruktur karena menyebabkan 19 insiden korupsi database dalam enam bulan.

Artikel ini akan membahas bagaimana Tailscale menemukan bug tersebut, dampaknya pada arsitektur mereka, dan pelajaran penting bagi developer yang menggunakan SQLite di production.

Konteks: Arsitektur Database Tailscale

Tailscale menggunakan SQLite sebagai database utama untuk control plane sejak tahun 2022. Setiap tailnet berada pada shard yang memiliki database SQLite sendiri, diakses secara eksklusif oleh satu proses Go. Desain single-writer ini seharusnya sesuai dengan best practice SQLite.

Pipeline backup mereka mengambil snapshot lengkap database setiap beberapa menit dan mengunggahnya ke S3. Sistem ini berjalan lancar hingga Agustus tahun lalu, ketika pipeline data melaporkan error korupsi pada salah satu backup. Setelah menjalankan PRAGMA integrity_check, temuan itu terkonfirmasi: database memang rusak.

Korupsi yang Terus Berulang

Seiring waktu, insiden korupsi tidak hanya terjadi sekali. Tailscale mencatat 19 insiden korupsi database dalam periode enam bulan. Setiap kali korupsi terjadi, shard yang terdampak harus dihentikan sementara, menyebabkan downtime control plane untuk tailnet di shard tersebut.

Berikut beberapa fakta kritis dari laporan Tailscale:

• Database yang rusak hanya berisi metadata konfigurasi, bukan kunci enkripsi atau traffic jaringan pengguna.

• Korupsi tidak terikat pada shard tertentu, pelanggan tertentu, atau waktu tertentu.

• Bug ini sangat sulit direproduksi secara sintetis karena tidak ada pola waktu yang konsisten.

Investigasi yang Panjang

Tim Tailscale menghabiskan waktu berbulan-bulan untuk investigasi. Mereka meninjau ulang seluruh kode low-level yang berinteraksi dengan SQLite, mencari faktor umum antar insiden, dan bahkan mengontrak professional support dari SQLite developers.

Tanpa pola reproduksi yang jelas, tim harus mengandalkan telemetry forensik di lingkungan live. Mereka menambahkan diagnostic setiap kali insiden terjadi, secara bertahap menyaring berbagai teori seperti broken POSIX locks, memory mismanagement, atau masalah thread safety.

Kunci Temuan: Transaksi yang Hilang

Terobosan datang ketika Tailscale membangun pipeline transaction logging. Setiap perubahan database dicatat dalam log file terpisah, yang理论上 bisa direplay ke backup terakhir yang valid untuk memulihkan state terbaru tanpa kehilangan data.

Namun, pada dua insiden, replay log gagal. Setelah investigasi mendalam, tim menemukan bahwa data yang ditulis dan dicommit oleh satu transaksi secara misterius tidak terlihat oleh transaksi berikutnya. Write telah hilang tanpa error.

Temuan ini mengarah pada area checkpointing SQLite. Bersama dengan SQLite developers, Tailscale mengidentifikasi bug lama yang berhubungan dengan WAL reset. Bug ini telah ada di SQLite selama 16 tahun dan baru memanifestasi di kondisi konkuren tertentu yang dijalankan Tailscale.

Respons dan Perbaikan

Tailscale mengambil langkah agresif untuk meminimalkan dampak sambil mencari akar masalah:

1. Konfigurasi shard untuk hard-stop otomatis saat mendeteksi korupsi.

2. Deployment backup monitor yang terus menjalankan PRAGMA integrity_check.

3. Peningkatan runbook dan pelatihan on-call.

4. Automated recovery untuk mempercepat proses restore.

Setelah bug diidentifikasi, mereka bekerja sama dengan tim SQLite untuk mengembangkan patch. Saat ini, Tailscale yakin bug telah diperbaiki dan tidak ada insiden korupsi baru.

Pelajaran untuk Developer

Beberapa takeaway penting dari kasus ini:

• Boring technology tidak selalu aman: SQLite memang andal, tapi edge case bisa muncul kapan saja di skala besar.

• Forensik live lebih baik dari reproduksi sintetis: Ketika bug tidak bisa direproduksi, telemetry yang matang di production adalah kunci.

• Jangan ragu meminta bantuan expert: Professional support dari tim upstream bisa mempercepat penyelesaian berminggu-minggu.

• Single-writer tidak menjamin keamanan: Bahkan dengan desain SQLite yang ideal, interaksi dengan sistem operasi dan hardware bisa memunculkan bug tak terduga.

Kesimpulan

Laporan dari Tailscale ini adalah studi kasus klasik tentang bagaimana bug di sistem yang dianggap stabil bisa memunculkan masalah besar di skala production. Bagi developer Indonesia yang mengandalkan SQLite di backend mereka, cerita ini mengingatkan pentingnya monitoring, backup, dan tidak pernah menganggap software mature sebagai 100% bebas risiko.

Gambar: Tailscale Blog.