स्वतः पुनर्प्राप्ति

Arkvory विफल सेवा को स्वयं फिर से शुरू करता है और बिना किसी ऑपरेटर के रुका हुआ काम जारी रखता है। यह पृष्ठ बताता है कि क्या-क्या फिर से शुरू होता है, हर पुनर्प्राप्ति में कितना समय लगता है और कौन-सी समस्याओं के लिए अब भी आपकी ज़रूरत होती है। एक सर्वर उच्च उपलब्धता (high availability) वाला सिस्टम नहीं है: रीस्टार्ट कुछ समय के लिए कनेक्शन बाधित करता है, और क्लाइंट अपने ट्रांसफ़र जारी रखते हैं।

क्या अपने-आप फिर से शुरू होता है

हर सेवा प्लेटफ़ॉर्म के सेवा प्रबंधक के अधीन चलती है। API, वर्कर और बैकअप एजेंट तब अपनी प्रक्रिया समाप्त कर देते हैं जब वे सुरक्षित रूप से आगे नहीं बढ़ सकते। इसके बाद सेवा प्रबंधक एक नई प्रक्रिया शुरू करता है।

स्थिति	Linux (systemd)	Windows सेवाएँ	Docker Compose
क्रैश, kill, आउट ऑफ़ मेमोरी	10 सेकंड बाद रीस्टार्ट	10 सेकंड बाद रीस्टार्ट	इंजन बढ़ते ठहराव के साथ कंटेनर को फिर से शुरू करता है
रोकने के अनुरोध के बिना एग्ज़िट, एग्ज़िट कोड 0 के साथ भी	रीस्टार्ट	लॉन्चर एग्ज़िट को कोड 1 में बदल देता है, 10 सेकंड बाद रीस्टार्ट	रीस्टार्ट
स्टोरेज का स्वामित्व या लीज़ खो गया	एग्ज़िट 1, रीस्टार्ट	एग्ज़िट 1, रीस्टार्ट	एग्ज़िट 1, रीस्टार्ट
मुख्य थ्रेड हैंग	वॉचडॉग प्रक्रिया समाप्त करता है, रीस्टार्ट	वही	वही
शुरू में डेटाबेस अनुपलब्ध	एग्ज़िट 1, हर 10 सेकंड में रीट्राई	एग्ज़िट 1, हर 10 सेकंड में रीट्राई	एग्ज़िट 1, बढ़ते ठहराव के साथ रीट्राई
मशीन रीस्टार्ट होती है	सेवाएँ multi-user.target में सक्षम हैं	Automatic (Delayed Start)	कंटेनर इंजन के साथ। Docker Desktop: उपयोगकर्ता के साइन इन करने के बाद
आप सेवा रोकते हैं	यह अगले बूट तक रुकी रहती है	यह अगले बूट तक रुकी रहती है	docker compose stop रुका रहता है

स्वयं विफल होने वाला तैयारी जाँच (readiness check) किसी सेवा को फिर से शुरू नहीं करती। यह इसलिए विफल हो सकती है क्योंकि प्रक्रिया रुकने से पहले ड्रेन कर रही है, या क्योंकि स्टोरेज डायरेक्टरी का कोई फ़ोल्डर गायब है। रीस्टार्ट इन कारणों को ठीक नहीं करेगा।

Windows सेवाएँ

ग्राफ़िकल इंस्टॉलर और install.ps1 Arkvoryapi, Arkvoryworker और Arkvorybackup को पंजीकृत करते हैं, जो खाता NT AUTHORITY\LocalService साझा करते हैं, और प्रबंधित डेटाबेस के लिए डेटाबेस सेवा Arkvorydatabase को। Windows देखें।

• स्टार्ट प्रकार। API, वर्कर और बैकअप एजेंट Automatic (Delayed Start) इस्तेमाल करते हैं। डेटाबेस Automatic इस्तेमाल करता है। विलंबित शुरुआत का मतलब है कि सेवाएँ बूट के कुछ समय बाद शुरू होती हैं, उसी क्षण नहीं।
• रिकवरी क्रियाएँ। विफलता के बाद Windows सेवा को 10 सेकंड बाद फिर से शुरू करता है। यही क्रिया हर अगली विफलता पर दोहराई जाती है। विफलता काउंटर एक घंटे बाद रीसेट हो जाता है। रिकवरी क्रियाएँ तब भी लागू होती हैं जब प्रक्रिया किसी एरर कोड के साथ एग्ज़िट करती है।
• स्टॉप टाइमआउट। 120 सेकंड, ताकि चल रहा अनुरोध पूरा हो सके।
• लॉग। हर सेवा का आउटपुट logs\ में जाता है और 20 MiB पर 5 पुरानी फ़ाइलों के साथ रोटेट होता है।

किसी सेवा की रिकवरी क्रियाएँ दिखाएँ:

sc.exe qfailure Arkvoryapi

ग्राफ़िकल इंस्टॉलर को फिर से चलाने पर स्टार्ट प्रकार और रिकवरी क्रियाएँ बहाल हो जाती हैं। जो सेवा आपने खुद रोकी थी, वह रुकी रहती है।

Linux systemd यूनिट

पैकेज और install.sh arkvory-api, arkvory-worker और arkvory-backup बनाते हैं, और डेटाबेस प्रबंधित होने पर arkvory-database।

• Restart=always और RestartSec=10 API, वर्कर और बैकअप एजेंट को हर उस एग्ज़िट के बाद फिर से शुरू करते हैं जिसका अनुरोध आपने नहीं किया, एग्ज़िट कोड 0 सहित।
• StartLimitIntervalSec=0 रीस्टार्ट प्रयासों की सीमा हटा देता है, इसलिए systemd किसी विफल सेवा को कभी नहीं छोड़ता। गलत सेटिंग जैसी स्थायी खराबी हर 10 सेकंड में रीस्टार्ट की ओर ले जाती है, जब तक आप उसे ठीक नहीं करते।
• डेटाबेस यूनिट वही 10 सेकंड के साथ Restart=on-failure इस्तेमाल करती है।
• TimeoutStopSec=120 रुकती हुई सेवा को दो मिनट देता है।
• यूनिट multi-user.target के लिए सक्षम हैं।

systemctl is-enabled arkvory-api arkvory-worker arkvory-backup
systemctl status arkvory-api arkvory-worker arkvory-backup

नेटिव सेवाओं के लिए केवल systemd समर्थित है। किसी दूसरे init सिस्टम वाले सिस्टम पर Docker Compose इस्तेमाल करें।

Docker Compose

प्रोजेक्ट proanima-arkvory की सभी सेवाएँ restart: unless-stopped इस्तेमाल करती हैं। एक-बार के चरण initialize और migrate फिर से शुरू नहीं होते।

• API कंटेनर में हेल्थ चेक है: हर 10 सेकंड में यह हेल्थ कुंजी के साथ /health/ready पूछता है, 20 सेकंड की स्टार्ट अवधि के साथ। अस्वस्थ कंटेनर चिह्नित होता है, पर Docker उसे फिर से शुरू नहीं करता। वर्कर शुरू में स्वस्थ API की प्रतीक्षा करता है।
• कंटेनरों को रुकने के लिए 120 सेकंड मिलते हैं।
• कंटेनर इंजन बूट पर शुरू होना चाहिए। Linux पर systemctl is-enabled docker जाँचें। Arkvory इंजन नहीं बदलता।
• Windows पर Docker Desktop एक उपयोगकर्ता का एप्लिकेशन है। उपयोगकर्ता के साइन इन करने और Docker Desktop के शुरू होने से पहले कोई कंटेनर नहीं चलता। Start Docker Desktop when you sign in चालू करें। इसके बंद होने पर इंस्टॉलर और arkvory status चेतावनी देते हैं। ऐसे सर्वर के लिए जिसे साइन-इन के बिना शुरू होना चाहिए, नेटिव Windows सेवाएँ इस्तेमाल करें।

हैंग के बाद रीस्टार्ट

कोई प्रक्रिया बिना समाप्त हुए काम करना बंद कर सकती है: अनंत लूप, ब्लॉक करने वाला कॉल या नेटिव कोड में हैंग। सेवा प्रबंधक इसे नहीं देखता, क्योंकि प्रक्रिया अब भी मौजूद रहती है। इसलिए API, वर्कर और बैकअप एजेंट में से हर एक का अपना वॉचडॉग है।

1. मुख्य थ्रेड हर सेकंड एक बार काउंटर बढ़ाता है।
2. दूसरा थ्रेड हर सेकंड एक बार काउंटर जाँचता है।
3. जब काउंटर लगातार ARKVORY_WATCHDOG_SECONDS जाँचों तक नहीं हिला (डिफ़ॉल्ट रूप से 60), तो वॉचडॉग standard error पर stalledSeconds फ़ील्ड के साथ process.stalled रिकॉर्ड लिखता है और प्रक्रिया समाप्त कर देता है।
4. सेवा प्रबंधक प्रक्रिया को क्रैश के बाद की तरह फिर से शुरू करता है।

वॉचडॉग अपनी ही टिक गिनता है, घड़ी का समय नहीं। जब होस्ट सो जाता है या वर्चुअल मशीन रोक दी जाती है, तो दोनों थ्रेड रुक जाते हैं, और जागने के बाद कोई नकली ठहराव नहीं बनाया जाता। इसलिए एक हैंग पर अधिकतम 60 सेकंड और रीस्टार्ट के 10 सेकंड का खर्च आता है।

ARKVORY_WATCHDOG_SECONDS 10 से 3600 स्वीकार करता है। मान 0 वॉचडॉग बंद कर देता है। इसे केवल तब इस्तेमाल करें जब कोई डीबगर प्रक्रिया को रोकता है, क्योंकि सीमा से ज़्यादा समय तक रुकी प्रक्रिया फिर से शुरू कर दी जाती है। लंबा ब्लॉकिंग ऑपरेशन भी हैंग माना जाता है। अगर वॉचडॉग खुद शुरू न हो सके, तो सेवा process.watchdog_failed लिखती है और उसके बिना चलती रहती है। प्रबंधित PostgreSQL में कोई वॉचडॉग नहीं है। क्रैश के बाद उसका सेवा प्रबंधक उसे फिर से शुरू करता है। एनवायरनमेंट वेरिएबल देखें।

डेटाबेस सत्र या स्टोरेज स्वामित्व खो जाना

API डेटाबेस सत्र के ज़रिए साबित करता है कि स्टोरेज डायरेक्टरी का एकमात्र लेखक वही है। सत्र की हर 2 सेकंड में जाँच होती है, और 8 सेकंड के भीतर जवाब न देने वाली जाँच खोई हुई मानी जाती है। वर्कर उसी तरह अपनी भूमिका साबित करता है। चल रही प्रक्रिया के भीतर स्वामित्व कभी बहाल नहीं किया जाता, क्योंकि कोई दूसरी प्रक्रिया उसे अपने हाथ में ले चुकी हो सकती है।

जब स्वामित्व खो जाता है, उदाहरण के लिए PostgreSQL के रीस्टार्ट के बाद, प्रक्रिया:

1. api.ownership_lost या worker.ownership_lost लिखती है,
2. काम स्वीकार करना बंद करती है और ट्रांसफ़र रद्द करती है,
3. कोड 1 के साथ एग्ज़िट करती है।

सेवा प्रबंधक एक नई प्रक्रिया शुरू करता है, जो शुरू से सब कुछ फिर से जाँचती है। जब तक डेटाबेस डाउन रहता है, नई प्रक्रिया शुरू नहीं हो सकती, और API हर 10 सेकंड में एग्ज़िट और रीस्टार्ट होता है जब तक PostgreSQL जवाब नहीं देता। यह अपेक्षित है। इस बीच क्लाइंट को Retry-After के साथ 503 unavailable मिलता है। डेटाबेस दूर होने पर चल रहा बैकअप एजेंट एग्ज़िट नहीं करता। यह त्रुटि लॉग करता है और अपने पोलिंग अंतराल (डिफ़ॉल्ट रूप से 15 सेकंड) के बाद फिर से कोशिश करता है।

चल रहे काम का क्या होता है

क्रैश खुले कनेक्शन तोड़ देता है। जिस डेटा की पुष्टि हो चुकी थी, वह बना रहता है। आगे क्या होता है, यह काम के प्रकार पर निर्भर करता है।

काम	रीस्टार्ट के बाद
डाउनलोड	क्लाइंट range अनुरोध के साथ जारी रखता है। SDK और कमांड-लाइन क्लाइंट यह खुद करते हैं
मल्टीपार्ट अपलोड	दर्ज किए गए भाग सर्वर पर बने रहते हैं। क्लाइंट पूछता है कि कौन-से भाग मौजूद हैं और छूटे हुए भेज देता है। सत्र अपने बनने से 7 दिन तक खुला रहता है
पूरी फ़ाइल का एकल-अनुरोध अपलोड	क्लाइंट फ़ाइल को पहले बाइट से फिर से भेजता है
वर्कर द्वारा अपलोड पूर्ण करना	नीचे देखें
बैकअप	नीचे देखें
मिरर सिंक्रनाइज़ेशन	वर्कर हर लागू किए गए बदलाव के बाद अपनी स्थिति सहेजता है और फ़ाइल को पहले छूटे भाग से कॉपी करता है। विफलता के बाद यह 2 सेकंड प्रतीक्षा करता है, जो प्रयासों के बीच 5 मिनट तक दोगुना होता जाता है
अपडेट	इंस्टॉलर अपना लॉक और अपना जर्नल रखता है। यह खुद आगे नहीं बढ़ता। समस्या निवारण देखें

SDK और कमांड-लाइन क्लाइंट नेटवर्क विफलताओं और 408, 429, 502, 503 और 504 उत्तरों को सीमित संख्या में दोहराते हैं। दूसरे क्लाइंट को अपनी खुद की रीट्राई चाहिए। ट्रांसफ़र देखें।

पूर्णता जॉब। बड़ा अपलोड वर्कर द्वारा पूरा किया जाता है (SDK और कमांड-लाइन क्लाइंट यह 16 GiB से करते हैं)। वर्कर एक जॉब पर 30 सेकंड की लीज़ रखता है और उसे हर 2 सेकंड में नवीनीकृत करता है। वर्कर के क्रैश होने पर लीज़ 30 सेकंड के भीतर समाप्त हो जाती है, और फिर से शुरू हुआ वर्कर जॉब को फिर ले लेता है। एक जॉब अधिकतम 5 बार चलता है। विफलता के बाद यह 2 सेकंड प्रतीक्षा करता है, जो 60 सेकंड तक दोगुना होता जाता है। ये त्रुटियाँ जॉब को तुरंत समाप्त कर देती हैं: forbidden, invalid_input, integrity_mismatch और not_found। जिस जॉब ने सभी प्रयास खर्च कर दिए, उसे completion.attempts_exhausted रिकॉर्ड मिलता है। उसी अपलोड को दोबारा पूरा करने को कहने पर जॉब फिर कतार में लग जाता है। पूर्णता सहेजे गए बाइट जाँचती है, इसलिए इसे दोहराना सुरक्षित है।

उसी डेटाबेस पर दूसरा वर्कर स्टैंडबाय (worker.standby) के रूप में प्रतीक्षा करता है और हर 5 सेकंड में जाँचता है कि पहला चला गया है या नहीं।

बैकअप एजेंट। एजेंट 60 सेकंड की लीज़ रखता है (ARKVORY_BACKUP_LEASE_SECONDS) और उसे हर 20 सेकंड में नवीनीकृत करता है। क्रैश के बाद कोई दूसरा एजेंट, या फिर से शुरू हुआ वही एजेंट, समाप्त होने पर लीज़ ले लेता है, इसलिए बैकअप को अधिकतम एक मिनट तक प्रतीक्षा करनी पड़ती है। रुका हुआ जॉब उसी कुंजी के साथ फिर चलता है, अधिकतम 5 बार। नया कैप्चर मृत कैप्चर के लॉक छोड़ देता है। हार्टबीट के बिना 2 मिनट बाद चेतावनी agent_offline दिखती है। अपडेट के दौरान इंस्टॉलर पहले एजेंट रोकता है, और चल रहा बैकअप interrupted के रूप में समाप्त होकर फिर कतार में लग जाता है।

रेट सीमाएँ। प्रति पते के साइन-इन काउंटर प्रक्रिया में रहते हैं और रीस्टार्ट पर रीसेट हो जाते हैं। किसी खाते का बैकऑफ़ डेटाबेस में रहता है और बना रहता है।

शुरुआत में जाँच

हर प्रक्रिया सेवा देने से पहले अपना एनवायरनमेंट जाँचती है। विफल जाँच प्रक्रिया को एग्ज़िट कोड 1 और एक पंक्ति startup.failed (API) या worker.unavailable (वर्कर) के साथ समाप्त कर देती है। reason बिना सीक्रेट के कारण बताता है।

प्रक्रिया	क्या जाँचा जाता है
API	हर सेटिंग का मान मान्य है; संदेश वेरिएबल का नाम बताता है, कभी उसका मान नहीं। कुंजी फ़ाइल 1 MiB तक JSON के रूप में पढ़ी जाती है। अंतर्निहित TLS: प्रमाणपत्र और कुंजी पढ़े जाते हैं, मेल खाते हैं और समाप्त नहीं हुए हैं; HTTP पर कोई फ़ॉलबैक नहीं है। स्टोरेज डायरेक्टरी लिखने योग्य है। डेटाबेस जवाब देता है और उसके पास इस रिलीज़ के सभी माइग्रेशन हैं और किसी नए संस्करण का कोई नहीं। स्टोरेज डायरेक्टरी की storage-id फ़ाइल डेटाबेस में सहेजी गई पहचान के बराबर है। डेटाबेस को कोई दूसरा लेखक नहीं रखता
वर्कर	वही सेटिंग, डेटाबेस, स्टोरेज पहचान, और एकमात्र वर्कर का लॉक। दूसरा वर्कर स्टैंडबाय के रूप में प्रतीक्षा करता है
बैकअप एजेंट	स्टोरेज पहचान, स्कीमा संख्या, और यह कि बैकअप स्टोरेज (vault) स्टोरेज डायरेक्टरी से अलग है। गायब या अनमाउंटेड vault घातक नहीं है। एजेंट इसे चेतावनी के रूप में बताता है

अपडेट के बाद इंस्टॉलर लगातार तीन सफल तैयारी उत्तरों और चल रहे वर्कर की प्रतीक्षा करता है। फिर यह बैकअप एजेंट की हार्टबीट के लिए लगभग 90 सेकंड प्रतीक्षा करता है। गायब एजेंट केवल चेतावनी है और अपडेट को कभी रोलबैक नहीं करता।

किस चीज़ के लिए अब भी आपकी ज़रूरत है

स्वतः पुनर्प्राप्ति प्रक्रिया की विफलताओं को कवर करती है। इनके लिए ऑपरेटर चाहिए:

• स्थायी खराबी। गलत सेटिंग, पहुँच से बाहर डेटाबेस, भरी हुई डिस्क या गलत अनुमतियाँ सेवा को हर 10 सेकंड में बिना सफलता के फिर से शुरू कराती रहती हैं। startup.failed पढ़ें और कारण ठीक करें। समस्या निवारण देखें।
• विफल अपडेट। रुका हुआ अपडेट तब तक अपना लॉक और जर्नल रखता है जब तक आप recover नहीं चलाते।
• क्षतिग्रस्त बैकअप। verify_failed और vault_unavailable के लिए किसी व्यक्ति की ज़रूरत है। एजेंट vault को अपरिवर्तित रखता है।
• प्रमाणपत्र। Arkvory नवीनीकृत प्रमाणपत्र फ़ाइलों को बिना रीस्टार्ट के पढ़ता है (डिफ़ॉल्ट रूप से हर 300 सेकंड में), पर आपके टूल को उन्हें नवीनीकृत करना होगा।
• रुकी हुई सेवा। जो सेवा आपने रोकी, वह रुकी रहती है।
• प्लेटफ़ॉर्म। Docker को बूट पर शुरू होना चाहिए। PostgreSQL के मुख्य संस्करण, Node.js और ऑपरेटिंग सिस्टम आप अपडेट करते हैं।
• खोया हुआ सर्वर या डिस्क। कोई फ़ेलओवर नहीं है। बैकअप से पुनर्स्थापित करें। बैकअप देखें।

संबंधित पेज

• मॉनिटरिंग
• समस्या निवारण
• Windows
• एनवायरनमेंट वेरिएबल