Jepsen’in TigerBeetle 0.16.11 doğrulaması

 (jepsen.io)
1 puan yazan GN⁺ 2025-06-07 | 1 yorum | WhatsApp'ta paylaş
  • Çift taraflı muhasebe için OLTP veritabanı TigerBeetle, güvenlik ve hızı öne çıkarıyor; Jepsen, 0.16.11~0.16.30 serisini 3~6 makinelik Debian kümelerinde hata enjeksiyonuyla birlikte doğruladı
  • Testler, açık zaman damgası sıralaması ile dokümantasyon tabanlı tek iş parçacıklı durum makinesi modelini birleştirerek Strong Serializability ile hesap, transfer ve sorgu semantiklerini birlikte kontrol etti
  • Başlıca güvenlik hataları, çoklu filtre sorgu sonuçlarında eksik kayıtlar ve Java istemcisinde header zaman damgası hatasıydı; 0.16.26 ve sonrasında çeşitli hata kombinasyonlarında da Strong Serializability iddiasıyla uyumlu sonuçlar gözlemlendi
  • Kullanılabilirlik tarafında istemcinin sonsuz yeniden denemesi, oturum eviction sırasında süreç çökmesi, tek düğüm arızasında gecikmenin keskin artması, disk bit flip’i ve yükseltme sırasında sunucu panic’i, tek düğüm disk kaybı için kurtarma yolunun olmaması ortaya çıktı
  • TigerBeetle 0.16.43, bildirilen sorunların çoğunu yansıtarak tek düğüm arızası gecikmesini azaltmayı ve tigerbeetle recover komutunu içeriyor; operatörlerin 0.16.43’e yükseltme ve 0.16.26+ sürümlerine geçiş sırasında sürüm notlarını kontrol etmesi gerekiyor

TigerBeetle’ın tasarımı ve test kapsamı

  • TigerBeetle, çift taraflı muhasebe için bir OLTP veritabanıdır; keyfi satırlar, nesneler, graflar veya blob’lar yerine yalnızca hesapları (accounts) ve transferleri (transfers) saklar
  • Viewstamped Replication (VR) temelinde Strong Serializable tutarlılık sağlama sözü verir ve finansal işlemler, envanter, biletleme, kamu hizmeti ölçümü gibi modellere uygun olarak tasarlanmıştır
  • Yüksek çekişmeli ve yüksek işlem hacimli iş yükleri için tüm yazmaları birincil VR düğümünün tek çekirdeğinden geçirir; scale-out yerine scale-up yaklaşımına odaklanır
    • Performans için toplu işleme, I/O paralelleştirme, sabit şema ve sabit boyutlu, cache hizalı veri yapıları kullanır
  • Hata modeli bellek, süreç, saat, depolama ve ağı açıkça ele alır
    • Süreçler durabilir veya çökebilir
    • Saatler ileri ya da geri sıçrayabilir
    • Diskler yalnızca tamamen arızalanmakla kalmaz, kısmi yazma bozulması ve veri kirlenmesi de yaşayabilir
    • Ağ gecikme, paket düşürme, çoğaltma, yanlış teslimat ve mesaj bozulmasına yol açabilir
  • TigerBeetle deterministik simülasyon testi kullanır; VOPR testi tüm kümeyi ve saat, disk, ağ arayüzlerini simüle eder

Veri modeli ve istek semantiği

  • Veri modeli iki tür kayıttan oluşur: accounts ve transfers
    • Hesap; kullanıcı tanımlı 128 bit id, ledger, flags, timestamp, code, user_data_32, user_data_64, user_data_128 vb. alanlara sahiptir
    • Transfer; debit_account_id, credit_account_id, amount, ledger, flags, kullanıcı tanımlı alanlar vb. içeren değişmez bir kayıttır
  • Transfer tek adımda anında post edilebilir; pending ve post/void olarak ayrılan 2 aşamalı transfer de mümkündür
    • Pending transfer, debit ve credit hesaplarının kapasitesini rezerve eder
    • Daha sonra pending amount değerine kadar post edilebilir veya void edilebilir
    • timeout alanı otomatik süre dolumunu kontrol eder
  • Hesaplar, closed bayrağı ve dört bakiye alanı dışında değişmezdir; transferler ise her zaman değişmezdir
    • Bir transferi değiştirmek veya geri almak için yeni bir dengeleme transferi oluşturmak gerekir
  • İstekler tek bir mantıksal işlem türünü temsil eder ve genellikle en fazla 8190 event içeren bir batch barındırır
    • create_accounts, create_transfers yazma istekleridir
    • lookup_accounts, lookup_transfers, query_accounts, query_transfers, get_account_transfers, get_account_balances okuma istekleridir
  • Her istek veritabanı açısından tek bir transaction’dır; ancak commit edilmiş bir istekteki bazı event’ler mantıksal olarak başarısız olup hata kodu döndürebilir
    • Event’ler arasında koşullu atomiklik gerekiyorsa, aynı chain içindeki event’lerin ya tamamının başarılı ya da tamamının başarısız olması için chain kullanılır

Jepsen test yöntemi

  • Jepsen test paketi, Jepsen testing library kullanarak özellik tabanlı testleri hata enjeksiyonuyla birleştirir
  • Test hedefi TigerBeetle 0.16.11’den 0.16.30’a kadar olan sürümlerdir; çeşitli geliştirme build’leri de dahildir
    • Küme 3~6 Debian düğümünden oluşur
    • Hem LXC container’larında hem de EC2 VM’lerinde çalıştırılmıştır
  • TigerBeetle’ın resmi istemcisi tüm düğümlere bağlanan bir smart client olduğu için eşzamanlılık hatalarını gizleyebilir
    • Jepsen normal smart-client davranışını da test eder
    • Aynı zamanda her istemciyi tek bir düğümle sınırlayan bir yöntem de kullanır
  • Doğrulayıcı iki aşamada çalışır
    • Başarılı isteklerin yürütme zaman damgalarını okur; başarısız veya timeout’a düşen yazmalar için zaman damgasını daha sonra gözlemlenen etkilerden çıkarır
    • Çıkarılan zaman damgası sırasına göre dokümantasyon tabanlı TigerBeetle durum makinesi modelini çalıştırarak sonuçları ve hata kodlarını doğrular
  • Durum makinesi modeli 1.600 satırdan fazla Clojure ile yazılmıştır; hesap ve transfer map’leri, indeksler, transient error’lar, iç istatistikler, saat akışı vb. içerir
    • Yinelenen ID’leri, monoton olmayan zaman damgalarını, bakiye kısıtlarını, uyumsuz bayrakları, chain’in speculative execution ve rollback davranışlarını işler
    • Yüksek performanslı kalıcı veri yapısı kütüphanesi Bifurcan kullanılır

Hata enjeksiyonu ve dosya bozulması testi

  • Jepsen süreçlere SIGKILL, SIGSTOP, çeşitli ağ bölünmesi biçimleri, milisaniyelerden yüzlerce saniyeye kadar saat değişiklikleri ve hızlı ileri-geri saat değişimleri enjekte etti
  • Test sırasında birden fazla sürüme düğüm yükseltmeleri de yapıldı
  • Yeni dosya bozulması nemesis’iyle çeşitli depolama hataları oluşturuldu
    • Rastgele bit flip ile kozmik ışın etkisi benzeri bozulmalar simüle edildi
    • Yanlış yönlendirilmiş yazmayı simüle etmek için dosya chunk’ları başka chunk’larla değiştirildi
    • Kayıp yazmayı simüle etmek için dosya chunk snapshot’ları daha sonra geri yüklendi
  • TigerBeetle düğümlerinin tek bir veri dosyası vardır; dosya, öngörülebilir offset’lerdeki zone’lara ayrılır
    • WAL header, superblock zone’daki yinelenen copy’ler gibi yalnızca belirli zone’ları bozan testler yapıldı
    • Birden fazla zone’u veya tüm dosyayı bozan testler de dahil edildi
  • “helical” disk hatası, tüm düğümlerdeki dosyaları bozarken her düğümde farklı bir chunk’ı bozan bir yöntemdir
    • TigerBeetle’ın güncel replica dosya yerleşimi genellikle bit-for-bit aynı olduğundan, tek bir kaydın tüm replica’larda kurtarılamaz biçimde bozulduğu durumdan kaçınmayı amaçlar
    • WAL’in head’i düğüme göre farklı konumda olabildiği için istisna oluşturur

Bulunan güvenlik sorunları

  • 0.16.13’te query_accounts, query_transfers, get_account_transfers yanıtlarının bazı ya da tüm sonuçları atlaması sık sık görüldü
    • Atlanan sonuçlar her zaman yanıtın son kısmındaydı ve yanıt, doğru sonuçların bir prefix’iydi
    • Tek filtreli sorgularda görülmedi; ledger ve code gibi çoklu filtre kombinasyonlarında ortaya çıktı
    • Nedeni, birden çok indeks arasındaki zig-zag merge join işleminde bounds check hatasıydı
    • #2544 ile izlendi ve 0.16.17’de düzeltildi
  • Jepsen testlerini desteklemek için 0.16.13’e eklenen Java istemcisi header API’si hatalı veya yinelenen yürütme zaman damgaları döndürüyordu
    • Nedeni, Java istemcisindeki mutable singleton yanıt nesnesi Batch.EMPTY idi
    • Başarılı yanıt boş batch olarak temsil edildiğinden, birden çok yanıt aynı nesnenin header’ının üzerine yazıyordu
    • #2495 ile düzeltildi ve 0.16.14’e dahil edildi
    • Gerçek veri tutarlılığını etkilemez; yalnızca Java istemcisi header API’sindeki istek zaman damgalarını etkiler
  • 0.16.26 ve sonrasında gözlemlenen sonuçlar, TigerBeetle’ın Strong Serializability iddiasıyla uyumludur
    • Process pause, crash, ağ partition, clock error, disk corruption ve upgrade kombinasyonlarında da bu özellik korunur

İstemci ve istek işleme sorunları

  • TigerBeetle dokümantasyonu, isteklerin timeout’a düşmediğini ve istemcinin yanıt alana kadar retry etmeye devam ettiğini açıklar
    • Java asenkron metodu CompletableFuture döndürür ve .get(timeout, timeUnit) veya .orTimeout(...) gibi timeout API’leri kullanılabilir
    • .NET istemcisinin Task yapısı da timeout tabanlı Wait() sağlar
  • Sonsuz retry, hem definite error hem de indefinite error durumlarını gizleyebilir
    • Örneğin TCP bağlantısı ECONNREFUSED ile başarısız olursa, ilgili ilk isteğin yürütülemeyeceği anlamına gelen definite failure’dır
    • Ancak istemci bunu çağırana bildirmeyip yalnızca içeride retry etmeye devam ederse, çağıran açısından timeout veya kesinti gibi indefinite failure’a dönüşür
  • Bu sorun #206 içinde tartışılıyor ve rapor tarihi itibarıyla çözülmemiş durumda
    • Jepsen, definite error ve indefinite error durumlarının birinci sınıf kavramlar olarak ifade edilip çağırana döndürülmesini önerir
    • Otomatik retry korunabilir, ancak yapılandırılabilir olmalı; bağlantı başlatma ve yanıt bekleme için azami sürelerin seçenek olarak sunulması önerilir
  • 0.16.11 Java istemcisinde, timeout işlemek için senkron çağrı thread’ini interrupt etmek veya asenkron çağrıdan sonra client’ı close etmek tüm JVM’in segfault ile çökmesine yol açabiliyordu
    • Nedeni, request data structure içinde unset field bulunmasıydı
    • İstemci, request oluşturma ile gönderme arasında kapatılırsa Zig’in varsayılan 0xaaa... adresi dereference ediliyordu
    • #2435 ile düzeltildi ve 0.16.12’ye dahil edildi
  • Resmî istemciler, sunucu session eviction bildirdiğinde tüm process’i crash ettiriyordu
    • TigerBeetle varsayılan olarak concurrent session sayısını 64 ile sınırlar
    • Sunucudan daha yeni bir istemci sürümü kullanıldığında da eviction gerçekleşir
    • #2484 sonrasında, 0.16.13’ten itibaren eviction durumunda process crash yerine çağırana error döndürülür

Tek düğüm arızasında gecikmenin keskin artması

  • Tek düğüm arızalarında client latency’nin 3–5 basamağa kadar arttığı örnekler tekrarlandı
    • 5 düğümlü bir kümede tek düğüm öldürüldüğünde minimum latency 1 ms’nin altından 10 saniyeye çıktı
    • 3 düğümlü kümede bir düğümün öldürüldüğü testte 1–50 ms olan latency istek başına yaklaşık 100 saniyeye kadar yükseldi ve düğüm yeniden başlatılana kadar neredeyse 1000 saniye sürdü
  • Neden, TigerBeetle’ın prepare yayma yöntemiyle ilgilidir
    • Geleneksel VR’de primary tüm secondary’lere prepare gönderir ve ack’leri doğrudan alır
    • TigerBeetle düğümleri ring olarak yerleştirir; primary bir sonraki secondary’ye prepare gönderdiğinde her secondary bunu sonraki düğüme iletir
    • Bu yöntem tek bir düğümün bandwidth gereksinimini azaltır, ancak ring’deki sonraki f replica’dan biri başarısız olursa commit engellenebilir
  • Bu sorun #2739 ile izleniyor
  • 0.16.30, prepare mesajlarının yarısını ring’in ters yönüne göndererek bunu hafifletti
    • Bazı prepare mesajları arızalı düğümün etrafından dolaşabilir
    • Jepsen testlerinde 100 saniyeler düzeyindeki latency 1–30 saniye seviyesine düştü
  • 0.16.43 ek performans iyileştirmeleri içerir
    • Düğümler ring’in iki yönünde de replicate eder
    • Ring topology dinamik olarak değişir; küme, ağ koşullarına ve arızalara göre düğüm sırasını ayarlar

Disk bozulması ve sunucu crash’i

  • 0.16.20’de superblock, WAL ve grid zone’da tek bitlik bozulmanın startup crash’e yol açtığı durumlar vardı
    • Loglar panic: reached unreachable code çıktısını verip kapanıyordu
    • Nedeni, sector padding kontrolündeki hataydı
  • TigerBeetle checksum, chunk’ın verisini kapsar ancak padding’i hariç tutar
    • Padding’deki 0 bit 1’e dönerse checksum geçer
    • Daha sonra padding’in hâlâ 0 olup olmadığını kontrol eden assertion başarısız olur ve sunucu crash eder
    • Padding bozulması safety’yi zedelemez; tekrar 0 yapılabilir veya başka bir replica’dan onarılabilir
  • VOPR daha önce sector’ün tamamını bozduğu için bu hatayı bulamadı
    • Sector bozulması checksum başarısızlığına ve repair yoluna neden oluyor, padding assertion’a kadar ulaşmıyordu
    • TigerBeetle, #2681 kapsamında VOPR’a single-byte error ekledi
    • 0.16.26’dan itibaren padding’i bozulmuş sector, crash yerine repair edilir
  • Superblock copy number bit flip’i de aynı panic’e yol açabiliyordu
    • Superblock’un dört kopyasının her biri farklı 2 baytlık copy numarasına sahiptir ve checksum bu numarayı atlar
    • Diskte bozulan copy number belleğe okunduktan sonra write sırasında 0–3 aralığı assertion’ını başarısız kılıyordu
    • 0.16.26’da copy number reset edilerek çözüldü

Yükseltmeyle ilgili sorunlar

  • 0.16.25 ve altından 0.16.26 veya üstüne yükseltme yapılırken panic: checkpoint diverged çökmesinin tekrar tekrar gözlemlendiği görüldü
    • Nedeni, 0.16.26’daki CheckpointState yapısının değişmesiydi
    • Yeni sürüm released blocks kümesini içeriyordu, ancak eski sürümle uyumlu durum aktarımı sırasında bu bilgi boş olabiliyordu
    • Sonrasında bir düğüm 0.16.26 ile yeniden başlatıldığında, diğer replikaların bildiği released blocks bilgisini kaybetmiş durumda kalabiliyordu
    • Assertion divergence’ı algılayıp çökerek istemcinin tutarsız veri gözlemlemesini engelledi
  • Bu sorun #2745 ile changelog’da belgelendi
    • TigerBeetle yamalı bir 0.16.26 sürümü yayımlamadı
    • Operatörler 0.16.26 veya üstüne yükseltmeden önce client’ı durdurmalı ve replica catch-up’ın tamamlanmasını beklemeli
  • 0.16.16’dan 0.16.28’e birden fazla upgrade yaklaşık 20 saniye içinde art arda yapıldığında veya upgrade sırasında düğüm pause/crash olduğunda release_transition assertion failure oluştu
    • Çalışmakta olan düğüm yeni binary’yi memfd ile açıp exec() ile değiştiriyor, ancak bu arada diskteki binary daha yeni bir sürümle değiştirilmiş olabiliyor
    • Kod, diskteki version header’ın da o anda çalışan sürümle aynı olduğunu assert ettiği için başarısız oluyor
    • #2758 ile 0.16.29’da assertion warning’e dönüştürüldü
  • 0.16.26’dan 0.16.27’ye yükseltme sırasında deprecated message type nedeniyle panic: switch on corrupt value oluştu
    • Yeni düğümdeki switch ifadesinde eski mesaj tipi için case bulunmadığından crash oluyordu
    • #2763 ile 0.16.29’da deprecated message type yeniden case’e eklenip yok sayılacak şekilde düzeltildi

Tek düğüm disk kaybından kurtarma

  • TigerBeetle dosya bozulmalarına karşı dayanıklı olsa da disk arızası, yangın, EBS volume error, operatör hatası gibi nedenlerle bir düğümün veri dosyasının tamamı kaybolabilir veya kurtarılamayacak şekilde bozulabilir
  • Raporun yazıldığı dönemde belgelerde arızalı düğümü değiştirme yöntemi yoktu; undocumented recovery prosedürü olarak tigerbeetle format çalıştırılıp boş bir veri dosyasıyla başlatma ve ardından repair bekleme yöntemi vardı
  • Jepsen, reformat’ın çoğunlukla çalıştığını ancak güvenli olmayabileceğini doğruladı
    • 3 düğümden 2’sinde committed operation op varken bunlardan biri reformat edilirse, opyi gözlemlememiş 2/3 majority bir view change gerçekleştirip operation’ın kaybolmasına yol açabilir
    • Gerçek testte acknowledged transfer’lardan 5’inin kaybolduğu bir run oldu
    • Upgrade sırasında newer binary ile formatlanan bir düğümün cluster version transition tamamlanmadan startup crash yaşadığı örnekler de vardı
  • Bu sorun #2767 ile takip ediliyor
  • Daha sonra TigerBeetle 0.16.43, catastrophic data loss yaşayan düğümleri kurtarmak için tigerbeetle recover komutunu içerdi

Jepsen’in sonucu ve önerileri

  • Bulunan güvenlik sorunları iki taneydi
    • 0.16.17 öncesinde çoklu filtre sorgu sonuçlarının eksik dönmesi
    • Jepsen testlerinde kullanılan Java istemcisinin debugging API’sindeki hatalı ve yinelenen timestamp’ler
  • Crash sorunları toplam 7 adetti
    • Java istemcisi 2 adet: uninitialized memory access, eviction sırasında process crash
    • Sunucu 5 adet: disk bozulmasıyla ilgili 2 panic, upgrade ile ilgili 3 panic
    • #2745 belgelendi, kalan crash’ler ise 0.16.29’a kadar çözüldü
  • 0.16.43, rapordaki sorunlardan biri dışında kalanların tamamını çözdü
    • unresolved madde, client request’lerin tasarım gereği sürekli retry edilmesi sorunu
  • Kullanıcılara yönelik öneriler net
    • 0.16.43’e yükseltin
    • 0.16.26’ya veya sonraki sürümlere geçerken release note’ları kontrol edin
    • Test ortamında tek düğüm arızasını simüle edin ve uygulamanın artan latency’ye nasıl tepki verdiğini ölçün
  • TigerBeetle’ın mimarisi sound görünüyor; VR, flexible quorum ve protocol-aware recovery entegrasyonunun Strong Serializability’nin temel invariant’larını bozmadığı gözlemlendi
  • Ancak Jepsen doğrulaması deneysel bir yaklaşım olduğundan, bug’ların varlığını kanıtlayabilir ama yokluğunu kanıtlayamaz

İlgili okumalar

1 yorum

 
GN⁺ 2025-06-07
Hacker News yorumları

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

  • Bu rapor gerçekten etkileyici. TigerBeetle’ın güvenilirlik ve ölçeklenebilirlik iddialarını her gördüğümde “tamam, Jepsen raporunu bekleyelim” diye düşünüyordum
    Raporda birkaç sorun ortaya çıktı ve bunlar endişe yaratabilir; ama yalnızca düzeltmekle kalmayıp, gelecekte benzer hataları yakalamak için iç test paketlerini genişletmiş olmaları olumlu. Bu mühendislik yaklaşımıyla TigerBeetle, 10 yıl sonra finans uygulamaları nişinde “sadece Postgres kullan yeter” seviyesinde varsayılan veritabanı haline gelebilir gibi görünüyor
    aphyr’in işi de harikaydı; raporu okurken çok şey öğrendiğimi hissettim

    • TigerBeetle’da 6.000’den fazla assertion var; bazıları o kadar katıydı ki çökmelere yol açtı, ama bu assertion’lar görevini yapıp mental model’in ayarlanması gerektiğine dair sinyal verdi ve gerçekten de ayarlandı
      Bunun dışında, Jepsen denetimine yardımcı olmak için yalnızca Java istemcisine eklenen dahili test işlevindeki küçük bir doğruluk hatası hariç, Jepsen’in bulduğu yalnızca bir doğruluk hatası vardı ve dayanıklılığı etkilemiyordu. İlgili yazı burada: https://tigerbeetle.com/blog/2025-06-06-fuzzer-blind-spots-m...
      Adil olmak gerekirse TigerBeetle, Postgres’e kıyasla daha fazla arıza türüne dayanacak şekilde tasarlanıp test edildi. Çünkü açık bir depolama arızası modeli var ve Postgres’in 1996’da çıktığı dönemde mevcut olmayan araştırmalardan yararlanıyor. TB’nin arıza modeli deterministik simülasyon testleriyle ayrıca doğrulanıyor; NASA’nın Safety-Critical Code için Power of Ten Rules’ına uygun statik bellek ayırma gibi teknikler de kullanılıyor. Literatürde Postgres’in veri kaybettiği bilinen senaryolar var, ancak TigerBeetle bunları tespit edip kurtarabiliyor
      Daha fazlası için Kyle’ın raporundaki helical fault injection bölümüne bakabilirsiniz. Çoğu Raft ve Paxos uygulaması buna dayanacak şekilde tasarlanmamıştır; QCon London sunumu da var: https://m.youtube.com/watch?v=_jfOk4L7CiY
    • Kyle’ın yazılarını hep sabırsızlıkla bekliyorum. Her yeni yazı çıktığında dağıtık sistemler bilgisi bir seviye yükseliyor gibi hissediyorum

  • aphyr’in doğrulaması sonucunda TigerBeetle’ın kendi iddialarıyla uyumlu bir görüntü sergilemesini görmek gerçekten sevindirici. Doğru yaklaşımı seçince doğru sonuçların geldiğini görmek güzel
    TigerBeetle’ın pratikte nasıl kullanılacağını merak ediyorum. Account veya Transfer olmayan her şey için TigerBeetle kurulumunun etrafında dış sistemler ve başka veritabanları çok olacak; bu daha az güvenilir sistemlerin TigerBeetle ile uyum içinde çalışması için tipik kalıplar neler, özellikle ikisi arasında tutarlılık sorunu oluştuğunda nasıl toparlanılıyor merak ediyorum

    • TigerBeetle’ı entegre ederken tipik kalıp kontrol düzlemi ile veri düzlemini ayırmaktır. Genel amaçlı işler veya OLGP için Postgres, işlem işleme veya OLTP için TigerBeetle kullanılır
      Kullanıcı bilgileri (ad, adres, parola vb.) ve ürün bilgileri (açıklama, fiyat vb.) bir “dosya dolabı” olarak OLGP’ye konur
      Black Friday’de kullanıcının ürünü stok hesabından sepet hesabına, oradan da ödeme ve gönderim hesaplarına taşıdığı tüm işlemler ise bir “kasa” olarak OLTP’ye konur. TigerBeetle, her hesap veya transfer için en fazla 3 kullanıcı veri tanımlayıcısı saklamanıza izin verir; böylece varlıklar arasındaki olaylar, bu varlıkları tanımlayan OLGP veritabanıyla ilişkilendirilebilir
      Bu mimari [1], temiz bir sorumluluk ayrımı sağlayarak farklı iş yüklerinin bağımsız ölçeklenmesini ve yönetilmesini mümkün kılar. Bir banka için, müşteri kayıtlarının bulunduğu dosya dolabında tüm nakdi saklamak yerine; performans, mevzuata uyum ve saklama özellikleri farklı olan nakdi kasada tutmak daha mantıklıdır
      Bu kalıbın doğru olmasının nedeni, kullanıcıların adını veya e-posta adresini değiştirme sıklığının (OLGP), işlem yapma sıklığından (OLTP) çok daha düşük olmasıdır
      Tutarlılığı korumak için yazma yolunda TigerBeetle’ı OLTP veri düzlemi ve “kayıtların kaynağı” olarak ele alın. “Sepete taşı” veya “ödeme” işlemi geldiğinde önce gerekli veri bağımlılıklarını OLGP’ye yazın; ilgili blob verisi varsa S3 gibi bir yere de yazın; ardından en son TigerBeetle’a yazarak işlemi commit edin. Okuma yolunda ise katı serileştirilebilirliği korumak için önce kayıtların kaynağını sorgulayın
      [1] https://docs.tigerbeetle.com/coding/system-architecture/

  • TigerBeetle’ın fuzzer kör noktaları yazısını okuduktan sonra özellikle ilginç gelen bir Jepsen raporu
    JNI tarafındaki segfault, Rust veya başka bir bellek güvenli dil kullanılmış olsaydı bile engellenemeyecek gibi görünüyor. Bellek güvenliği hatalarının çok az olması, TigerBeetle’ın Zig programlama yaklaşımının, hatırladığım kadarıyla TigerStyle’ın amaçladığı rolü oldukça iyi yerine getirdiğinin kanıtı gibi duruyor

    • https://news.ycombinator.com/item?id=44201189 bağlantısına bakın. Rust olsaydı kurtaracağı bir hata vardı. Ama assertion kurtardı; pastırma yalnızca biraz çıtırlaştı, yanmadı
      Yine de doğru. TigerStyle olmasaydı nasal demonsa yakalanırdı

  • Harika derecede ayrıntılı raporu beğendim. Jepsen tarafından test edilip imzalanmış olması TigerBeetle için muazzam bir güvence. Henüz v1.0’a bile ulaşmadı; bundan sonraki yeni kilometre taşlarını merakla bekliyorum.
    Bu başlıkta iyi içgörüler paylaşan kuruculara da ayrıca alkış

    • Kyle inanılmaz bir iş çıkardı; rapordaki ayrıntılar da gerçekten çok iyiydi. Okurken baştan sona “bu bir sanat eseri gibi” diye düşündüm; o kadar zanaatkârlık ve hassasiyet hissediliyordu.
      Yakında Amsterdam’daki SD25 sunumunda da yeni şeyler paylaşacak, onu da sabırsızlıkla bekliyorum.

  • “Panic! At the Disk 0” bölüm başlığı küçük de olsa hoşuma gitti.

  • Test edilen dağıtık sistemin, duvar saati zamanını kullanmak yerine sistemin dış modeliyle doğru biçimde doğrulanabilmesi için olayların gerçekten gerçekleştiği zamanı ve sırayı raporlaması gerektiği sonradan bakınca bariz ama ilginç.

    • Bunun çalışmasının nedeni strict serializability olması. Daha zayıf tutarlılık garantilerinde tek bir küresel tutarlı zaman çizelgesi mutlaka bulunmaz.
      Daha zor bir işi başardığınızda sistemin tersine basitleşmesi ilginç bir meta örüntü.
      Bir başka örnek olarak, diskin arızalanabileceğini varsayıp bir kurtarma protokolü eklemek gerektiğinden, geride kalmış replikaların durum senkronizasyonunu fiilen “bedavaya” elde ediyorsunuz. Çünkü bu, tüm diskin bozulduğu durumla tam olarak aynı problem.
    • Bunun klasik yaklaşım olduğunu düşünüyorum. Örn: https://lamport.azurewebsites.net/pubs/time-clocks.pdf

  • Yazıdaki “Viewstamped Replication” makalesine giden bağlantı ne yazık ki bozuk. https://pmg.csail.mit.edu/papers/vr-revisited.pdf bağlantısı reddediliyor.
    Muhtemelen http://pmg.csail.mit.edu/papers/vr-revisited.pdf gibi https değil http şeması olmalı.
    Artık cuma akşamı okuyacak bir şeyim var.

    • Yakında düzeltilecek.
      VSR 2012 makalesi en sevdiğim makalelerden biri; “Protocol-Aware Recovery for Consensus-Based Storage” da gerçekten çok güçlü.
      Keyifli okumalar.

  • Sırf öğrenmek istediğim için soruyorum; yanlış anlaşılmasını istemem. Dağıtık sistemleri yeni öğreniyorum ve deterministik simülasyon testleri beni büyülüyor.
    TigerBeetle hakkındaki Jepsen raporuna, ilgili blog yazılarına ve GitHub workflow’undaki Antithesis entegrasyon koduna kısaca baktıktan sonra test kapsamını daha iyi anlamak istedim.
    Temel sorum şu: Jepsen test paketinin bulduğu bu hataları Antithesis entegrasyonu da bulabilir miydi?
    Bu soru bazı varsayımlardan geliyor ve yanlış olabilirler. TigerBeetle’ın zaten kendi iç test paketi ve Antithesis ürünüyle kapsamlı biçimde test edildiğini sanıyordum; ayrıca Antithesis test paketinin Jepsen’den daha güçlü olduğunu anladığım için Jepsen’in Antithesis’in bulamadığı sorunları keşfetmesi bana şaşırtıcı geldi.
    Anlayışımın yanlış olup olmadığını merak ediyorum. Örneğin 1) Antithesis test paketinin bu belirli hata sınıfını algılayıp algılayamadığını, 2) sistemin bu bölümünün henüz Antithesis testleriyle kapsanıp kapsanmadığını, 3) Jepsen ve Antithesis test paketlerinin farklı güçlü yanlarını ve hedeflerini yanlış anlayıp elmalarla portakalları mı karşılaştırdığımı bilmek isterim.

    • TigerBeetle blog yazısında daha ayrıntılı anlatılıyor ama kısaca, Antithesis’te çalışan testler oldukça kapsamlı olmasına rağmen kesişen sorgular ile sırası değişmiş değerlerin tam kombinasyonunu oluşturamamıştı; Jepsen üreticisi ise bu kombinasyonu tutturdu.
      Jepsen test üreticisinde de neredeyse kesin olarak kör noktalar vardır. Bu yüzden farklı üreticiler tasarlamak faydalı.
    • Dağıtık sistemlerde üretici tabanlı testler genellikle üç bileşen gerektirir. Birincisi, sistemi çalıştıracak bir ortama ihtiyaç vardır. En basit haliyle gerçek makinelerden oluşan bir küme ayağa kaldırmak olabilir; ancak performansı, harici API yanıtları üzerindeki kontrolü, determinizmi ve yeniden üretilebilirliği artırmak için daha sofistike bir şey daha iyidir. İkincisi, ortamdaki sisteme ilginç işler yaptıracak bir yük üreticisi gerekir. Üçüncüsü, yük altındaki sistemin davranışını gözlemleyip spesifikasyona uyup uymadığına karar veren bir denetçi gerekir.
      Antithesis esas olarak 1. problemi ele alır ve sanal makinelerle deterministik simülasyon ortamı sağlar. Jepsen aynı problemi gerçek makineler kullanıp işletim sistemi seviyesinde arıza enjekte ederek ele alır; TigerBeetle’ın kendi VOPR’ı ise veritabanıyla birlikte tasarlanmıştır ve tüm kümeyi tek bir iş parçacığında çalıştırabilir. Bu üç yaklaşım birbirini tamamlar ve her birinin iyi olduğu alanlar farklıdır.
      Bu hatada belirleyici olan kısım 2 ve 3’tü: yani hatayı gerçekten tetikleyebilen workload doğrulayıcıları ve denetçileri yazmak. Burada aphyr’nin yazdığı TigerBeetle’a özel 1.600 satırlık Clojure kodu hatayı tetikledi ve tespit etti; ardından TigerBeetle tarafındaki eşdeğer test de bunu tetikleyecek şekilde yamalandı. Aslında burada hatalı olan veritabanından çok VOPR. Veritabanında hata olması olağan bir şey; sadece iradeyle hatalardan kaçınılamaz. Bu yüzden çoğu hatayı tetikleyebilecek bir test stratejisine ihtiyaç var; kaçan hatalar ise workload üreticisindeki kusurlara işaret eder.
    • Deterministik simülasyon testlerinin %90’ını çoğunlukla TigerBeetle’ın kendi geliştirdiği deterministik simülatör VOPR yapıyor. 1.000 özel CPU çekirdeği ölçeğinde 7/24 çalışıyor.
      Antithesis’i de kullanıyoruz, ancak deterministik simülasyon testlerinin ikinci katmanı olarak.
      Sorgu motoru hatasının neden kaçtığı için buraya bakın: https://tigerbeetle.com/blog/2025-06-06-fuzzer-blind-spots-m...

  • Büyük bankaların ya da borsaların TigerBeetle kullanıp kullanmadığını merak ediyorum

    • Ülke ölçeğinde, Gates Foundation ile birlikte TigerBeetle’ı kâr amacı gütmeyen bir merkez bankası anahtarına entegre ediyoruz; bu sistemin bu yılın sonunda Ruanda’nın National Digital Payments System 2.0 sistemini çalıştırması planlanıyor [1]
      Şirket ölçeğinde ise TigerBeetle, hâlihazırda ayda 100 milyondan fazla işlemi işleyen müşterilerin üretim ortamlarında kullanılıyor; yakın zamanda Avrupa’nın 2 milyar dolarlık fintech unicorn’larından biriyle ilk sözleşmesini imzaladı ve ABD’de de birkaç anlaşmanın yakında tamamlanması bekleniyor. Dünya genelinde gerçek zamanlı işlem işlemeye geçiş eğilimi [2] nedeniyle, daha yüksek performans için TigerBeetle’a geçmek isteyen şirketlerden epey ilgi var.
      Soruyu yanıtlamak gerekirse, Wall Street’in oldukça büyük aracı kurumlarından Clear Street’in bazı kurucuları TigerBeetle’a yatırım yaptı [3].
      [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
    • Banka ya da borsa değil ama çok büyük bir fintech şirketinde çalışıyorum ve yeni bir üründe TigerBeetle kullanıyoruz
    • Böyle bir müşterileri olsaydı, sanırım ana sayfada bununla övünürlerdi. Şu ana kadar ana sayfadaki en büyük referans bir YouTuber’dan gelmiş. Popüler bir YouTuber olduğu doğru ama sonuçta YouTuber.