Wawancara Rekayasa Data: Menangani Risiko Korupsi Data WAL-reset pada SQLite secara Aman

Petunjuk dan konteks

Sebuah layanan sinkronisasi desktop membuka satu file SQLite dari beberapa proses dalam mode WAL. Tim mengetahui bahwa versi-versi terdahulu mungkin mengandung bug WAL-reset dan mengkhawatirkan keamanan pembacaan yang keliru, penulisan konkuren selama proses peningkatan (upgrade), atau sinkronisasi salinan yang rusak ke hilir (downstream). Rancang inventaris versi, penilaian risiko, peningkatan, verifikasi integritas, pemulihan cadangan, dan rollback, termasuk kontrol akses multiproses.

Hal yang diuji oleh pewawancara

• Memisahkan rentang versi yang terpengaruh dari kondisi yang dapat memicu bug tersebut.
• Membangun matriks peningkatan dari versi resmi yang telah diperbaiki dan versi backport.
• Mengurutkan langkah-langkah pencadangan yang konsisten, verifikasi, isolasi, dan pemulihan.
• Menjelaskan batasan dari PRAGMA integrity_check alih-alih menganggapnya sebagai kebenaran bisnis.
• Menangani penulisan multiproses, checkpoint, penyalinan file, dan efek samping sinkronisasi.

Pertanyaan untuk klarifikasi

1. Versi SQLite, opsi build, sistem operasi, dan mode jurnal apa tepatnya yang diterapkan?
2. Apakah ada dua atau lebih proses atau thread yang menulis ke atau melakukan checkpoint pada file yang sama?
3. Cadangan terverifikasi, replika, dan stempel waktu pemeriksaan sukses terakhir apa saja yang ada?
4. Bisakah proses peningkatan membekukan penulisan secara singkat dan memaksa proses lama untuk keluar?
5. Apakah target pemulihan berupa toleransi kehilangan transaksi terkini, rekonstruksi server, atau pemulihan persis seperti semula?

Jawaban 30 detik

Pertama-tama saya akan menginventarisasi versi dan mode runtime; rentang versi yang terpengaruh tidak membuktikan adanya kerusakan. Dokumen SQLite mencatat bug WAL-reset pada beberapa skenario WAL dari versi 3.7.0 hingga 3.51.2, yang telah diperbaiki pada versi 3.51.3 dan setelahnya, dengan beberapa rilis backport. Sebelum meningkatkan, bekukan penulisan, salin database beserta bukti WAL/SHM, dan catat baseline verifikasi. Lakukan peningkatan pada salinan terisolasi, lalu jalankan pemeriksaan integritas struktural, sampling tingkat bisnis, dan pemeriksaan konsistensi sinkronisasi. Alihkan file produksi hanya setelah gerbang validasi lolos, dengan tetap menyimpan salinan rollback. Untuk jangka panjang, batasi penulisan multiproses, pantau checkpoint, konflik penguncian, dan kegagalan verifikasi, serta jadikan simulasi pemulihan sebagai bagian dari gerbang rilis.

Pembahasan mendalam langkah demi langkah

1. Membangun matriks dampak

Dokumentasi resmi SQLite menetapkan kemungkinan rentang bug dari versi 3.7.0 hingga 3.51.2, dengan perbaikan pada 3.51.3 dan yang lebih baru serta backport pada 3.44.6 dan 3.50.7. Risiko ini juga membutuhkan mode WAL, beberapa koneksi ke satu file, serta penulisan atau checkpoint yang saling bersilangan (interleave) dalam rentang waktu yang sangat sempit. Catat versi SQLite, status WAL, jumlah koneksi, model proses, dan lokasi file setiap klien, lalu klasifikasikan sebagai "versi terpengaruh ditambah kondisi pemicu terpenuhi".

version/mode -> WAL enabled -> multi-connection/process -> concurrent write/checkpoint
      |             |                    |                         |
      +-- upgrade gate ------------------+----------> isolate, verify, rehearse recovery

2. Membekukan dan mengamankan bukti

Hentikan penulisan baru dan biarkan aplikasi menutup koneksi secara baik-baik. Jika proses lama mungkin masih berjalan, jangan mengganti atau menyalin database. Amankan database asli, file WAL/SHM di direktori yang sama, data versi, cadangan terbaru, dan log verifikasi. Salin hanya dari kondisi stabil; WAL yang terus berubah bukanlah snapshot statis.

3. Meningkatkan dan memverifikasi dalam isolasi

Buka salinan dengan versi yang sudah diperbaiki. Jalankan pemeriksaan integritas tingkat SQLite terlebih dahulu, kemudian pemeriksaan aplikasi untuk jumlah baris, indeks utama, foreign key, kursor sinkronisasi, dan transaksi terkini. integrity_check dapat menemukan masalah struktural tetapi tidak dapat membuktikan semantik domain, kesetaraan replika jarak jauh, atau kelengkapan pekerjaan yang belum di-commit. Kaitkan hasil pemeriksaan dengan hash salinan dan versi alat.

4. Mengalihkan, melakukan rollback, dan memulihkan

Setelah gerbang validasi lolos, alihkan path file atau direktori berversi secara atomik dan simpan salinan lama sebagai read-only. Jika saat startup ditemukan kegagalan verifikasi, konflik sinkronisasi, atau kesenjangan bisnis, hentikan penulisan baru, beralih kembali ke versi sebelumnya atau bangun ulang dari cadangan tepercaya, lalu lakukan sinkronisasi ulang secara inkremental. Jangan menjalankan VACUUM, perbaikan massal, atau menimpa salinan pada file yang dicurigai rusak sebelum mengamankan bukti.

5. Mengatur penulisan multiproses dan checkpoint

Utamakan satu proses penulis (writer) untuk satu file dan serialisasikan transaksi penulisan melalui antrean; proses lain menggunakan koneksi baca yang terkontrol. Tentukan siapa yang memicu checkpoint, batas waktu (timeout), dan peringatan kegagalan agar beberapa komponen tidak melakukan checkpoint secara bersamaan. Jika akses multiproses tidak dapat dihindari, catat siklus hidup koneksi, waktu tunggu kunci, hasil checkpoint, dan versi proses, serta lakukan stress-test terhadap penulisan dan checkpoint yang saling bersilangan.

6. Memantau dan melatih pemulihan

Setelah rilis, pantau cakupan versi SQLite, pertumbuhan WAL, latensi checkpoint, konflik penguncian, kegagalan integritas, upaya ulang sinkronisasi, dan waktu pemulihan. Latih prosedur "bekukan—cadangkan—verifikasi—alihkan—rollback" pada salinan yang telah disanitasi dan verifikasi bahwa klien lama tidak dapat membuka kembali database versi lama. Nyatakan target pemulihan sebagai RPO dan RTO bisnis daripada sekadar mengatakan "cadangan tersedia".

Jawaban model

Saya akan memulai dengan matriks dampak: apakah SQLite berada di antara versi 3.7.0–3.51.2, apakah WAL aktif, apakah banyak koneksi berbagi file yang sama, dan apakah penulisan serta checkpoint dapat saling tumpang tindih. Berada dalam rentang tersebut berarti perlu melakukan peningkatan dan verifikasi; hal itu tidak membuktikan adanya kerusakan. Bekukan penulisan, pastikan proses lama telah keluar, amankan database, WAL/SHM, cadangan, versi, dan nilai hash, lalu tingkatkan salinan terisolasi ke versi 3.51.3 atau backport yang dapat diterima.

Verifikasi memiliki tiga lapisan: PRAGMA integrity_check untuk struktur, sampling aplikasi untuk data dan indeks utama, serta pemeriksaan sinkronisasi untuk kursor lokal versus jarak jauh. Lakukan pengalihan secara atomik setelah lolos gerbang dan simpan salinan lama sebagai read-only. Jika pemeriksaan atau invarian bisnis gagal, hentikan penulisan, pulihkan salinan tepercaya, dan bangun ulang sinkronisasi inkremental. Untuk jangka panjang, pusatkan penulisan pada satu proses, batasi checkpoint aktif, pantau konflik penguncian serta kegagalan verifikasi, dan lakukan simulasi pemulihan.

Kesalahan umum

• Menyatakan database rusak hanya karena versi lama yang sedang diterapkan.
• Meningkatkan biner tanpa membekukan penulisan atau tanpa mengamankan WAL/SHM dan salinan rollback.
• Menganggap satu hasil integrity_check yang lolos sebagai bukti kebenaran bisnis yang lengkap.
• Menjalankan VACUUM atau menimpa file yang dicurigai rusak sebelum mengamankan bukti.
• Membiarkan banyak proses melakukan checkpoint secara independen tanpa metrik konflik dan timeout.
• Mengatakan "kami mencadangkan secara teratur" tanpa konsistensi cadangan, RPO, RTO, atau simulasi pemulihan.

Pertanyaan lanjutan dan tanggapan

Jika versinya terpengaruh tetapi tidak ada anomali yang terlihat, bisakah kita melewati peningkatan?

Tidak. Gunakan kondisi pemicu untuk menilai paparan jangka pendek dan jadwalkan penerapan versi yang telah diperbaiki; tidak adanya kegagalan yang teramati tidak menyangkal adanya race condition yang sempit.

Mengapa perlu melakukan pemeriksaan bisnis setelah PRAGMA integrity_check lolos?

Metode tersebut terutama memeriksa struktur database dan batasan-batasan tertentu. Metode ini tidak memvalidasi kursor sinkronisasi, invarian domain, kesetaraan jarak jauh, atau kelengkapan transaksi terkini, sehingga sampling aplikasi dan perbandingan replika tetap diperlukan.

Apa langkah sementara jika akses multiproses tidak dapat didesain ulang dengan segera?

Satukan versi SQLite dan pengaturan startup, larang checkpoint aktif yang tidak terkontrol, serialisasikan penulisan, dan tingkatkan telemetri konflik penguncian. Perkecil batch canary dan simpan salinan read-only yang dapat dialihkan kembali dengan cepat hingga desain penulis tunggal (single-writer) tersedia.