Litestream kini mendukung pemulihan titik waktu yang cepat

• Litestream adalah alat untuk mencadangkan aplikasi full-stack berbasis SQLite dengan aman ke object storage, dan kali ini mengalami perubahan fitur terbesar
• Dengan menerapkan format file LTX dan teknik compaction yang lebih efisien dibanding arsitektur sebelumnya, kini dimungkinkan pemulihan titik waktu yang cepat dan efisien
• Pendekatan baru yang memanfaatkan conditional write menyederhanakan implementasi singleton reader dan fitur read replica
• Segera akan tersedia lapisan read-replica berbasis VFS sehingga dapat diperluas dengan mudah di berbagai lingkungan
• Arsitektur yang jauh lebih ditingkatkan memungkinkan sinkronisasi banyak database secara bersamaan, sehingga skalabilitas meningkat

---

Pengenalan Litestream dan pentingnya

• Litestream adalah alat open source yang menyediakan fungsi untuk mencadangkan dengan aman berbagai aplikasi full-stack berbasis SQLite ke object storage
• Alat ini menyelesaikan masalah ketergantungan data pada satu server akibat sifat embedded SQLite, sehingga pemulihan data menjadi lebih mudah bahkan saat terjadi kegagalan server

Perkembangan Litestream

• Litestream hadir pada tahun 2020 untuk mempermudah penggunaan SQLite
• Litestream berjalan sebagai proses terpisah dari aplikasi SQLite, menggantikan proses checkpointing WAL, lalu melakukan streaming perubahan data secara real-time ke object storage seperti S3
• Bahkan jika server hilang, database dapat dipulihkan secara efisien ke kondisi terbaru dari object storage
• Setelah itu, proyek bernama LiteFS dikembangkan lebih lanjut untuk mendukung read replica dan failover utama dasar (Primary Failover), sehingga SQLite bisa digunakan dengan arsitektur deployment modern seperti Postgres
• Baik LiteFS maupun Litestream memiliki keunggulan masing-masing, tetapi Litestream lebih mudah dideploy dan digunakan sehingga lebih luas dipakai

Pemulihan titik waktu yang efisien (Point-in-time Restore)

• Desain Litestream sebelumnya terus merekam semua perubahan dan mengirimkannya ke S3, tetapi ini tidak efisien saat pemulihan jika data sering berubah
• Di LiteFS, diperkenalkan pendekatan berbasis kesadaran transaksi, menggunakan format file LTX yang mencatat rentang halaman yang berubah dalam urutan terurut
• Beberapa file LTX dapat dengan mudah digabungkan (compaction) sehingga hanya versi terbaru yang dipertahankan, yang secara drastis meningkatkan kecepatan dan efisiensi pemulihan data
• Struktur ini mirip dengan pohon LSM
• Litestream baru juga mengadopsi file LTX dan metode compaction, sehingga mendukung pemulihan titik waktu yang akurat tanpa banyak penyimpanan duplikat

CASAAS: Compare-and-Swap as a Service

• Litestream harus dapat bekerja tanpa aplikasi SQLite menyadari sistem backup, tetapi jika proses mati akibat kegagalan dan semacamnya, perubahan data bisa saja terlewat
• Untuk mengatasi masalah ini, diperkenalkan konsep generation untuk mengidentifikasi secara unik setiap sesi backup dan aliran log yang terkait dengannya
• Di LiteFS, Consul digunakan untuk menjamin satu reader tunggal, tetapi karena memerlukan dependensi eksternal, Litestream mengimplementasikan jalur replikasi tunggal (singleton) secara sederhana dengan fitur conditional write dari object storage seperti S3
• Dengan demikian, sistem dapat beroperasi secara stabil tanpa kebingungan bahkan di lingkungan node ephemeral

Fitur read replica yang ringan

• LiteFS menggunakan filesystem FUSE untuk kesadaran transaksi, tetapi hal ini membawa kompleksitas dan beban adopsi
• Untuk menguranginya, modul ekstensi SQLite Virtual Filesystem(VFS) bernama LiteVFS dirancang agar dapat berjalan di berbagai lingkungan tanpa FUSE
• Ke depannya, Litestream juga akan menerapkan lapisan berbasis VFS yang sama untuk menyediakan lapisan read-replica yang mengambil dan melakukan cache halaman langsung dari object storage seperti S3
• Memang tidak secepat SQLite lokal, tetapi melalui strategi caching dan prefetching, diharapkan dapat memberikan performa yang memuaskan untuk banyak kasus penggunaan

Open source dan kegunaan

• Litestream sepenuhnya open source, tidak bergantung pada Fly.io, dan dapat digunakan di mana saja
• Ditambahkan pula kemampuan untuk menyinkronkan sejumlah besar database dalam satu proses, sehingga ratusan hingga ribuan database dapat dicadangkan/direplikasi secara efisien

Pertumbuhan berkelanjutan bersama SQLite

• SQLite adalah database tangguh yang terus melahirkan kasus penggunaan baru bahkan di tengah perubahan industri
• Baru-baru ini, di bidang seperti agen pembuat kode berbasis LLM, rollback dan percabangan data real-time menjadi penting, sehingga kemampuan pemulihan titik waktu Litestream yang telah ditingkatkan dapat menjadi fondasi yang penting
• Ke depannya, arsitektur yang ditingkatkan ini juga akan berkontribusi pada fitur lanjutan seperti rollback, fork, dan dukungan untuk agen otomatis
• Litestream baru lebih unggul dibanding desain sebelumnya, sekaligus memperkuat skalabilitas dan kemudahan penggunaan

[xguru]

Litestream - alat replikasi streaming SQLite
Saya all-in pada SQLite sisi server

[GN⁺]

Komentar Hacker News

• Berbagi pengalaman menemukan letak repositori kode; ada pendapat bahwa 2 tahun lalu penggunaan litestream dan litefs terasa kurang nyaman, tetapi kali ini sebagian besar masalah tampaknya sudah terselesaikan. Kini litestream bisa diterapkan ke database dengan lebih leluasa dan kekhawatiran soal banyak writer pun berkurang. Ada juga harapan pada keunggulan lapisan FUSE untuk read replica, serta pengenalan metode pengambilalihan lease di pull request terkait (jika lease sudah ada, proses baru akan mencoba lagi setiap 1 detik sehingga mendukung rolling restart yang cepat), yang dinilai sebagai pendekatan praktis.

• Kesan bahwa semua fitur yang diharapkan dari Litestream baru akhirnya sudah terwujud, disertai rasa antusias dan bersemangat.

• Pandangan positif terhadap pendekatan yang sangat cerdas dan menyederhanakan deployment; dalam situasi yang memerlukan backup ribuan SQLite DB, selama ini pernah membuat solusi sementara dengan fanotify dan Backup API milik SQLite. Jika wildcard replication mendukung banyak file, ada harapan ingin beralih ke Litestream.

• Menekankan bahwa setelah beralih ke LTX, replikasi /data/*.db menjadi mungkin meskipun ada ratusan atau ribuan database dalam satu direktori. Bagian ini sebelumnya dianggap sebagai hambatan yang sangat menentukan. Kini ada pandangan positif bahwa di lingkungan multi-tenant, pemulihan ke titik waktu tertentu per database pengguna, serta unduh dan migrasi data, menjadi mungkin.

• Ucapan terima kasih kepada ben sambil berbagi pengalaman penggunaan nyata; litestream telah dipakai di produksi selama lebih dari sekitar 1 tahun untuk use case internal yang write-heavy (sekitar 12GB setelah kompresi), dan biaya bulanannya sangat kecil, hanya sekitar beberapa ratus won berdasarkan Azure. Ada harapan besar untuk menerapkan perubahan baru ini.

• Harapan agar pengalaman pengembang berbasis SQLite di Fly bisa lebih dipoles lagi. Kekurangan saat ini adalah UI dan CLI bawaan yang kurang memadai, sehingga menyiapkan database awal di Fly Machine ternyata membutuhkan cukup banyak proses. fly console juga tidak terintegrasi dengan SQLite dengan baik dan berjalan di mesin terpisah sehingga tidak bisa mengakses volume tempat data berada. Akhirnya harus masuk langsung ke mesin terkait dengan fly ssh console —pty, yang dinilai merepotkan. Karena web app berbasis SQLite kebanyakan berskala kecil, untuk menghasilkan pendapatan perlu mengoperasikan banyak instance, dan itu menjadi tantangan tersendiri.

  • Pertanyaan tentang arah pilihan pribadi terhadap kombinasi Rails 8 dan SQLite, serta rasa penasaran apakah belakangan ini lebih disukai dibanding Postgres.

• Berbagi pengalaman pribadi yang kebetulan membaca tulisan ini pada saat sedang meneliti Litestream. Menggunakan Sqlite di VPS dan sedang mempertimbangkan adopsi Litestream. Ada pertanyaan apakah database bisa dipulihkan ke titik waktu tertentu saat proses Litestream sedang berjalan. Karena auto-checkpointing mengonsumsi WAL ketika proses mati, muncul rasa penasaran tentang rentang waktu yang tidak bisa dipulihkan (misalnya proses berhenti karena gangguan dari 2:00 sampai 3:00; pemulihan ke 1:55 atau 3:05 mungkin bisa, tetapi informasi pemulihan di antara 2:00~3:00 hilang).

  • Penjelasan bahwa Litestream menyimpan segmen WAL berdasarkan satuan waktu tertentu, dan secara default mengirim perubahan WAL setiap detik, sehingga pemulihan per detik ke titik waktu yang diinginkan dimungkinkan selama masih dalam periode retensi yang dikonfigurasi.

  • Pertanyaan tentang masalah penanganan DST (daylight saving time), misalnya dalam konteks Eropa ketika pada 30 Maret waktu melompat dari 2:00 ke 3:00, dan rasa ingin tahu bagaimana perilakunya dalam situasi tersebut.

• Berbagi pengalaman pernah membuat sqlite vfs bernama DonutDB yang berbasis dynamodb di masa lalu. Setelah S3 menambahkan dukungan CAS(Content Addressable Storage), sempat ingin memperbarui DonutDB menjadi versi yang mendukung S3, tetapi kali ini lightstream sudah mendukungnya sehingga tidak perlu mengembangkannya sendiri. Ada ungkapan senang dan antusias untuk memakai alat baru ini.

  • Menanggapi pernyataan bahwa S3 telah menambahkan CAS(Content Addressable Storage), ada permintaan referensi resmi atau tautan rujukan, serta rasa ingin memastikan apakah yang dimaksud dengan CAS memang benar demikian.

• Saat melakukan deployment aplikasi, sebelumnya metode yang dipakai adalah menyalakan instance server baru, lalu setelah health check lolos trafik dialihkan dan server lama dimatikan. Diingat kembali bahwa pada proses peralihan ini pernah ada masalah hilangnya perubahan database. Muncul pertanyaan apakah perubahan kali ini menyelesaikan masalah tersebut.

  • Ada pendapat bahwa server sebaiknya dipandang bukan sebagai instance web server sekali pakai, melainkan dari perspektif database produksi. Saat men-deploy web app python/sqlite, yang dilakukan bukan mengganti seluruh mesin, melainkan hanya meng-upgrade paket lalu me-restart layanan systemd. Untuk mengurangi downtime, proses peralihan bisa dipertimbangkan dengan SO_REUSEPORT dan semacamnya. Dalam situasi ini proses lama dan baru memang bisa sama-sama memakai database, tetapi jika ada perubahan skema DB, sejumlah downtime tetap tidak bisa dihindari. Pandangan ini dinilai mungkin juga berlaku untuk DB lain.

  • Ada pandangan bahwa ini tetap bukan masalah yang mudah diselesaikan. Masih hanya satu writer yang bisa memegang lease, sehingga meskipun layanan baru dijalankan, lease baru bisa diperoleh setelah writer lama berhenti. Memang ada alat untuk membantu pergantian writer, tetapi menunggu permintaan atau downtime singkat tetap tidak terhindarkan.

• Pertanyaan tentang bagaimana menambahkan database baru secara dinamis saat runtime jika ingin mereplikasi sangat banyak database per pengguna dengan litestream (use case utama yang dibahas di dokumentasi). Disebutkan bahwa saat ini file konfigurasi bersifat statis dan tidak ditemukan API real-time.

  • Ada penjelasan bahwa masalah ini kemungkinan pada akhirnya akan terselesaikan. Logika pendeteksian SQLite baru memang rumit, tetapi bukan tidak mungkin. Sementara itu, ada panduan bahwa alat ini cukup mudah digunakan dalam bentuk library.