Litestream में अब तेज़ point-in-time restore संभव है

• Litestream एक SQLite-आधारित full-stack application का बैकअप सुरक्षित रूप से object storage में लेता है, और इस बार इसमें अब तक का सबसे बड़ा फीचर बदलाव हुआ है
• पहले की संरचना की तुलना में अधिक कुशल LTX file format और compaction तकनीक अपनाई गई है, जिससे तेज़ और प्रभावी point-in-time restore संभव हो गया है
• Conditional write का उपयोग करने वाले नए तरीके से leader singleton और read replica फीचर्स का implementation सरल हो गया है
• जल्द ही VFS-आधारित read-replica layer उपलब्ध होगी, जिससे अलग-अलग environments में आसानी से scale करना संभव होगा
• काफ़ी बेहतर की गई संरचना के कारण कई databases को एक साथ sync करना संभव हो गया है, जिससे scalability बढ़ी है

---

Litestream का परिचय और महत्व

• Litestream एक open source tool है, जो SQLite पर आधारित विभिन्न full-stack applications का बैकअप सुरक्षित रूप से object storage में लेने की सुविधा देता है
• SQLite की embedded प्रकृति के कारण data के एक सर्वर पर निर्भर रहने की समस्या को यह हल करता है, और server failure की स्थिति में भी data recovery को आसान बनाता है

Litestream का विकास

• SQLite का उपयोग आसान बनाने के लिए Litestream 2020 में सामने आया
• Litestream, SQLite application से अलग process के रूप में चलता है और WAL checkpointing process की जगह लेकर data changes को real time में S3 जैसे object storage तक stream करता है
• सर्वर खो जाने पर भी object storage से database को उसकी latest state में प्रभावी ढंग से restore किया जा सकता है
• इसके बाद LiteFS नाम का प्रोजेक्ट आगे विकसित किया गया, जिसने read replica और basic failover (Primary Failover) तक support दिया, ताकि SQLite को Postgres जैसी आधुनिक deployment architecture में इस्तेमाल किया जा सके
• LiteFS और Litestream दोनों के अपने फायदे हैं, लेकिन Litestream deployment और उपयोग में आसान होने के कारण अधिक व्यापक रूप से इस्तेमाल होता है

प्रभावी point-in-time restore

• Litestream का पुराना design सभी changes को लगातार रिकॉर्ड करके S3 पर भेजता था, लेकिन जब data में बार-बार बदलाव होते हों तो restore के समय यह अक्षम साबित होता था
• LiteFS में transaction-aware approach लाई गई, जो changed page ranges को sort करके रिकॉर्ड करने वाले LTX file format का उपयोग करती है
• कई LTX files को आसानी से merge (compaction) करके केवल latest version बचाए रखने के तरीके से data restore की speed और efficiency में बड़ा सुधार हुआ
• यह संरचना LSM tree जैसी है
• नए Litestream में भी LTX files और compaction approach अपनाई गई है, जिससे बिना ज़्यादा duplicate storage के सटीक point-in-time restore संभव हो गया है

CASAAS: Compare-and-Swap as a Service

• Litestream को ऐसा काम करना चाहिए कि SQLite application को backup system की जानकारी न हो, लेकिन failure जैसी स्थिति में process बंद हो जाए तो data changes छूट सकते हैं
• इस समस्या को हल करने के लिए generation की अवधारणा लाई गई, जो हर backup session और उससे जुड़े log stream को uniquely identify करती है
• LiteFS में single leader सुनिश्चित करने के लिए Consul का उपयोग किया गया था, लेकिन external dependency की ज़रूरत के कारण Litestream ने S3 जैसे object storage की conditional write capability से single replication path (singleton) को सरल तरीके से implement किया
• इसके चलते ephemeral node environments में भी बिना भ्रम के स्थिर operation संभव हो गया है

हल्का read replica फीचर

• LiteFS transaction awareness के लिए FUSE filesystem का उपयोग करता है, लेकिन इससे complexity और adoption burden बढ़ता है
• इसे कम करने के लिए LiteVFS नाम का SQLite Virtual Filesystem(VFS) extension module डिज़ाइन किया गया, ताकि FUSE के बिना भी यह अलग-अलग environments में काम कर सके
• आगे चलकर Litestream में भी यही VFS-आधारित layer लागू की जाएगी, जो S3 जैसे object storage से pages को सीधे fetch और cache करने वाली read-replica layer देगी
• यह local SQLite जितना तेज़ नहीं होगा, लेकिन caching और prefetching strategy के जरिए कई use cases में संतोषजनक performance मिलने की उम्मीद है

open source और उपयोगिता

• Litestream पूरी तरह open source है और Fly.io पर निर्भर नहीं है, इसलिए इसे कहीं भी इस्तेमाल किया जा सकता है
• एक process में बड़ी संख्या में databases को sync करने की सुविधा जुड़ गई है, जिससे सैकड़ों से हज़ारों databases का backup/replication प्रभावी ढंग से किया जा सकता है

SQLite के साथ निरंतर सह-विकास

• SQLite उद्योग में बदलावों के बीच भी लगातार नए use cases पैदा करने वाला एक मज़बूत database है
• हाल के LLM-आधारित code generation agents जैसे क्षेत्रों में, real-time data rollback और branching महत्वपूर्ण होते जा रहे हैं, इसलिए Litestream की उन्नत point-in-time restore क्षमता एक अहम आधार बन सकती है
• आगे चलकर यह बेहतर architecture rollback, fork, automated agent support जैसी विस्तारित क्षमताओं में भी योगदान देगा
• नया Litestream पुराने design की तुलना में बेहतर है और scalability व usability दोनों को मज़बूत करता है

[xguru]

Litestream - SQLite streaming replication tool
मैं server-side SQLite पर पूरी तरह दांव लगा रहा हूँ

[GN⁺]

Hacker News राय

• कोड रिपॉजिटरी का रास्ता ढूंढ लेने का अनुभव साझा किया गया। 2 साल पहले litestream और litefs इस्तेमाल करते समय असुविधाएँ थीं, लेकिन इस बार लगता है कि ज़्यादातर समस्याएँ हल हो गई हैं। अब database में litestream को बेझिझक लागू किया जा सकता है और multiple writer की समस्या को लेकर चिंता कम हुई है। read replica FUSE layer के फ़ायदों को लेकर भी उम्मीद है। संबंधित pull request में lease acquisition तरीके का परिचय दिया गया है (अगर lease पहले से मौजूद है, तो नया process 1 सेकंड के अंतराल पर retry करता है, जिससे तेज़ rolling restart संभव होता है)। इसे एक practical approach माना गया।

• लगता है कि नए Litestream में वे सभी फीचर आ गए हैं जिनकी मैं उम्मीद कर रहा था; इसे लेकर उत्साह और रोमांच है।

• इस बहुत ही smart और deployment को सरल बनाने वाले तरीके पर सकारात्मक नज़र है। हज़ारों SQLite DB के backup की ज़रूरत वाले माहौल में अब तक fanotify और SQLite Backup API से एक अस्थायी जुगाड़ बनाया था। अगर wildcard replication बहुत सारी files को support करता है, तो Litestream पर स्विच करना चाहूँगा।

• LTX पर जाने के बाद, एक directory में सैकड़ों या हज़ारों database होने पर भी /data/*.db replication संभव हो गया है। इस बिंदु पर ज़ोर दिया गया कि पहले यही निर्णायक बाधा थी। अब multi-tenant environment में हर user के database के लिए मनचाहा point-in-time recovery, data download और migration संभव हो सकेगा—इसे लेकर सकारात्मक उम्मीद जताई गई।

• ben को धन्यवाद देते हुए वास्तविक उपयोग का अनुभव साझा किया गया। करीब 1 साल से अधिक समय से write-heavy internal use case (compression के बाद लगभग 12GB) में litestream को production में चला रहे हैं, और मासिक लागत बेहद कम है (azure के हिसाब से कुछ सौ won के बराबर)। नए बदलाव लागू करने का इंतज़ार है।

• Fly के SQLite-आधारित developer experience के और polished होने की उम्मीद है। अभी कमी यह लगती है कि अपना UI और CLI पर्याप्त नहीं है, इसलिए शुरुआती database को Fly Machine पर सेट करना अपेक्षा से अधिक चरणों वाला काम है। fly console SQLite के साथ ठीक से integrate नहीं होता और अलग machine पर चलता है, इसलिए data वाले volume तक पहुँच नहीं पाता। अंततः fly ssh console —pty से सीधे उस machine में जाना पड़ता है—यह असुविधाजनक है। SQLite-आधारित web app आम तौर पर छोटे पैमाने के होते हैं, इसलिए कमाई के लिए बहुत बड़ी संख्या में उन्हें चलाना पड़ता है।

  • Rails 8 और SQLite के संयोजन को लेकर व्यक्तिगत पसंद की दिशा क्या है—क्या हाल में यह Postgres से भी ज़्यादा पसंद आने लगा है? ऐसा सवाल पूछा गया।

• Litestream के बारे में अभी-अभी पढ़ना शुरू किया था और सही समय पर यह पोस्ट दिखी। VPS पर Sqlite इस्तेमाल कर रहा हूँ और Litestream अपनाने पर विचार कर रहा हूँ। सवाल यह है कि क्या Litestream process चलते रहने के दौरान database को किसी खास समय बिंदु पर restore किया जा सकता है? यह जिज्ञासा भी है कि auto-checkpointing process के down होने पर WAL को consume कर लेता है, तो क्या कोई ऐसा समयखंड होता है जिसे restore नहीं किया जा सकता (उदाहरण: process 2:00~3:00 के बीच बंद रहा; 1:55 या 3:05 पर restore संभव है, लेकिन 2:00~3:00 के बीच की recovery जानकारी गायब हो जाती है)?

  • समझाया गया कि Litestream WAL segments को निश्चित समय इकाइयों में स्टोर करता है। डिफ़ॉल्ट रूप से WAL changes हर सेकंड भेजे जाते हैं, इसलिए (configured retention period के भीतर) इच्छित समय पर सेकंड-स्तरीय point-in-time recovery संभव है।

  • DST (daylight saving time) हैंडलिंग को लेकर सवाल उठाया गया। यूरोप में 30 मार्च को 2:00 से सीधे 3:00 पर समय कूदने की स्थिति में यह कैसे काम करेगा?

• पहले dynamodb-आधारित DonutDB नाम का sqlite vfs बनाया था—ऐसा अनुभव साझा किया गया। S3 में CAS(Content Addressable Storage) क्षमता जुड़ने के बाद DonutDB को S3-supporting version के रूप में नया बनाने की सोच थी, लेकिन अब lightstream यह support दे रहा है, इसलिए खुद बनाने की ज़रूरत नहीं रही—इस पर खुशी जताई गई। नए tool को इस्तेमाल करने की उम्मीद है।

  • S3 में CAS(Content Addressable Storage) जुड़ने की बात पर official material या reference link माँगा गया; यह भी जानना चाहा गया कि CAS का अर्थ सही समझा गया है या नहीं।

• App deploy करते समय पुराने तरीके में नया server instance उठाकर health check pass होने पर traffic switch किया जाता था और फिर पुराने server को बंद किया जाता था। याद किया गया कि इस transition के दौरान database changes खो जाने की समस्या थी। सवाल उठाया गया कि क्या इस बदलाव से वह समस्या हल हो गई है।

  • राय दी गई कि server को एक ephemeral web server instance की तरह नहीं, बल्कि production database के नज़रिए से देखना चाहिए। python/sqlite web app deploy करते समय पूरी machine बदलने के बजाय package upgrade करके systemd service restart की जाती है। downtime कम करना हो तो SO_REUSEPORT जैसी चीज़ों से transition पर विचार किया जा सकता है। इस दौरान नया और पुराना process database को एक साथ इस्तेमाल कर सकते हैं, लेकिन अगर DB schema change शामिल हो, तो कुछ downtime लगभग अपरिहार्य है। यह बात दूसरे DB पर भी लागू हो सकती है।

  • यह आसानी से हल होने वाली समस्या नहीं है—ऐसी राय दी गई। अभी भी केवल एक writer ही lease ले सकता है। नई service चलने पर भी उसे lease तभी मिलेगा जब पुराना writer नीचे आएगा। writer replacement के लिए tools उपलब्ध हैं, लेकिन request waiting या छोटा downtime पूरी तरह टाला नहीं जा सकता।

• अगर litestream से user-आधारित बहुत सारे database replicate करने हों (जो docs में बताया गया मुख्य use case है), तो runtime पर नए database dynamically जोड़ने का तरीका क्या होगा—ऐसा सवाल पूछा गया। अनुभव साझा किया गया कि अभी config file static है और real-time API नहीं मिला।

  • कहा गया कि यह समस्या अंततः हल हो जाएगी। नई SQLite detection logic थोड़ी tricky है, लेकिन असंभव नहीं। तब तक इसे library के रूप में आसानी से इस्तेमाल किया जा सकता है—ऐसी जानकारी दी गई।