Verifikasi Jepsen terhadap TigerBeetle 0.16.11

 (jepsen.io)
1 poin oleh GN⁺ 2025-06-07 | 1 komentar | Bagikan ke WhatsApp
  • Basis data OLTP untuk pembukuan berpasangan TigerBeetle mengedepankan keamanan dan kecepatan; Jepsen memverifikasi seri 0.16.11–0.16.30 pada klaster Debian berisi 3–6 mesin dengan injeksi kegagalan
  • Pengujian menggabungkan urutan timestamp eksplisit dengan model state machine single-thread berbasis dokumentasi untuk memeriksa Strong Serializability bersama semantik akun, transfer, dan kueri
  • Bug keamanan utama adalah hasil kueri multi-filter yang hilang dan kesalahan timestamp header pada klien Java; pada versi 0.16.26 ke atas, hasil yang konsisten dengan klaim Strong Serializability teramati bahkan dalam berbagai kombinasi kegagalan
  • Dari sisi ketersediaan, terungkap retry klien tanpa batas, crash proses saat eviction sesi, lonjakan latensi besar pada kegagalan satu node, panic server saat bit flip disk dan upgrade, serta tidak adanya jalur pemulihan untuk kehilangan disk pada satu node
  • TigerBeetle 0.16.43 telah mengakomodasi sebagian besar isu yang dilaporkan, mencakup mitigasi latensi pada kegagalan satu node dan tigerbeetle recover; operator perlu memeriksa catatan rilis saat upgrade ke 0.16.43 dan saat beralih ke 0.16.26 ke atas

Desain TigerBeetle dan cakupan pengujian

  • TigerBeetle adalah basis data OLTP untuk pembukuan berpasangan, yang hanya menyimpan akun (accounts) dan transfer (transfers), bukan baris, objek, graf, atau blob arbitrer
  • Berbasis Viewstamped Replication (VR), TigerBeetle menjanjikan konsistensi Strong Serializable, dan dirancang untuk model seperti transaksi keuangan, inventaris, ticketing, dan pengukuran utilitas
  • Untuk beban kerja dengan contention tinggi dan throughput tinggi, semua penulisan dilewatkan melalui satu core pada node VR primary, dengan fokus pada scale-up ketimbang scale-out
    • Demi performa, TigerBeetle menggunakan pemrosesan batch, paralelisasi I/O, skema tetap, serta struktur data berukuran tetap dan selaras cache
  • Model kegagalannya secara eksplisit menangani memori, proses, jam, storage, dan jaringan
    • Proses dapat berhenti atau crash
    • Jam dapat melompat maju atau mundur
    • Disk dapat mengalami bukan hanya kegagalan total, tetapi juga kerusakan penulisan parsial dan korupsi data
    • Jaringan dapat menyebabkan latensi, drop, duplikasi, salah kirim, dan kerusakan pesan
  • TigerBeetle menggunakan pengujian simulasi deterministik, dan pengujian VOPR menyimulasikan seluruh klaster beserta antarmuka jam, disk, dan jaringan

Model data dan semantik request

  • Model datanya terdiri dari dua jenis record: accounts dan transfers
    • Akun memiliki id 128-bit yang ditentukan pengguna, ledger, flags, timestamp, code, user_data_32, user_data_64, user_data_128, dan lainnya
    • Transfer adalah record immutable yang mencakup debit_account_id, credit_account_id, amount, ledger, flags, field yang ditentukan pengguna, dan lainnya
  • Transfer dapat langsung di-post dalam satu tahap, dan juga mendukung transfer dua tahap yang terbagi menjadi pending lalu post/void
    • Pending transfer mencadangkan kapasitas akun debit dan kredit
    • Setelah itu, jumlah hingga sebesar pending amount dapat di-post atau di-void
    • Field timeout mengontrol kedaluwarsa otomatis
  • Akun bersifat immutable kecuali flag closed dan empat field saldo, sementara transfer selalu immutable
    • Untuk mengubah atau membatalkan transfer, harus dibuat transfer kompensasi baru
  • Request merepresentasikan satu jenis operasi logis, dan biasanya mencakup batch hingga 8190 event
    • create_accounts dan create_transfers adalah request tulis
    • lookup_accounts, lookup_transfers, query_accounts, query_transfers, get_account_transfers, dan get_account_balances adalah request baca
  • Setiap request adalah satu transaksi dari sudut pandang basis data, tetapi sebagian event di dalam request yang sudah commit dapat gagal secara logis dan mengembalikan kode error
    • Jika diperlukan atomisitas bersyarat antar-event, gunakan chain agar semua event dalam chain yang sama berhasil semua atau gagal semua

Metode pengujian Jepsen

  • Suite pengujian Jepsen menggunakan Jepsen testing library untuk menggabungkan pengujian berbasis properti dan injeksi kegagalan
  • Target pengujian adalah TigerBeetle 0.16.11 hingga 0.16.30, termasuk beberapa build pengembangan
    • Klaster terdiri dari 3–6 node Debian
    • Dijalankan pada kontainer LXC maupun VM EC2
  • Klien resmi TigerBeetle adalah smart client yang terhubung ke semua node, sehingga dapat menyembunyikan error konkurensi
    • Jepsen juga menguji perilaku smart-client biasa
    • Pada saat yang sama, Jepsen juga menggunakan cara membatasi tiap klien ke satu node
  • Verifier bekerja dalam dua tahap
    • Membaca timestamp eksekusi dari request yang berhasil, lalu menyimpulkan timestamp untuk penulisan yang gagal atau timeout dari efek yang teramati kemudian
    • Menjalankan model state machine TigerBeetle berbasis dokumentasi sesuai urutan timestamp yang disimpulkan untuk memverifikasi hasil dan kode error
  • Model state machine ditulis dalam Clojure lebih dari 1.600 baris, mencakup map akun dan transfer, indeks, transient error, statistik internal, aliran waktu, dan lainnya
    • Model ini menangani ID duplikat, timestamp yang tidak monoton, batasan saldo, flag yang tidak kompatibel, speculative execution dan rollback pada chain, dan lainnya
    • Menggunakan library struktur data persisten berperforma tinggi Bifurcan

Injeksi kegagalan dan pengujian kerusakan file

  • Jepsen menginjeksikan SIGKILL dan SIGSTOP proses, berbagai bentuk partisi jaringan, perubahan jam dari milidetik hingga ratusan detik, serta perubahan jam bolak-balik secara cepat
  • Selama pengujian, upgrade node ke beberapa versi juga dilakukan
  • Nemesis kerusakan file baru dibuat untuk menghasilkan berbagai kegagalan storage
    • Mensimulasikan kerusakan seperti interferensi sinar kosmik dengan flip bit acak
    • Mensimulasikan misdirected write dengan mengganti chunk file dengan chunk lain
    • Mensimulasikan lost write dengan memulihkan snapshot chunk file di kemudian waktu
  • Node TigerBeetle memiliki satu file data, dan file tersebut dibagi menjadi zone pada offset yang dapat diprediksi
    • Pengujian dilakukan dengan merusak hanya zone tertentu, seperti WAL header dan salinan redundan pada superblock zone
    • Pengujian yang merusak beberapa zone atau seluruh file juga termasuk
  • Fault disk “helical” merusak file pada semua node, tetapi merusak chunk yang berbeda pada tiap node
    • Karena layout file replica terbaru TigerBeetle umumnya identik bit-for-bit, tujuannya adalah menghindari situasi ketika satu record rusak tanpa dapat dipulihkan di semua replica
    • Head WAL dapat berada di lokasi berbeda pada tiap node, sehingga menjadi pengecualian

Masalah keamanan yang ditemukan

  • Pada 0.16.13, respons query_accounts, query_transfers, dan get_account_transfers sering kehilangan sebagian atau seluruh hasil
    • Hasil yang hilang selalu berada di bagian akhir respons, dan respons merupakan prefix dari hasil yang benar
    • Tidak muncul pada kueri dengan satu filter, tetapi terjadi pada kombinasi beberapa filter seperti ledger dan code
    • Penyebabnya adalah bug bounds check pada zig-zag merge join di antara beberapa indeks
    • Dilacak melalui #2544 dan diperbaiki di 0.16.17
  • API header klien Java yang ditambahkan pada 0.16.13 untuk mendukung pengujian Jepsen mengembalikan timestamp eksekusi yang salah atau duplikat
    • Penyebabnya adalah objek respons singleton mutable Batch.EMPTY pada klien Java
    • Karena respons sukses direpresentasikan sebagai batch kosong, beberapa respons menimpa header pada objek yang sama
    • Diperbaiki melalui #2495 dan masuk ke 0.16.14
    • Tidak memengaruhi konsistensi data aktual, hanya memengaruhi timestamp permintaan pada Java client header API
  • Hasil yang diamati pada 0.16.26 ke atas konsisten dengan klaim Strong Serializability TigerBeetle
    • Properti tersebut tetap terjaga bahkan dalam kombinasi pause proses, crash, partition jaringan, error clock, korupsi disk, dan upgrade

Masalah klien dan pemrosesan permintaan

  • Dokumentasi TigerBeetle menjelaskan bahwa permintaan tidak mengalami timeout dan klien terus retry sampai menerima respons
    • Metode asinkron Java mengembalikan CompletableFuture dan dapat menggunakan API timeout seperti .get(timeout, timeUnit) atau .orTimeout(...)
    • Task pada klien .NET juga menyediakan Wait() berbasis timeout
  • Retry tanpa batas dapat menyembunyikan definite error maupun indefinite error
    • Misalnya, jika koneksi TCP gagal dengan ECONNREFUSED, permintaan asal tersebut tidak mungkin dieksekusi, sehingga ini adalah definite failure
    • Namun jika klien tidak memberi tahu pemanggil dan hanya terus melakukan retry internal, dari sudut pandang pemanggil hal itu menjadi indefinite failure seperti timeout atau penghentian
  • Masalah ini sedang dibahas di #206 dan, berdasarkan laporan, masih unresolved
    • Jepsen merekomendasikan agar definite error dan indefinite error direpresentasikan sebagai entitas kelas satu dan dikembalikan kepada pemanggil
    • Retry otomatis boleh dipertahankan, tetapi harus dapat dikonfigurasi, serta disarankan menyediakan opsi untuk batas maksimum waktu memulai koneksi dan menunggu respons
  • Klien Java 0.16.11 mengalami masalah: saat thread panggilan sinkron di-interrupt untuk menangani timeout, atau saat client ditutup setelah panggilan asinkron, seluruh JVM mengalami segfault
    • Penyebabnya adalah field yang belum disetel pada request data structure
    • Jika klien ditutup di antara pembuatan dan pengiriman request, alamat default Zig 0xaaa... akan di-dereference
    • Diperbaiki melalui #2435 dan masuk ke 0.16.12
  • Klien resmi membuat seluruh proses crash ketika server memberi tahu adanya session eviction
    • TigerBeetle secara default membatasi concurrent session menjadi 64
    • Eviction juga terjadi saat menggunakan versi klien yang lebih baru daripada server
    • Setelah #2484, mulai 0.16.13, saat eviction terjadi klien mengembalikan error kepada pemanggil alih-alih membuat proses crash

Lonjakan latensi saat kegagalan satu node

  • Pada kegagalan satu node, berulang kali terlihat kasus client latency meningkat hingga 3–5 digit
    • Dalam cluster 5 node, jika satu node dimatikan, minimum latency naik dari kurang dari 1 ms menjadi 10 detik
    • Dalam pengujian cluster 3 node dengan satu node dimatikan, latency yang sebelumnya 1–50 ms meningkat hingga sekitar 100 detik per permintaan, dan bertahan hampir 1000 detik sampai node direstart
  • Penyebabnya terkait dengan cara propagasi prepare di TigerBeetle
    • Dalam VR tradisional, primary mengirim prepare ke semua secondary dan menerima ack secara langsung
    • TigerBeetle menempatkan node dalam ring; saat primary mengirim prepare ke secondary berikutnya, tiap secondary meneruskannya ke node berikutnya
    • Pendekatan ini mengurangi kebutuhan bandwidth satu node, tetapi jika salah satu dari f replica berikutnya dalam ring gagal, commit bisa terblokir
  • Masalah ini dilacak melalui #2739
  • 0.16.30 memitigasinya dengan mengirim separuh pesan prepare ke arah berlawanan dalam ring
    • Sebagian prepare dapat melewati node yang bermasalah
    • Dalam pengujian Jepsen, latency sekitar 100 detik turun menjadi kisaran 1–30 detik
  • 0.16.43 mencakup peningkatan performa tambahan
    • Node melakukan replicate ke dua arah ring
    • Ring topology berubah secara dinamis, dan cluster menyesuaikan urutan node sesuai kondisi jaringan dan kegagalan

Korupsi disk dan crash server

  • Pada 0.16.20, korupsi satu bit pada superblock, WAL, atau grid zone kadang menyebabkan crash saat startup
    • Log mencetak panic: reached unreachable code lalu keluar
    • Penyebabnya adalah bug pemeriksaan sector padding
  • Checksum TigerBeetle mencakup data chunk tetapi mengecualikan padding
    • Jika bit 0 pada padding berubah menjadi 1, checksum tetap lolos
    • Setelah itu, assertion yang memeriksa bahwa padding masih 0 gagal, sehingga server crash
    • Korupsi padding tidak merusak safety, dan dapat dikembalikan menjadi 0 atau dipulihkan dari replica lain
  • VOPR sebelumnya tidak menemukan bug ini karena merusak seluruh sector
    • Korupsi sector memicu kegagalan checksum dan jalur repair, sehingga tidak mencapai assertion padding
    • TigerBeetle menambahkan single-byte error ke VOPR di #2681
    • Mulai 0.16.26, sector dengan korupsi padding diperbaiki alih-alih menyebabkan crash
  • Bit flip pada copy number superblock juga dapat menyebabkan panic yang sama
    • Empat salinan superblock masing-masing memiliki nomor copy 2 byte yang berbeda, dan checksum melewati nomor ini
    • Setelah copy number yang rusak di disk dibaca ke memori, assertion rentang 0–3 gagal saat write
    • Diselesaikan di 0.16.26 dengan cara me-reset copy number

Masalah terkait upgrade

  • Saat melakukan upgrade dari 0.16.25 atau lebih rendah ke 0.16.26 atau lebih tinggi, crash panic: checkpoint diverged berulang kali teramati
    • Penyebabnya adalah perubahan struktur CheckpointState pada 0.16.26
    • Versi baru menyertakan himpunan released blocks, tetapi informasi ini bisa kosong dalam proses pengiriman state yang kompatibel dengan versi lama
    • Setelah itu, jika node direstart sebagai 0.16.26, node tersebut bisa berada dalam keadaan kehilangan released blocks yang diketahui replica lain
    • Assertion mendeteksi divergence dan crash, sehingga klien tidak sampai mengamati data yang tidak konsisten
  • Masalah ini didokumentasikan di changelog melalui #2745
    • TigerBeetle tidak merilis 0.16.26 yang sudah dipatch
    • Operator harus menghentikan client dan menunggu replica catch-up sebelum melakukan upgrade ke 0.16.26 atau lebih tinggi
  • Saat melakukan beberapa upgrade dari 0.16.16 ke 0.16.28 secara beruntun dalam sekitar 20 detik, atau saat node mengalami pause/crash selama upgrade, terjadi kegagalan assertion release_transition
    • Node yang sedang berjalan membuka binary baru dengan memfd dan menggantinya lewat exec(), tetapi di sela-sela itu binary di disk bisa diganti dengan versi yang lebih baru
    • Kode gagal karena melakukan assert bahwa version header di disk juga sama dengan versi yang sedang berjalan
    • Melalui #2758, assertion diubah menjadi warning pada 0.16.29
  • Saat upgrade dari 0.16.26 ke 0.16.27, panic: switch on corrupt value terjadi karena deprecated message type
    • Pernyataan switch pada node baru tidak memiliki case untuk tipe pesan lama, sehingga crash
    • Melalui #2763, pada 0.16.29 deprecated message type kembali dimasukkan ke case dan diperbaiki agar diabaikan

Pemulihan kehilangan disk pada satu node

  • TigerBeetle tangguh terhadap kerusakan file, tetapi seluruh file data sebuah node bisa hilang atau rusak hingga tidak dapat dipulihkan karena kegagalan disk, kebakaran, error EBS volume, kesalahan operator, dan sebagainya
  • Pada saat laporan, dokumentasi belum memiliki cara mengganti node yang gagal, dan ada prosedur recovery yang tidak terdokumentasi berupa menjalankan tigerbeetle format untuk menginisialisasi file data kosong lalu berharap repair berjalan
  • Jepsen memastikan bahwa reformat umumnya berfungsi, tetapi bisa tidak aman
    • Jika 2 dari 3 node memiliki committed operation op dan salah satunya di-reformat, majority 2/3 yang tidak mengamati op dapat melakukan view change sehingga operation tersebut hilang
    • Dalam pengujian nyata, ada run yang kehilangan 5 acknowledged transfer
    • Saat upgrade, ada juga kasus node yang diformat dengan binary lebih baru mengalami startup crash sebelum menyelesaikan cluster version transition
  • Masalah ini dilacak melalui #2767
  • Setelah itu, TigerBeetle 0.16.43 menyertakan perintah tigerbeetle recover untuk memulihkan node yang mengalami catastrophic data loss

Kesimpulan dan rekomendasi Jepsen

  • Ada dua masalah keselamatan yang ditemukan
    • Hasil kueri multi-filter sebelum 0.16.17 yang hilang
    • Timestamp yang salah dan duplikat pada API debugging client Java untuk pengujian Jepsen
  • Total ada 7 masalah crash
    • 2 pada client Java: uninitialized memory access, crash proses saat eviction
    • 5 pada server: 2 panic terkait kerusakan disk, 3 panic terkait upgrade
    • #2745 didokumentasikan, dan crash lainnya diselesaikan hingga 0.16.29
  • 0.16.43 menyelesaikan semua isu dalam laporan kecuali satu
    • Item yang belum terselesaikan adalah masalah client request yang menurut desain terus di-retry
  • Rekomendasi untuk pengguna jelas
    • Upgrade ke 0.16.43
    • Periksa release note saat berpindah ke 0.16.26 atau versi setelahnya
    • Simulasikan kegagalan satu node di lingkungan pengujian dan ukur bagaimana aplikasi merespons latency yang meningkat
  • Arsitektur TigerBeetle tampak sound, dan integrasi VR, flexible quorum, serta protocol-aware recovery teramati tidak merusak invariant inti Strong Serializability
  • Namun, verifikasi Jepsen adalah pendekatan eksperimental, sehingga dapat membuktikan keberadaan bug, tetapi tidak dapat membuktikan ketiadaannya

Bacaan terkait

1 komentar

 
GN⁺ 2025-06-07
Komentar Hacker News

  • Bacaan terkait: Fuzzer Blind Spots (Meet Jepsen!) – https://tigerbeetle.com/blog/2025-06-06-fuzzer-blind-spots-m...

  • Laporan ini benar-benar mengesankan. Setiap kali melihat klaim keandalan dan skalabilitas TigerBeetle, saya selalu berpikir, “baiklah, kita tunggu laporan Jepsen”
    Laporan itu memang menemukan beberapa isu dan bisa saja membuat khawatir, tetapi yang positif adalah mereka tidak berhenti hanya dengan memperbaikinya; mereka juga memperluas kumpulan pengujian internal agar bug serupa bisa tertangkap di masa depan. Dengan pendekatan engineering seperti ini, dalam 10 tahun TigerBeetle tampaknya bisa menjadi database default di ceruk aplikasi finansial, setara dengan “pakai Postgres saja”
    Pekerjaan aphyr juga luar biasa, dan rasanya saya banyak belajar saat membaca laporannya

    • TigerBeetle memiliki lebih dari 6.000 assertion, dan sebagian di antaranya begitu ketat sampai menyebabkan crash, tetapi assertion itu menjalankan perannya: memberi sinyal bahwa mental model perlu disesuaikan, dan memang kemudian disesuaikan
      Selain itu, kecuali bug kecil pada ketepatan fitur pengujian internal yang hanya dimasukkan ke klien Java untuk membantu audit Jepsen, hanya ada satu bug correctness yang ditemukan Jepsen, dan itu tidak memengaruhi durabilitas. Tulisan terkait ada di sini: https://tigerbeetle.com/blog/2025-06-06-fuzzer-blind-spots-m...
      Secara adil, TigerBeetle dirancang dan diuji untuk menahan lebih banyak kegagalan daripada Postgres. Alasannya, ia memiliki model kegagalan storage yang eksplisit dan memanfaatkan riset yang belum ada ketika Postgres keluar pada 1996. Model kegagalan TB divalidasi lebih lanjut dengan pengujian simulasi deterministik, serta menggunakan teknik seperti alokasi memori statis sesuai Power of Ten Rules NASA untuk Safety-Critical Code. Dalam literatur ada skenario yang diketahui membuat Postgres kehilangan data, tetapi TigerBeetle dapat mendeteksi dan memulihkannya
      Untuk melihat lebih jauh, baca bagian helical fault injection dalam laporan Kyle. Kebanyakan implementasi Raft dan Paxos tidak dirancang untuk menahannya, dan ada juga presentasi QCon London: https://m.youtube.com/watch?v=_jfOk4L7CiY
    • Tulisan Kyle selalu saya nantikan. Setiap kali ada tulisan baru, rasanya pengetahuan sistem terdistribusi naik satu tingkat

  • Senang sekali melihat hasil verifikasi aphyr menunjukkan TigerBeetle sesuai dengan klaimnya sendiri. Menyenangkan melihat bahwa memilih pendekatan yang benar menghasilkan hasil yang benar
    Saya penasaran bagaimana TigerBeetle akan dipakai dalam praktik. Untuk semua hal selain Account atau Transfer, kemungkinan akan ada banyak sistem eksternal dan database lain di sekitar instalasi TigerBeetle; saya ingin tahu pola umum seperti apa yang dipakai agar sistem-sistem yang kurang andal itu tetap selaras dengan TigerBeetle, terutama bagaimana pemulihan dilakukan ketika muncul masalah konsistensi di antara keduanya

    • Pola umum saat mengintegrasikan TigerBeetle adalah memisahkan control plane dan data plane. Postgres dipakai untuk tujuan umum atau OLGP, sedangkan TigerBeetle dipakai untuk pemrosesan transaksi atau OLTP
      Informasi pengguna (nama, alamat, kata sandi, dll.) dan informasi produk (deskripsi, harga, dll.) dimasukkan ke OLGP sebagai “lemari arsip”
      Lalu pada Black Friday, semua transaksi ketika pengguna memindahkan barang dari akun inventaris ke akun keranjang, lalu ke akun pembayaran dan pengiriman, dimasukkan ke OLTP sebagai “brankas”. TigerBeetle memungkinkan penyimpanan hingga 3 identifier data pengguna untuk setiap akun atau transfer, sehingga event antar-entitas dapat dikaitkan dengan database OLGP yang mendeskripsikan entitas tersebut
      Arsitektur ini [1] memberikan pemisahan tanggung jawab yang rapi, sehingga workload yang berbeda dapat diskalakan dan dikelola secara independen. Jika Anda bank, lebih masuk akal menyimpan uang tunai di brankas, karena karakteristik performa, kepatuhan regulasi, dan retensinya berbeda, daripada menyimpan seluruh uang tunai di lemari arsip yang berisi catatan nasabah
      Pola ini cocok karena frekuensi pengguna mengganti nama atau alamat email (OLGP) jauh lebih rendah daripada frekuensi mereka bertransaksi (OLTP)
      Untuk menjaga konsistensi, pada jalur tulis, perlakukan TigerBeetle sebagai data plane OLTP sekaligus “sumber kebenaran”. Ketika transaksi “pindahkan ke keranjang” atau “pembayaran” masuk, tulis terlebih dahulu dependensi data yang diperlukan ke OLGP, tulis juga data blob terkait ke tempat seperti S3 bila ada, lalu terakhir tulis ke TigerBeetle untuk melakukan commit transaksi. Pada jalur baca, query terlebih dahulu sumber kebenaran untuk mempertahankan serializability yang ketat
      [1] https://docs.tigerbeetle.com/coding/system-architecture/

  • Setelah membaca tulisan TigerBeetle tentang blind spot fuzzer, laporan Jepsen ini terasa sangat menarik
    Segfault di sisi JNI tampaknya tidak akan bisa dicegah sekalipun menggunakan Rust atau bahasa lain yang memory-safe. Fakta bahwa hampir tidak ada bug memory safety terlihat sebagai bukti bahwa pendekatan pemrograman Zig TigerBeetle, kalau tidak salah disebut TigerStyle, cukup berhasil menjalankan peran yang dimaksudkan

    • Lihat https://news.ycombinator.com/item?id=44201189. Memang ada satu bug yang mungkin akan terselamatkan jika menggunakan Rust. Sebagai gantinya, assertion yang menyelamatkan, jadi baconnya hanya sedikit renyah, tidak sampai gosong
      Tetap saja benar. Tanpa TigerStyle, mereka akan kena nasal demons

  • Saya suka laporan yang luar biasa rinci ini. Fakta bahwa Jepsen telah menguji dan menandatanganinya merupakan jaminan yang sangat besar bagi TigerBeetle. Padahal belum mencapai v1.0, jadi saya menantikan tonggak baru berikutnya
    Apresiasi khusus juga untuk para pendiri yang berbagi wawasan bagus di thread ini

    • Kyle melakukan pekerjaan yang luar biasa, dan detail dalam laporannya juga benar-benar bagus. Sepanjang membaca, saya sampai berpikir “ini seperti karya seni”, karena terasa sekali craftsmanship dan presisinya
      Saya juga menantikan hal baru yang akan segera dibagikan dalam presentasi SD25 di Amsterdam

  • Saya cukup menyukai judul bagian “Panic! At the Disk 0”, meski hanya detail kecil

  • Menarik, meski kalau dipikir belakangan terasa jelas, bahwa sistem terdistribusi yang diuji perlu melaporkan waktu dan urutan kejadian yang benar-benar terjadi agar bisa diverifikasi secara tepat terhadap model eksternal sistem, alih-alih memakai waktu wall-clock

    • Ini bekerja karena ada strict serializability. Dengan jaminan konsistensi yang lebih lemah, belum tentu ada satu timeline global yang konsisten
      Ini pola meta yang menarik: ketika kita berhasil melakukan sesuatu yang lebih sulit, sistem justru menjadi lebih sederhana
      Contoh lain: karena kita mengasumsikan disk bisa gagal dan harus menyertakan protokol pemulihan, sinkronisasi status replika yang tertinggal pada dasarnya didapat “gratis”. Sebab masalahnya persis sama dengan kondisi seluruh disk rusak
    • Menurut saya ini pendekatan klasik. Contoh: https://lamport.azurewebsites.net/pubs/time-clocks.pdf

  • Sayangnya, tautan di artikel ke makalah “Viewstamped Replication” rusak. https://pmg.csail.mit.edu/papers/vr-revisited.pdf menolak koneksi
    Mungkin skemanya seharusnya http, bukan https, seperti http://pmg.csail.mit.edu/papers/vr-revisited.pdf
    Sekarang saya punya bahan bacaan untuk Jumat malam

    • Akan segera diperbaiki
      Makalah VSR 2012 adalah salah satu makalah favorit saya, dan “Protocol-Aware Recovery for Consensus-Based Storage” juga benar-benar kuat
      Semoga senang membacanya

  • Ini pertanyaan murni karena ingin belajar, dan semoga tidak disalahpahami. Saya masih baru mempelajari sistem terdistribusi dan sangat tertarik pada deterministic simulation testing
    Setelah melihat sekilas laporan Jepsen tentang TigerBeetle, tulisan blog terkait, dan kode integrasi Antithesis di workflow GitHub, saya ingin memahami cakupan pengujiannya dengan lebih baik
    Pertanyaan intinya adalah apakah integrasi Antithesis juga bisa menemukan bug-bug yang ditemukan oleh rangkaian tes Jepsen ini
    Pertanyaan ini muncul dari beberapa asumsi yang mungkin keliru. Saya mengira TigerBeetle sudah diuji secara menyeluruh dengan rangkaian tes internal dan produk Antithesis, dan saya memahami rangkaian tes Antithesis lebih kuat daripada Jepsen, sehingga cukup mengejutkan bahwa Jepsen menemukan masalah yang tidak ditemukan Antithesis
    Saya ingin tahu apakah pemahaman saya salah. Misalnya, saya ingin tahu apakah 1) rangkaian tes Antithesis tidak bisa mendeteksi kelas bug spesifik ini, 2) bagian sistem ini belum tercakup oleh tes Antithesis, atau 3) saya sedang membandingkan apel dan jeruk karena salah memahami kekuatan dan tujuan berbeda dari rangkaian tes Jepsen dan Antithesis

    • Di tulisan blog TigerBeetle ada penjelasan lebih rinci, tetapi singkatnya, tes yang berjalan di Antithesis memang cukup menyeluruh, namun tidak berhasil membuat kombinasi tepat antara query yang saling beririsan dan nilai yang urutannya tertukar, sementara generator Jepsen berhasil mengenainya
      Generator tes Jepsen juga hampir pasti punya blind spot. Itulah sebabnya merancang generator yang berbeda-beda membantu
    • Pengujian generatif untuk sistem terdistribusi biasanya membutuhkan tiga komponen. Pertama, diperlukan lingkungan untuk menjalankan sistem. Yang paling sederhana adalah menyalakan cluster mesin nyata, tetapi jika ingin meningkatkan performa, kontrol respons API eksternal, determinisme, dan reproduksibilitas, sesuatu yang lebih canggih lebih baik. Kedua, diperlukan generator beban yang membuat sistem di dalam lingkungan tersebut melakukan hal-hal menarik. Ketiga, diperlukan auditor yang mengamati perilaku sistem saat diberi beban dan menilai apakah sesuai spesifikasi
      Antithesis terutama menangani masalah nomor 1, dengan menyediakan lingkungan simulasi deterministik berbasis mesin virtual. Jepsen menangani masalah yang sama dengan memakai mesin nyata tetapi menyuntikkan kegagalan di tingkat sistem operasi, sementara VOPR milik TigerBeetle sendiri dirancang bersama databasenya sehingga seluruh cluster bisa dijalankan dalam satu thread. Ketiga pendekatan ini saling melengkapi dan masing-masing punya area keunggulan yang berbeda
      Bagian yang menentukan dalam bug ini adalah nomor 2 dan 3, yakni menulis validator workload dan auditor yang benar-benar bisa memicu bug tersebut. Di sini, 1.600 baris kode Clojure khusus TigerBeetle yang ditulis aphyr berhasil memicu dan mendeteksi bug, dan setelah itu tes ekuivalen dari pihak TigerBeetle juga di-patch agar bisa memicunya. Sebenarnya, yang bermasalah di sini bukan database melainkan VOPR. Adanya bug di database adalah hal yang wajar, dan bug tidak bisa dihindari hanya dengan niat. Karena itu diperlukan strategi pengujian yang bisa memicu sebagian besar bug, dan bug yang lolos menunjukkan kekurangan pada generator workload
    • 90% dari deterministic simulation testing terutama dilakukan oleh simulator deterministik buatan TigerBeetle sendiri, VOPR. Itu berjalan 24/7 pada skala 1.000 core CPU khusus
      Antithesis juga digunakan, tetapi sebagai lapisan kedua untuk deterministic simulation testing
      Alasan bug query engine bisa lolos dapat dilihat di sini: https://tigerbeetle.com/blog/2025-06-06-fuzzer-blind-spots-m...

  • Penasaran apakah bank besar atau bursa efek menggunakan TigerBeetle

    • Di tingkat negara, bersama Gates Foundation, TigerBeetle sedang diintegrasikan ke switch bank sentral nirlaba, dan sistem ini dijadwalkan menjalankan National Digital Payments System 2.0 milik Rwanda pada akhir tahun ini [1]
      Di tingkat perusahaan, TigerBeetle sudah digunakan di produksi oleh pelanggan yang memproses lebih dari 100 juta transaksi per bulan, baru-baru ini menandatangani kontrak pertama dengan unicorn fintech Eropa senilai 2 miliar dolar, dan beberapa kontrak di AS juga akan segera rampung. Karena tren global menuju pemrosesan transaksi real-time [2], cukup banyak perusahaan yang tertarik pindah ke TigerBeetle demi performa yang lebih tinggi
      Untuk menjawab pertanyaannya, beberapa pendiri Clear Street, broker yang cukup besar di Wall Street, telah berinvestasi [3] di TigerBeetle
      [1] https://mojaloop.io/how-mojaloop-enables-rndps-2-0-ekash/
      [2] https://tigerbeetle.com/blog/2024-07-23-rediscovering-transa...
      [3] https://tigerbeetle.com/company
    • Bukan bank atau bursa, tetapi saya bekerja di perusahaan fintech yang sangat besar dan kami menggunakan TigerBeetle untuk produk baru
    • Kalau ada pelanggan seperti itu, rasanya mereka pasti sudah memamerkannya di beranda. Sejauh ini, dukungan terbesar di beranda berasal dari seorang YouTuber. Memang YouTuber populer, tapi tetap saja YouTuber