Jepsen द्वारा TigerBeetle 0.16.11 का सत्यापन

 (jepsen.io)
1 पॉइंट द्वारा GN⁺ 2025-06-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • डबल-एंट्री बुककीपिंग के लिए OLTP डेटाबेस TigerBeetle सुरक्षा और गति को आगे रखता है, और Jepsen ने 3–6 Debian नोड वाले क्लस्टर पर fault injection के साथ 0.16.11~0.16.30 सीरीज़ का सत्यापन किया
  • टेस्ट ने explicit timestamp order और डॉक्यूमेंटेशन-आधारित single-threaded state machine model को मिलाकर Strong Serializability और account, transfer, query semantics को साथ में जांचा
  • मुख्य safety bugs में multi-filter query results का छूटना और Java client header timestamp error शामिल थे; 0.16.26 और उससे ऊपर के versions में कई fault combinations के बावजूद Strong Serializability के दावे से मेल खाते परिणाम देखे गए
  • availability के लिहाज से client infinite retries, session eviction पर process crash, single-node failure में latency का तेजी से बढ़ना, disk bit flip और upgrade के दौरान server panic, और single-node disk loss recovery path की कमी सामने आई
  • TigerBeetle 0.16.43 रिपोर्ट किए गए ज्यादातर issues को शामिल करता है, जिसमें single-node failure latency mitigation और tigerbeetle recover शामिल हैं; operators को 0.16.43 upgrade और 0.16.26 या उससे ऊपर पर जाने के समय release notes देखना जरूरी है

TigerBeetle का design और test scope

  • TigerBeetle डबल-एंट्री बुककीपिंग के लिए OLTP डेटाबेस है; यह arbitrary rows, objects, graphs या blobs के बजाय सिर्फ accounts और transfers स्टोर करता है
  • यह Viewstamped Replication (VR) पर आधारित Strong Serializable consistency देने का वादा करता है और financial transactions, inventory, ticketing, utility metering जैसे models के लिए design किया गया है
  • high-contention, high-throughput workloads के लिए सभी writes को primary VR node के single core से गुजारता है और scale-out के बजाय scale-up पर focus करता है
    • performance के लिए batch processing, I/O parallelization, fixed schema, fixed-size और cache-aligned data structures का इस्तेमाल करता है
  • fault model memory, process, clock, storage और network को स्पष्ट रूप से संभालता है
    • process रुक सकता है या crash हो सकता है
    • clock आगे-पीछे jump कर सकती है
    • disk में complete failure के अलावा partial write corruption और data corruption भी हो सकते हैं
    • network delay, drop, duplicate, misdelivery और message corruption पैदा कर सकता है
  • TigerBeetle deterministic simulation testing का इस्तेमाल करता है, और VOPR test पूरे cluster के साथ clock, disk और network interfaces को simulate करता है

Data model और request semantics

  • data model दो तरह के records से बना है: accounts और transfers
    • account में user-defined 128-bit id, ledger, flags, timestamp, code, user_data_32, user_data_64, user_data_128 आदि होते हैं
    • transfer एक immutable record है जिसमें debit_account_id, credit_account_id, amount, ledger, flags, user-defined fields आदि शामिल होते हैं
  • transfer को single step में तुरंत post किया जा सकता है, और two-phase transfer भी संभव है जो pending और post/void में बंटता है
    • pending transfer debit और credit accounts की capacity reserve करता है
    • बाद में pending amount तक post या void किया जा सकता है
    • automatic expiry को timeout field से control किया जाता है
  • account closed flag और चार balance fields को छोड़कर immutable होता है, और transfer हमेशा immutable होता है
    • transfer को बदलने या reverse करने के लिए नया compensating transfer बनाना पड़ता है
  • request एक ही प्रकार के logical operation को दर्शाता है और आम तौर पर अधिकतम 8190 events की batch रखता है
    • create_accounts, create_transfers write requests हैं
    • lookup_accounts, lookup_transfers, query_accounts, query_transfers, get_account_transfers, get_account_balances read requests हैं
  • हर request database के नजरिए से एक transaction है, लेकिन committed request के भीतर कुछ events logical रूप से fail होकर error code लौटा सकते हैं
    • अगर events के बीच conditional atomicity चाहिए, तो chain का इस्तेमाल करके एक ही chain के events को सभी सफल या सभी fail कराया जाता है

Jepsen test method

  • Jepsen test suite Jepsen testing library का इस्तेमाल करके property-based testing और fault injection को जोड़ता है
  • test target TigerBeetle 0.16.11 से 0.16.30 तक हैं, जिनमें कई development builds भी शामिल हैं
    • cluster 3–6 Debian nodes से बना है
    • इसे LXC containers और EC2 VMs दोनों पर चलाया गया
  • TigerBeetle का official client सभी nodes से connect करने वाला smart client है, इसलिए वह concurrency errors छिपा सकता है
    • Jepsen ने सामान्य smart-client behavior भी test किया
    • साथ ही हर client को single node तक सीमित करने का तरीका भी इस्तेमाल किया
  • verifier दो चरणों में काम करता है
    • successful requests के execution timestamps पढ़ता है, और failed या timed-out writes के timestamps बाद में देखे गए effects से infer करता है
    • inferred timestamp order के अनुसार documentation-based TigerBeetle state machine model चलाकर results और error codes verify करता है
  • state machine model 1,600 से ज्यादा lines के Clojure में लिखा गया था, और इसमें account और transfer maps, indexes, transient errors, internal statistics, clock flow आदि शामिल हैं
    • यह duplicate IDs, non-monotonic timestamps, balance constraints, incompatible flags, chain की speculative execution और rollback आदि को handle करता है
    • high-performance persistent data structure library Bifurcan का इस्तेमाल करता है

Fault injection और file corruption test

  • Jepsen ने process SIGKILL, SIGSTOP, कई तरह के network partitions, milliseconds से लेकर सैकड़ों seconds तक clock changes, और तेज clock round-trip changes inject किए
  • tests के दौरान कई versions में node upgrades भी किए गए
  • नए file corruption nemesis से अलग-अलग storage faults बनाए गए
    • random bit flips से cosmic ray interference जैसी corruption simulate की गई
    • file chunks को दूसरे chunks से replace करके misdirected write simulate किया गया
    • file chunk snapshots को बाद में restore करके lost write simulate किया गया
  • TigerBeetle node के पास एक single data file होती है, और file अनुमानित offsets वाली zones में बंटी होती है
    • WAL header, superblock zone की duplicate copies जैसी specific zones को ही corrupt करने वाले tests किए गए
    • कई zones या पूरी file को corrupt करने वाले tests भी शामिल थे
  • “helical” disk fault सभी nodes की files को corrupt करता है, लेकिन हर node में अलग chunk corrupt करता है
    • इसका मकसद उस स्थिति से बचना है जिसमें single record सभी replicas में recover न हो सकने लायक corrupt हो जाए, क्योंकि TigerBeetle का latest replica file layout आम तौर पर bit-for-bit identical होता है
    • WAL का head node-specific location पर हो सकता है, इसलिए वह exception है

खोजे गए safety मुद्दे

  • 0.16.13 में query_accounts, query_transfers, get_account_transfers responses में कुछ या सारे results छूट जाने की समस्या अक्सर हुई
    • छूटे हुए results हमेशा response के अंत वाले हिस्से में थे, और response सही results का prefix था
    • यह single filter query में नहीं दिखा, बल्कि ledger और code जैसे multiple filters के combinations में हुआ
    • कारण कई indexes के बीच zig-zag merge join में bounds check bug था
    • इसे #2544 में track किया गया और 0.16.17 में fix किया गया
  • 0.16.13 में Jepsen test support के लिए जोड़ी गई Java client header API गलत या duplicate execution timestamps return करती थी
    • कारण Java client का mutable singleton response object Batch.EMPTY था
    • success response को empty batch के रूप में represent करने पर कई responses एक ही object के header को overwrite कर रहे थे
    • इसे #2495 में fix किया गया और 0.16.14 में शामिल किया गया
    • वास्तविक data consistency पर इसका असर नहीं पड़ा, केवल Java client header API के request timestamps पर असर पड़ा
  • 0.16.26 और उसके बाद observed results TigerBeetle के Strong Serializability दावे से मेल खाते हैं
    • process pause, crash, network partition, clock error, disk corruption, upgrade के combinations में भी यह property कायम रही

Client और request processing issues

  • TigerBeetle docs बताते हैं कि requests timeout नहीं होते और client response मिलने तक retry करता रहता है
    • Java asynchronous methods CompletableFuture return करते हैं और .get(timeout, timeUnit) या .orTimeout(...) जैसी timeout APIs इस्तेमाल की जा सकती हैं
    • .NET client का Task भी timeout-based Wait() देता है
  • Infinite retry definite error और indefinite error दोनों को छिपा सकता है
    • उदाहरण के लिए, TCP connection अगर ECONNREFUSED से fail हो जाए, तो यह definite failure है कि वह original request execute नहीं हो सकती
    • लेकिन अगर client इसे caller को बताए बिना सिर्फ internally retry करता रहे, तो caller के नजरिए से यह timeout या interruption जैसी indefinite failure बन जाती है
  • इस issue पर #206 में चर्चा चल रही है, और report के समय यह unresolved था
    • Jepsen definite error और indefinite error को first-class तरीके से represent करने और caller को return करने की सिफारिश करता है
    • automatic retry रखा जा सकता है, लेकिन उसे configurable होना चाहिए; connection initiation और response wait के लिए maximum time को option के रूप में रखने की सिफारिश की गई
  • 0.16.11 Java client में timeout handling के लिए synchronous call thread को interrupt करने या asynchronous call के बाद client close करने पर पूरा JVM segfault हो जाता था
    • कारण request data structure का unset field था
    • अगर client request creation और submission के बीच बंद हो जाए, तो Zig default value 0xaaa... address को dereference करता था
    • इसे #2435 में fix किया गया और 0.16.12 में शामिल किया गया
  • official clients server द्वारा session eviction बताने पर पूरे process को crash कर देते थे
    • TigerBeetle default रूप से concurrent sessions को 64 तक limit करता है
    • server से नया client version इस्तेमाल करने पर भी eviction हो सकता है
    • #2484 के बाद 0.16.13 से eviction पर process crash के बजाय caller को error return किया जाता है

Single-node failure पर latency में तेज उछाल

  • single-node failure में client latency 3–5 digits तक बढ़ने के cases बार-बार देखे गए
    • 5-node cluster में एक node को kill करने पर minimum latency 1ms से कम से बढ़कर 10 seconds हो गई
    • 3-node cluster में एक node को kill करने वाले test में 1–50ms latency प्रति request लगभग 100 seconds तक बढ़ गई, और node restart होने से पहले लगभग 1000 seconds तक बनी रही
  • कारण TigerBeetle के prepare propagation तरीके से जुड़ा था
    • traditional VR में primary सभी secondaries को prepare भेजता है और सीधे ack receive करता है
    • TigerBeetle nodes को ring में arrange करता है; primary अगले secondary को prepare भेजता है, फिर हर secondary अगले node को forward करता है
    • यह तरीका किसी एक node की bandwidth requirement घटाता है, लेकिन ring में अगले f replicas में से कोई fail हो जाए तो commit block हो सकता है
  • इस issue को #2739 में track किया गया
  • 0.16.30 ने prepare messages के आधे हिस्से को ring की opposite direction में भेजकर इसे mitigate किया
    • कुछ prepare failed node को bypass कर सकते हैं
    • Jepsen tests में 100-second range की latency घटकर 1–30 seconds के स्तर पर आ गई
  • 0.16.43 में अतिरिक्त performance improvements शामिल हैं
    • nodes ring की दोनों directions में replicate करते हैं
    • ring topology dynamically बदलती है, और cluster network conditions व failures के अनुसार node order adjust करता है

Disk corruption और server crash

  • 0.16.20 में superblock, WAL, grid zone में single-bit corruption से कभी-कभी startup crash होता था
    • logs panic: reached unreachable code print करके exit हो जाते थे
    • कारण sector padding check bug था
  • TigerBeetle checksum chunk के data को cover करता है, लेकिन padding को exclude करता है
    • padding का 0 bit 1 में बदल जाए तो checksum pass हो जाता है
    • इसके बाद padding अभी भी 0 है या नहीं, यह check करने वाली assertion fail होकर server crash करा देती है
    • padding corruption safety को नुकसान नहीं पहुंचाता, और इसे फिर से 0 बनाकर या दूसरे replica से recover किया जा सकता है
  • VOPR पहले पूरे sector को corrupt करता था, इसलिए यह bug नहीं मिला
    • sector corruption checksum failure और repair path trigger करता था, इसलिए padding assertion तक पहुंचता ही नहीं था
    • TigerBeetle ने #2681 में VOPR में single-byte error जोड़ा
    • 0.16.26 से padding-corrupted sector को crash के बजाय repair किया जाता है
  • superblock copy number bit flip भी वही panic पैदा कर सकता था
    • superblock की चार copies में अलग-अलग 2-byte copy number होता है, और checksum इस number को skip करता है
    • disk पर corrupt हुआ copy number memory में read होने के बाद write के समय 0–3 range assertion fail कर देता था
    • 0.16.26 में copy number reset करने के तरीके से इसे solve किया गया

अपग्रेड से जुड़ी समस्याएं

  • 0.16.25 या उससे नीचे से 0.16.26 या उससे ऊपर अपग्रेड करते समय panic: checkpoint diverged crash बार-बार देखा गया
    • वजह 0.16.26 में CheckpointState structure में बदलाव था
    • नए version में released blocks का set शामिल था, लेकिन पुराने version के साथ compatible state transfer के दौरान यह जानकारी खाली हो सकती थी
    • बाद में जब node 0.16.26 पर restart होता, तो वह उन released blocks को खोई हुई स्थिति में हो सकता था जिन्हें दूसरे replica जानते थे
    • assertion ने divergence detect करके crash किया, ताकि clients inconsistent data न देख सकें
  • यह समस्या #2745 में changelog में document की गई
    • TigerBeetle ने patched 0.16.26 release नहीं किया
    • operators को 0.16.26 या उससे ऊपर upgrade करने से पहले client रोककर replica catch-up का इंतजार करना चाहिए
  • 0.16.16 से 0.16.28 तक कई upgrades को करीब 20 सेकंड के भीतर लगातार चलाने पर, या upgrade के दौरान node pause/crash होने पर release_transition assertion failure हुआ
    • चल रहा node नए binary को memfd से खोलकर exec() के जरिए replace करता है, लेकिन इसी बीच disk पर मौजूद binary और नए version से replace हो सकता है
    • code disk के version header को भी current running version जैसा ही assert करता है, और इसी वजह से fail होता है
    • #2758 के जरिए 0.16.29 में assertion को warning में बदला गया
  • 0.16.26 से 0.16.27 पर upgrade करते समय deprecated message type के कारण panic: switch on corrupt value हुआ
    • नए node के switch statement में पुराने message type का case नहीं था, इसलिए crash हुआ
    • #2763 के जरिए 0.16.29 में deprecated message type को फिर से case में जोड़कर ignore करने के लिए fix किया गया

single-node disk loss recovery

  • TigerBeetle file corruption के खिलाफ मजबूत है, लेकिन disk failure, आग, EBS volume error, operator की गलती आदि के कारण node की पूरी data file गायब हो सकती है या recover न हो पाने लायक corrupt हो सकती है
  • report के समय documentation में failed node को replace करने का तरीका नहीं था, और एक undocumented recovery procedure था जिसमें tigerbeetle format चलाकर खाली data file से initialize किया जाता और फिर repair की उम्मीद की जाती थी
  • Jepsen ने पाया कि reformat ज्यादातर काम करता है, लेकिन unsafe हो सकता है
    • अगर 3 nodes में से 2 nodes पर committed operation op मौजूद हो और उनमें से एक को reformat कर दिया जाए, तो op को observe न करने वाली 2/3 majority view change कर सकती है और operation खो सकता है
    • असली test में एक run ऐसा था जिसमें 5 acknowledged transfers खो गए
    • upgrade के दौरान newer binary से format किया गया node cluster version transition पूरा होने से पहले startup crash कर गया, ऐसे मामले भी थे
  • यह समस्या #2767 में track की गई
  • बाद में TigerBeetle 0.16.43 में catastrophic data loss झेल चुके node को recover करने वाला tigerbeetle recover command शामिल किया गया

Jepsen के निष्कर्ष और सिफारिशें

  • मिली safety problems दो थीं
    • 0.16.17 से पहले multi-filter query results का missing होना
    • Jepsen testing के लिए Java client debugging API में गलत और duplicate timestamps
  • crash problems कुल 7 थीं
    • Java client में 2: uninitialized memory access, eviction के समय process crash
    • server में 5: disk corruption से जुड़े 2 panics, upgrade से जुड़े 3 panics
    • #2745 document कर दिया गया, और बाकी crashes 0.16.29 तक resolve हो गए
  • 0.16.43 ने report के issues में से एक को छोड़कर बाकी सब resolve कर दिए
    • unresolved item यह है कि client request design के हिसाब से लगातार retry होती रहती है
  • users के लिए recommendation साफ है
    • 0.16.43 पर upgrade करें
    • 0.16.26 पर या उसके बाद के versions पर जाते समय release note जांचें
    • test environment में single-node failure simulate करें और मापें कि application बढ़ी हुई latency पर कैसे react करता है
  • TigerBeetle का architecture sound दिखता है, और देखा गया कि VR, flexible quorum और protocol-aware recovery के integration ने Strong Serializability की core invariants को नुकसान नहीं पहुंचाया
  • हालांकि Jepsen verification एक experimental approach है, इसलिए यह bugs की मौजूदगी साबित कर सकता है, लेकिन उनकी गैर-मौजूदगी साबित नहीं कर सकता

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-06-07
Hacker News की राय

  • साथ में पढ़ने लायक लेख: Fuzzer Blind Spots (Meet Jepsen!) – https://tigerbeetle.com/blog/2025-06-06-fuzzer-blind-spots-m...

  • यह रिपोर्ट सच में प्रभावशाली है। TigerBeetle के विश्वसनीयता और scalability के दावे जब भी देखता था, सोचता था “ठीक है, Jepsen रिपोर्ट का इंतजार करते हैं”
    रिपोर्ट में कई issues सामने आए और चिंता हो सकती है, लेकिन सकारात्मक बात यह है कि वे सिर्फ fix करके नहीं रुके, बल्कि भविष्य में ऐसे मिलते-जुलते bugs पकड़ने के लिए अपने internal test suite को बढ़ाया। ऐसे engineering approach के साथ, 10 साल बाद TigerBeetle financial applications के niche में “बस Postgres इस्तेमाल कर लो” जितना default database बन सकता है
    aphyr का काम भी शानदार था, और रिपोर्ट पढ़कर लगा कि काफी कुछ सीखा

    • TigerBeetle में 6,000 से ज्यादा assertions हैं, और कुछ इतने सख्त थे कि crash हुआ, लेकिन उन assertions ने अपना काम किया: उन्होंने संकेत दिया कि mental model को adjust करना होगा, और सच में उसे adjust किया गया
      इसके अलावा, Jepsen audit में मदद के लिए सिर्फ Java client में डाली गई internal test functionality के एक छोटे correctness bug को छोड़ दें, तो Jepsen ने सिर्फ एक correctness bug पाया था और उसका durability पर असर नहीं था। संबंधित लेख यहां है: https://tigerbeetle.com/blog/2025-06-06-fuzzer-blind-spots-m...
      निष्पक्ष रूप से कहें तो TigerBeetle को Postgres से ज्यादा failures झेलने के लिए design और test किया गया है। वजह यह है कि इसमें explicit storage failure model है और यह उस research का इस्तेमाल करता है जो 1996 में Postgres आने के समय उपलब्ध नहीं थी। TB का failure model deterministic simulation testing से अतिरिक्त रूप से verify किया जाता है, और NASA के Safety-Critical Code के लिए Power of Ten Rules के अनुसार static memory allocation जैसी techniques भी इस्तेमाल होती हैं। साहित्य में ऐसे ज्ञात scenarios हैं जहां Postgres data खो देता है, लेकिन TigerBeetle उन्हें detect और recover कर सकता है
      और देखना हो तो Kyle रिपोर्ट का helical fault injection section देखें। अधिकतर Raft और Paxos implementations इसे झेलने के लिए design नहीं की गई हैं, और QCon London talk भी है: https://m.youtube.com/watch?v=_jfOk4L7CiY
    • Kyle के लेखों का हमेशा इंतजार रहता है। हर नए लेख के साथ लगता है कि distributed systems knowledge एक level ऊपर चला गया

  • aphyr के verification के बाद TigerBeetle को अपने दावों पर खरा उतरते देखना सच में अच्छा लगा। सही approach चुनने पर सही नतीजे आते हैं, यह देखना अच्छा है
    मुझे उत्सुकता है कि TigerBeetle को असल में कैसे इस्तेमाल किया जाएगा। Account या Transfer के अलावा बाकी हर चीज के लिए TigerBeetle installation के आसपास external systems और दूसरी databases बहुत होंगी; ऐसे कम विश्वसनीय systems का TigerBeetle के साथ तालमेल बैठाने का typical pattern क्या है, और खासकर जब दोनों के बीच consistency issues पैदा हों तो recovery कैसे होती है

    • TigerBeetle को integrate करते समय typical pattern control plane और data plane को अलग करना है। general purpose या OLGP के लिए Postgres इस्तेमाल करें, और transaction processing या OLTP के लिए TigerBeetle
      user information (नाम, पता, password आदि) और product information (description, price आदि) को “filing cabinet” के रूप में OLGP में रखा जाता है
      और Black Friday पर user द्वारा product को inventory account से cart account में, फिर payment और shipping accounts में ले जाने वाली सारी transactions को “vault” के रूप में OLTP में रखा जाता है। TigerBeetle हर account या transfer के लिए अधिकतम 3 user data identifiers store करने देता है, इसलिए entities के बीच events को उन entities का वर्णन करने वाले OLGP database से जोड़ा जा सकता है
      यह architecture [1] साफ separation of concerns देता है, जिससे अलग-अलग workloads को independently scale और manage किया जा सकता है। अगर बैंक की बात हो, तो ग्राहक records वाले filing cabinet में सारी cash रखने के बजाय, अलग performance, compliance और retention characteristics वाली cash को vault में रखना ज्यादा उचित है
      यह pattern इसलिए सही है क्योंकि user अपने नाम या email address को जितनी बार बदलता है (OLGP), उससे कहीं ज्यादा बार transactions करता है (OLTP)
      consistency बचाए रखने के लिए write path में TigerBeetle को OLTP data plane और “source of record” माना जाता है। “cart में move” या “payment” transaction आने पर पहले जरूरी data dependencies OLGP में लिखी जाती हैं, अगर relevant blob data हो तो S3 जैसी जगह पर भी लिखा जाता है, और फिर आखिर में TigerBeetle में लिखकर transaction commit की जाती है। read path में strict serializability बनाए रखने के लिए source of record को पहले query किया जाता है
      [1] https://docs.tigerbeetle.com/coding/system-architecture/

  • TigerBeetle के fuzzer blind spots वाले लेख को पढ़ने के बाद यह Jepsen report खास तौर पर दिलचस्प लगती है
    JNI वाले segfault को देखकर लगता है कि Rust या कोई दूसरी memory-safe language इस्तेमाल करने पर भी वह नहीं रुकता। memory safety bugs का लगभग न होना TigerBeetle के Zig programming approach—याद पड़ता है TigerStyle—के अपने intended role को काफी अच्छी तरह निभाने का सबूत लगता है

    • https://news.ycombinator.com/item?id=44201189 देखें। Rust होता तो एक bug जरूर बच जाता। उसके बजाय assertion ने बचा लिया, इसलिए bacon थोड़ा crispy हुआ, जला नहीं
      फिर भी बात सही है। TigerStyle नहीं होता तो nasal demons ने पकड़ लिया होता

  • मुझे यह बेहद विस्तृत रिपोर्ट बहुत पसंद आई। Jepsen ने टेस्ट किया और उस पर साइन किया, यह TigerBeetle के लिए बहुत बड़ी गारंटी है। यह अभी v1.0 तक भी नहीं पहुँचा है, और आगे आने वाले नए milestones का इंतज़ार है
    इस थ्रेड में अच्छी insights साझा करने वाले founders को भी खास तौर पर सराहना

    • Kyle ने कमाल का काम किया है, और रिपोर्ट में मौजूद detail भी सचमुच शानदार है। पढ़ते समय बार-बार लगा कि “यह तो कला का नमूना है”, इतनी craftsmanship और precision महसूस हुई
      जल्द ही Amsterdam में SD25 talk में भी नई बातें साझा की जाएँगी, इसलिए उसका इंतज़ार है

  • “Panic! At the Disk 0” वाला section title थोड़ा-सा ही सही, अच्छा लगा

  • पीछे मुड़कर देखें तो यह बात स्वाभाविक लगती है, लेकिन दिलचस्प है कि test किए जा रहे distributed system को असल में काम होने का समय और क्रम रिपोर्ट करना चाहिए, ताकि wall-clock time इस्तेमाल करने के बजाय सिस्टम के external model के साथ ठीक-ठीक verify किया जा सके

    • यह इसलिए काम करता है क्योंकि strict serializability है। कमजोर consistency guarantees में ज़रूरी नहीं कि एक single global consistent timeline मौजूद हो
      यह एक दिलचस्प meta pattern है कि ज़्यादा कठिन काम कर लेने पर सिस्टम उल्टा सरल हो जाता है
      एक और उदाहरण के तौर पर, क्योंकि आपको मानना पड़ता है कि disk fail हो सकती है और recovery protocol शामिल करना पड़ता है, इसलिए पीछे रह गई replica की state sync करना लगभग “मुफ़्त” में मिल जाता है। वजह यह है कि यह बिल्कुल वही समस्या है जो पूरी disk corrupt होने पर आती है
    • मुझे यह classical approach लगता है। उदाहरण: https://lamport.azurewebsites.net/pubs/time-clocks.pdf

  • लेख में “Viewstamped Replication” paper का link अफ़सोसजनक रूप से broken है। https://pmg.csail.mit.edu/papers/vr-revisited.pdf पर connection refused मिलता है
    शायद http://pmg.csail.mit.edu/papers/vr-revisited.pdf की तरह https नहीं, http scheme होना चाहिए
    अब शुक्रवार शाम के लिए पढ़ने को कुछ मिल गया

    • जल्द ही ठीक कर दिया जाएगा
      VSR 2012 paper मेरे पसंदीदा papers में से एक है, और “Protocol-Aware Recovery for Consensus-Based Storage” भी सचमुच बहुत दमदार है
      पढ़ने का आनंद लें

  • यह सवाल पूरी तरह सीखने की इच्छा से पूछ रहा हूँ, उम्मीद है इसे गलत नहीं समझा जाएगा। मैं distributed systems नया-नया सीख रहा हूँ और deterministic simulation testing से बहुत प्रभावित हूँ
    TigerBeetle पर Jepsen report, संबंधित blog post, और GitHub workflow में Antithesis integration code को संक्षेप में देखने के बाद test coverage को बेहतर समझना चाहता हूँ
    मुख्य सवाल यह है कि Jepsen test suite ने जो bugs पकड़े, क्या Antithesis integration भी उन्हें पकड़ सकता था
    यह सवाल कुछ assumptions पर आधारित है, जो गलत भी हो सकते हैं। मुझे लगा था कि TigerBeetle पहले से ही internal test suite और Antithesis product से व्यापक रूप से test किया जा रहा है, और मेरी समझ थी कि Antithesis test suite Jepsen से ज़्यादा powerful है; इसलिए यह surprising लगा कि Jepsen ने ऐसा issue खोजा जिसे Antithesis नहीं पकड़ पाया
    मैं जानना चाहता हूँ कि मेरी समझ कहाँ गलत है। जैसे 1) क्या Antithesis test suite इस खास bug class को detect नहीं कर सकता था, 2) क्या system का यह हिस्सा अभी Antithesis tests से covered नहीं था, 3) या मैं Jepsen और Antithesis test suites की अलग-अलग strengths और goals को गलत समझकर apples और oranges की तुलना कर रहा हूँ

    • TigerBeetle blog post में यह अधिक विस्तार से है, लेकिन संक्षेप में, Antithesis में चल रहे tests काफ़ी thorough थे, फिर भी वे overlapping queries और out-of-order values का वही सटीक combination नहीं बना पाए; Jepsen generator ने वह combination hit कर दिया
      Jepsen test generator में भी लगभग निश्चित रूप से blind spots होंगे। इसलिए अलग-अलग generators design करना मददगार होता है
    • distributed systems की generative testing में आम तौर पर तीन components चाहिए होते हैं। पहला, system चलाने के लिए environment चाहिए। सबसे सरल रूप में यह real machines का cluster खड़ा करना है, लेकिन performance, external API responses पर control, determinism, और reproducibility बढ़ाने के लिए कुछ अधिक sophisticated बेहतर होता है। दूसरा, ऐसा load generator चाहिए जो environment में system से interesting काम करवाए। तीसरा, ऐसा auditor चाहिए जो load में चल रहे system के behavior को observe करे और तय करे कि वह specification से मेल खाता है या नहीं
      Antithesis मुख्य रूप से problem 1 को handle करता है, और virtual machines के साथ deterministic simulation environment देता है। Jepsen उसी समस्या को real machines इस्तेमाल करके, लेकिन operating system level पर failures inject करके handle करता है, और TigerBeetle का अपना VOPR database के साथ इस तरह design किया गया है कि पूरा cluster single thread में चल सके। ये तीनों approaches complementary हैं और हर एक की अपनी strengths हैं
      इस bug में निर्णायक हिस्सा 2 और 3 था—यानी ऐसा workload verifier और auditor लिखना जो bug को सच में trigger कर सके। यहाँ aphyr द्वारा लिखी गई TigerBeetle-specific Clojure code की 1,600 lines ने bug को trigger और detect किया, और बाद में TigerBeetle की equivalent test को भी इसे trigger करने के लिए patch किया गया। असल में यहाँ bug database से ज़्यादा VOPR में है। database में bugs होना स्वाभाविक है, और सिर्फ़ इच्छाशक्ति से bugs से बचा नहीं जा सकता। इसलिए ऐसी test strategy चाहिए जो अधिकतर bugs को trigger कर सके; जो bugs निकल जाते हैं, वे workload generator की कमी की ओर इशारा करते हैं
    • deterministic simulation testing का 90% मुख्य रूप से TigerBeetle का खुद बनाया deterministic simulator VOPR करता है। यह 1,000 dedicated CPU cores के पैमाने पर 24/7 चल रहा है
      Antithesis भी इस्तेमाल करते हैं, लेकिन deterministic simulation testing की second layer के रूप में
      query engine bug क्यों छूट गया, इसके लिए यह देखें: https://tigerbeetle.com/blog/2025-06-06-fuzzer-blind-spots-m...

  • क्या बड़े बैंक या securities exchanges TigerBeetle इस्तेमाल कर रहे हैं, यह जानने की जिज्ञासा है

    • राष्ट्रीय स्तर पर, Gates Foundation के साथ TigerBeetle को एक गैर-लाभकारी central bank switch में integrate किया जा रहा है, और यह system इस साल के अंत में Rwanda के National Digital Payments System 2.0 को चलाएगा [1]
      enterprise स्तर पर, TigerBeetle पहले से ही उन ग्राहकों के production में इस्तेमाल हो रहा है जो हर महीने 100 मिलियन से ज्यादा transactions process करते हैं, और हाल ही में यूरोप की 2 अरब डॉलर valuation वाली fintech unicorn के साथ उसका पहला contract हुआ है; अमेरिका में भी कुछ deals जल्द final होने वाली हैं। दुनिया भर में real-time transaction processing की ओर बढ़ने के trend [2] की वजह से, बेहतर performance के लिए TigerBeetle पर migrate करना चाहने वाली कंपनियों की दिलचस्पी काफी ज्यादा है
      सवाल का जवाब दें तो, Wall Street की एक काफी बड़ी brokerage Clear Street के कुछ founders ने TigerBeetle में invest [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
    • बैंक या exchange तो नहीं, लेकिन मैं एक बहुत बड़ी fintech company में काम करता हूँ और एक नए product में TigerBeetle इस्तेमाल कर रहा हूँ
    • अगर उनके पास ऐसा कोई customer होता, तो लगता है वे homepage पर उसका खूब प्रचार करते। अब तक homepage पर सबसे बड़ा endorsement किसी YouTuber से आया है। वह popular YouTuber जरूर है, लेकिन फिर भी YouTuber ही है