Jepsen: TigerBeetle 0.16.11
(jepsen.io)- TigerBeetle एक double-entry bookkeeping के लिए विशेष रूप से बनाया गया OLTP डेटाबेस है, जिसे सुरक्षा और तेज़ processing speed को लक्ष्य बनाकर विकसित किया गया है
- यह Viewstamped Replication consensus protocol और strong serializability मानदंड का समर्थन करता है, और high-contention, high-throughput workloads के लिए अनुकूलित संरचना रखता है
- इसका डिज़ाइन और testing प्रक्रिया fault tolerance और failure recovery पर बहुत ध्यान देती है, और विभिन्न failure scenarios में बिना data loss के काम करने का लक्ष्य रखती है
- upgrade, testing, operational model, cluster failure recovery आदि में विभिन्न bugs और performance issues Jepsen testing से मिले, जिससे उनके समाधान की क्षमता बेहतर हुई
- नवीनतम version में ring-based replication performance, client error handling, logging और query correctness सहित कई improvements और bug fixes दिए गए हैं
TigerBeetle परिचय
- TigerBeetle double-entry bookkeeping के लिए विशेष रूप से बना online transaction processing (OLTP) database है
- यह Viewstamped Replication(VR) consensus protocol पर आधारित strong serializability की गारंटी देता है, और केवल account तथा account के बीच transfer data को store करता है
- यह banking internal switch, brokerage, ticketing, power metering जैसे उच्च transaction volume और भारी concurrency contention वाले environments के लिए उपयुक्त है
- इसकी संरचना ऐसी है कि एक single node(Core) सभी write operations को संभालता है, इसलिए यह horizontal scaling (scale-out) नहीं बल्कि vertical scaling (scale-up) पर केंद्रित है
- batch processing, IO parallelization, fixed schema जैसी hardware-friendly optimizations के माध्यम से single-node throughput को अधिकतम करने का लक्ष्य रखता है
Failure recovery और fault tolerance
- TigerBeetle memory, process, clock, storage और network faults के लिए explicit model और recovery procedures प्रदान करता है
- data durability इस तरह सुनिश्चित की जाती है कि यदि केवल एक replica भी जीवित हो, तब भी data loss न हो
- यदि सभी replicas में records corrupt हो जाएँ, तो यह सुरक्षित रूप से रुक जाता है
- यह system hardware/software failures, clock skew, disk corruption, network delay/loss/duplication जैसी विभिन्न failures को मानकर चलता है
- इसमें Viewstamped Replication और Protocol-Aware Recovery तकनीक, data block checksum, तथा multiple replica storage लागू किए गए हैं
- runtime verification (assertion) का उपयोग करके error या bug होने पर नुकसान को न्यूनतम किया जाता है
Upgrade तरीका
- binary में current version और कई previous versions का code शामिल होता है
- upgrade केवल binary बदलने से किया जा सकता है
- cluster के भीतर सभी nodes अपने-आप rolling तरीके से version बदलते हैं, जिससे user intervention न्यूनतम रहता है
- यह इस बात को रोकता है कि किसी खास version में committed operation किसी दूसरे version में duplicate commit हो जाए, जिससे state inconsistency को रोकने में मदद मिलती है
Time model
- यह VR view और operation number पर आधारित logical clock के साथ-साथ hybrid physical clock (physical time) का भी उपयोग करता है
- leader सभी replicas का POSIX time इकट्ठा करता है और error range के भीतर cluster को आपस में sync करता है
- यदि clock synchronization 60 seconds से अधिक समय तक विफल रहे, तो service deny कर दी जाती है
- timestamp की इकाई "Unix epoch के बाद nanoseconds" है, लेकिन वास्तविक POSIX time से 27 seconds का अंतर पाया जाता है
- leap second या negative time adjustment के समय internal clock के धीमा होने की स्थिति भी होती है
Data model
- यह केवल दो data types को support करता है: account और transfer
- प्रत्येक field fixed-size है, immutable principle का पालन करती है, और unsigned int आधारित डिज़ाइन रखती है
- account को user-defined 128-bit id, ledger, flags, creation time, और custom fields से परिभाषित किया जाता है
- transfer में debit/credit account id, code, amount, custom fields आदि शामिल होते हैं
- transfer को immediate execution (single-step) या two-step (reserve/execute negotiation) दोनों रूपों में process किया जा सकता है
- pending transfer को cancel या expire किया जा सकता है
- special transfers के माध्यम से account close/reopen भी किया जा सकता है
Operational model और transactions
- client data state update या query के लिए एक single request(batch) unit पर काम करता है
- request के भीतर हर event को क्रमवार और atomic transaction के रूप में process किया जाता है
- repeat execution, multi-request transactions, interactive queries आदि समर्थित नहीं हैं
- यह Strong Serializability और strong session consistency प्रदान करता है
- प्रत्येक operation की success/failure, error code return, और chain (subtransaction) feature के माध्यम से complex processing का समर्थन करता है
Jepsen test design
- Jepsen library के माध्यम से property-based testing और fault injection किया गया
- LXC, EC2 जैसी विभिन्न environments में 3 से 6-node clusters पर experiments किए गए
- data model constraints के कारण पारंपरिक list/set consistency verification कठिन था, इसलिए total order of operations का उपयोग करके state/time consistency verify की गई
- timestamp-based consistency checks, model verification, simulation आदि जैसे एक-दूसरे को पूरक तरीके इस्तेमाल कर errors खोजे गए
Model verification और operation generation
- 1600+ lines वाले single-threaded state machine model से TigerBeetle के व्यवहार की correctness को विस्तार से जाँचा गया
- विभिन्न error conditions (duplicate id, discontinuous timestamp, balance constraints आदि) और linked chains के लिए reasoning और rollback handling की गई
- verification efficiency के लिए operation/id generation, state updates, और probabilistic query combinations जैसे विभिन्न तरीकों का उपयोग किया गया
Fault injection
- process crash(SIGKILL), pause(SIGSTOP), network partition, clock changes जैसे मूल failure scenarios शामिल थे
- version upgrade, file corruption simulation, और केवल कुछ replicas में partial corruption जैसी सूक्ष्म storage fault injection भी की गई
- zigzag (helical) disk corruption जैसे अनेक scenarios के माध्यम से data loss की संभावना न्यूनतम होने की जाँच की गई
प्रमुख bug cases और improvements
Request timeout handling की समस्या (#206)
- TigerBeetle के डिज़ाइन में client requests कभी timeout नहीं होतीं; cluster से response मिलने तक अनंत retry होता है
- व्यवहार में Java आदि clients asynchronous operations के दौरान timeout exception दे सकते हैं, इसलिए application को बाहरी timeout लगाना पड़ सकता है
- network errors या definite errors को अस्पष्ट रूप से छिपाने वाली इस डिज़ाइन के कारण clear failures और uncertain errors में अंतर करना कठिन होता है
- Jepsen ने failure type (definite/uncertain) के अनुसार return behavior और retry option जोड़ने की सिफारिश की
Client error से JVM crash (#2435)
- timeout को bypass करने के लिए thread/asynchronous wrapping ने JVM segfault समस्या पैदा की
- Java client में ठीक से initialize न किए गए field को refer करने के कारण यह हुआ, जिसे 0.16.12 में ठीक किया गया
Session expiry पर client crash (#2484)
- excessive sessions के कारण client forcefully terminate होने की समस्या थी
- 0.16.13 से इसे error return approach में बदलकर सुधारा गया
Single-node failure पर latency spike (#2739)
- ring-based replication की कमजोरी के कारण कुछ nodes fail होने पर overall response time बहुत बढ़ जाता था
- कारण: सामान्य रूप से primary अगले node को एक-एक hop में message भेजता है, लेकिन कुछ nodes fail होने पर ack न मिलने से wait होता था
- 0.16.30 के बाद reverse-direction replication और dynamic ring topology जैसी तकनीकें जोड़कर failure के समय response delay को काफी कम किया गया
Java client Header API bug (#2495)
- empty response batch के लिए singleton object उपयोग करने से header और timestamp गलत तरीके से share होने की समस्या हुई
- data correctness पर इसका असर नहीं था, लेकिन Header API result corrupt हो जाता था; इसे 0.16.14 में ठीक किया गया
Query results missing (#2544)
- 0.16.13 version में
query_accounts,query_transfersआदि के कुछ results missing होने का bug report हुआ; responses केवल सही prefix तक सीमित रह जाते थे
निष्कर्ष
- TigerBeetle finance और accounting domains में उच्च safety और fault tolerance की आवश्यकता वाले environments के लिए विशेष रूप से उपयुक्त है
- Jepsen series testing से resilience, consistency, operational model और performance से जुड़े कई मुद्दे सामने आए
- सक्रिय सहयोग के माध्यम से failure recovery, client error handling, replication और upgrade automation जैसे क्षेत्रों में व्यावहारिक सुधार किए गए
- नवीनतम version में बेहतर failure handling, connection/response guarantees, और operational consistency के साथ उच्च स्तर की reliability प्रदान की गई है
(इस सामग्री का कुछ हिस्सा Github, आधिकारिक TigerBeetle दस्तावेज़, Jepsen test report आदि विभिन्न open source स्रोतों के आधार पर तैयार किया गया है)
1 टिप्पणियां
Hacker News राय
Fuzzer Blind Spots (Meet Jepsen!) लेख भी संदर्भ के लिए उपयोगी है, https://tigerbeetle.com/blog/2025-06-06-fuzzer-blind-spots-meet-jepsen/ की ओर संकेत
TigerBeetle की reliability और scalability पर किसी भी दावे को हमेशा अंत में Jepsen रिपोर्ट से सत्यापित करने का अपना अनुभव साझा किया, और इस रिपोर्ट में कई issues मिलने के बाद उन्हें तेज़ी से ठीक करने तथा आगे ऐसे bugs दोबारा न हों इसके लिए internal test suite को भी मज़बूत करने वाला engineering approach अच्छा लगा; अगर यही रवैया रहा तो उम्मीद है कि 10 साल बाद financial-specialized database क्षेत्र में यह ‘बस Postgres इस्तेमाल करो’ जैसी default स्थिति तक पहुँच सकता है; aphyr के शानदार काम से बहुत कुछ सीखने की बात भी कही
TigerBeetle को aphyr द्वारा validate किया जाना और उसका अपने वादों पर खरा उतरना देखकर खुशी जताई, और यह उम्मीद भी कि सही approach से सचमुच सही नतीजे मिल सकते हैं; साथ ही पूछा कि वास्तविक production environments में Account या Transfer के अलावा बाकी data अक्सर external systems और अलग databases में रहता है, तो ऐसे कम भरोसेमंद external systems और TigerBeetle के बीच consistency तथा recovery व्यवहार में कैसे संभाली जाती है
राय यह थी कि यदि Jepsen का fuzzer blind spot पोस्ट पढ़ा हो, तो यह TigerBeetle रिपोर्ट और भी दिलचस्प लगेगी; JNI वाला segfault case शायद Rust जैसी memory-safe languages के इस्तेमाल से बचाया जा सकता था, लेकिन memory safety के संदर्भ में TigerBeetle का Zig/TigerStyle approach भी अच्छा प्रमाण देता है
"Panic! At the Disk 0" सेक्शन के शीर्षक की चतुराई पर हल्की-सी golf clap वाली प्रशंसा
Jepsen-प्रमाणित इस विस्तृत रिपोर्ट से गहरा प्रभाव पड़ने की बात कही; अभी v1.0 रिलीज़ से पहले ही उत्साह बहुत अधिक है, और founders का thread में सक्रिय होकर insights साझा करना भी अलग से सराहा गया
distributed systems testing में यह दिलचस्प लगा कि सही validation के लिए system के भीतर घटनाओं का क्रम/समय खुद system द्वारा report किया जाना और उसे external model से ठीक-ठीक मिलाया जाना मूलभूत आवश्यकता है; और यह बात ‘स्पष्ट रूप से स्वाभाविक’ लगी
Jepsen रिपोर्ट, संबंधित ब्लॉग, और Antithesis integration code आदि देखने के बाद testing के दायरे और प्रभाव को समझने के उद्देश्य से पूछा गया कि TigerBeetle पहले से Antithesis के साथ भी व्यापक testing करता है, फिर Jepsen ने जो bug पकड़ा वह Antithesis से कैसे छूट गया; Antithesis और Jepsen testing में क्या अंतर है, और internal testing coverage अंततः कैसे भिन्न है, इस पर ठोस सवाल किया गया
TigerBeetle में रुचि जताते हुए यह अजीब लगा कि client docs में C या Zig client नहीं दिखता; चूँकि यह स्वयं Zig में लिखा गया है, इसलिए पूछा गया कि क्या ऐसा client मौजूद नहीं है या अभी development में है
यह जानने की उत्सुकता जताई गई कि क्या TigerBeetle का उपयोग पहले से बड़े banks या brokerages में हो रहा है