मिरर और दूसरी साइट

एक मिरर किसी Arkvory इंस्टॉलेशन पर बनी एक रिपॉज़िटरी है जो दूसरे इंस्टॉलेशन, यानी स्रोत, की रिपॉज़िटरी की रीड-ओनली प्रति है। मिरर इंस्टॉलेशन HTTPS के ज़रिए स्रोत से बदलाव खींचता है। यह अपना डेटाबेस, अपनी स्टोरेज, अपने accounts और अपनी keys रखता है।

किसी मिरर का उपयोग दूसरे स्थान से डाउनलोड परोसने और ऐसी दूसरी साइट रखने के लिए करें जो स्रोत खो जाने पर कार्यभार सँभाल सके। मिरर स्रोत का बैकअप नहीं है, और यह स्वचालित high availability नहीं है। स्विच आप स्वयं करते हैं। अन्य सुरक्षाओं के लिए बैकअप और रीड गेटवे देखें।

मिरर क्या है

मिरर किए गए रिपॉज़िटरी के लिए, मिरर इंस्टॉलेशन कॉपी करता है:

• प्रकाशित फ़ाइलें, उनके बाइट और स्रोत पर मौजूद वही artifact IDs के साथ।
• Labels, metadata और collections।
• UPack पंजीकरण, stages और वर्तमान फ़ाइल पथ।
• रिपॉज़िटरी की container images, Git LFS objects और npm packages।
• हटाना। स्रोत पर हटाई गई फ़ाइल मिरर पर हटा दी जाती है।

ID से, package (version, range, stage) से और फ़ाइल पथ से डाउनलोड मिरर पर वैसे ही उत्तर देते हैं जैसे अंतिम सिंक्रनाइज़ेशन पर स्रोत पर देते थे। स्रोत बंद होने पर भी वे काम करते रहते हैं।

मिरर कॉपी नहीं करता:

• Accounts, groups, keys और grants। मिरर के अपने होते हैं, और वे स्वतंत्र हैं: स्रोत पर कुंजी निरस्त करने से मिरर पर असर नहीं पड़ता।
• वे references जो फ़ाइलों को cleanup से बचाते हैं, builds के attachments, audit trails और storage policies।
• पहले सिंक्रनाइज़ेशन से पहले का फ़ाइल पथ इतिहास। मिरर पर labels और paths के revision numbers उसके अपने होते हैं।

Clients मिरर किए गए रिपॉज़िटरी में नहीं लिख सकते। अपलोड, label परिवर्तन, फ़ाइल पथ, stages, deletion और उसमें promotion को mirror_read_only कारण के साथ HTTP 409 मिलता है। मिरर इंस्टॉलेशन की अन्य रिपॉज़िटरियाँ सामान्य रूप से काम करती हैं। मिरर किए गए रिपॉज़िटरी में storage policies नहीं चलतीं, और वहाँ केवल सिंक्रनाइज़ेशन हटाता है।

मिरर सेट अप करें

आपको स्रोत पर एक कुंजी और मिरर पर एक कमांड चाहिए।

स्रोत पर कुंजी बनाएँ

मिरर को ऐसी कुंजी चाहिए जो केवल स्रोत रिपॉज़िटरी पढ़ सके। write key की ज़रूरत नहीं है।

1. स्रोत पर, recovery key या operator key के साथ सेवा एक्सेस खोलें।
2. सेवा खाता बनाएँ चुनें, और रिपॉज़िटरी अनुमतियाँ में रिपॉज़िटरी जोड़ें। मिरर को जिन अनुमतियों की ज़रूरत है उन्हें भरने के लिए पढ़ने का प्रीसेट चुनें। इनमें artifact.list, artifact.read, content.read, annotation.read, asset.read और package.read शामिल हैं।
3. कुंजी जारी करें चुनें, secret कॉपी करें, मैंने सीक्रेट सहेज लिया है पुष्टि करें और कुंजी सक्रिय करें चुनें। सक्रिय न की गई कुंजी 15 मिनट में समाप्त हो जाती है।
4. secret को मिरर सर्वर पर एक फ़ाइल में सहेजें। फ़ाइल में केवल कुंजी होती है, एक पंक्ति में, 16 से 4000 मुद्रण योग्य अक्षर। इसे केवल root या Administrators समूह पढ़ सकता है।

स्रोत में change feed वाली रिलीज़ होनी चाहिए। अगले चरण का कमांड इसे जाँचता है।

मिरर पर रिपॉज़िटरी अटैच करें

मिरर पर नया, खाली रिपॉज़िटरी नाम इस्तेमाल करें। सिंक्रनाइज़ेशन रिपॉज़िटरी को स्रोत के बराबर बनाता है, लेकिन जो स्रोत में कभी नहीं था उसे कभी नहीं हटाता।

sudo arkvory configure --root /opt/proanima-arkvory \
  --mirror releases \
  --mirror-upstream https://arkvory.example \
  --mirror-token-file /root/mirror-releases.key

$root = 'C:\ProgramData\ProAnima\Arkvory'
& 'C:\Program Files\ProAnima\Arkvory\arkvory.ps1' configure --root $root `
  --mirror releases --mirror-upstream https://arkvory.example `
  --mirror-token-file C:\secure\mirror-releases.key

विकल्प	अर्थ
--mirror NAME	इस इंस्टॉलेशन पर रिपॉज़िटरी। 1–64 अक्षर: छोटे अक्षर, अंक, _ और -, किसी अक्षर या अंक से शुरू
--mirror-upstream URL	स्रोत का ओरिजिन: https://host, बिना path, बिना credentials और बिना query। सादा http:// केवल localhost, 127.0.0.1 और [::1] के लिए स्वीकार किया जाता है
--mirror-token-file FILE	कुंजी फ़ाइल का absolute पथ
--mirror-source NAME	स्रोत पर रिपॉज़िटरी। डिफ़ॉल्ट: --mirror जैसा ही नाम
--mirror-ca-file FILE	स्रोत के certificate authority वाली PEM फ़ाइल। अपने certificate authority के साथ HTTPS देखें

एक कमांड को एक रिपॉज़िटरी दें। आप एक ही कॉल में मिरर परिवर्तन को HTTPS, vault या updates के परिवर्तनों के साथ नहीं जोड़ सकते।

1. कमांड कुछ भी बदलने से पहले कुंजी के साथ स्रोत की जाँच करता है। स्रोत को मिरर change feed बताना चाहिए, और स्रोत रिपॉज़िटरी का feed उत्तर देना चाहिए।
2. यह कुंजी config/mirrors/NAME.token में संग्रहीत करता है, config/mirrors/mirrors.json लिखता है और config/runtime.json में ARKVORY_MIRRORS_FILE सेट करता है।
3. यह API और worker को रीस्टार्ट करता है और उनके तैयार होने तक प्रतीक्षा करता है। अगर कुछ भी विफल हो, तो यह पिछली फ़ाइलें बहाल करके फिर से रीस्टार्ट करता है।

Docker Compose में, कमांड config/compose.mirrors.yml भी लिखता है, जो मिरर फ़ाइलों को API और worker कंटेनरों में माउंट करता है। इसे उन Compose कमांडों में जोड़ें जो आप स्वयं चलाते हैं।

रिपॉज़िटरी की कुंजी बदलने के लिए कमांड को केवल --mirror और नई --mirror-token-file के साथ दोहराएँ। स्रोत, stages और certificate authorities जैसे थे वैसे ही रहते हैं, और दोहराए गए कमांड से मिरर कभी आयात में नहीं बदलता। कमांड API और worker को रीस्टार्ट करता है। worker हर विफलता के बाद कुंजी फ़ाइल फिर से पढ़ता भी है, इसलिए हाथ से बदली गई कुंजी फ़ाइल बिना रीस्टार्ट काम करती है।

sudo arkvory configure --root /opt/proanima-arkvory \
  --mirror releases --mirror-token-file /root/new-mirror-releases.key

जब स्रोत कुंजी अस्वीकार करता है, तो कमांड कुछ भी बदलने से पहले रुक जाता है और कारण बताता है: कुंजी स्वीकार नहीं की गई (401), उसे रिपॉज़िटरी पढ़ने की अनुमति नहीं है (403), या रिपॉज़िटरी स्रोत पर मौजूद नहीं है (404)। जो रिपॉज़िटरी पहले से एक स्रोत को मिरर कर रही है वह दूसरे स्रोत को NAME mirrors another source; detach it first संदेश के साथ अस्वीकार कर देती है।

मिरर इंस्टॉलेशन पर, लोगों और tools को रिपॉज़िटरी तक पहुँच दें। रिपॉज़िटरी उसी क्षण अस्तित्व में आती है जब कोई grant या service policy उसका नाम लेती है। लोगों के लिए उपयोगकर्ता और एक्सेस में रिपॉज़िटरी एक्सेस प्रबंधित करें इस्तेमाल करें, और tools के लिए service policy। स्रोत की अनुमतियाँ आगे नहीं जातीं।

अपने certificate authority के साथ HTTPS

अगर स्रोत किसी corporate या self-signed authority का certificate इस्तेमाल करता है, तो --mirror कमांड में --mirror-ca-file /path/ca.pem जोड़ें। कमांड जाँचता है कि हर certificate पढ़ा जा सकता है और समाप्त नहीं हुआ, और यह 1 से 64 certificates config/mirrors/ca.pem में संग्रहीत करता है (फ़ाइल 1 MiB से अधिक नहीं होनी चाहिए)। फिर worker उन्हें मानक के अतिरिक्त भी भरोसा करता है।

• फ़ाइल इंस्टॉलेशन के हर मिरर के लिए काम करती है। नई --mirror-ca-file उसमें जोड़ती है, और पहले से मौजूद certificate एक ही बार रखा जाता है। अंतिम मिरर डिटैच करने पर फ़ाइल हट जाती है।
• worker अपने सभी कनेक्शनों के लिए पूरे समूह पर भरोसा करता है, केवल एक मिरर के लिए नहीं।
• Certificate जाँच कभी बंद नहीं की जाती।

क्या कॉपी होता है और कितनी बार

मिरर इंस्टॉलेशन का worker सिंक्रनाइज़ेशन करता है। कोई अलग सेवा नहीं है। हर मिरर किए गए रिपॉज़िटरी के लिए यह इन चरणों को चलाता है:

1. पहला भरण। worker स्रोत के change feed की वर्तमान स्थिति नोट करता है। फिर यह artifacts, packages और फ़ाइल पथों की सूची पृष्ठ-दर-पृष्ठ पढ़ता है और मिरर को उसके बराबर बनाता है।
2. अनुसरण। worker स्रोत का feed पढ़ता है। जब यह पकड़ लेता है, तो हर 10 सेकंड में फिर जाँचता है। लागू किए गए हर बदलाव के बाद अपनी स्थिति सहेजता है।
3. फ़ाइलें कॉपी करना। फ़ाइल भागों में कॉपी की जाती है। worker हर भाग और पूरी फ़ाइल का SHA-256 जाँचता है। रुकावट के बाद यह पहले गायब भाग से जारी रखता है। एक भाग मिरर की स्टोरेज डायरेक्टरी के अंदर mirror-staging में प्रतीक्षा करता है।
4. त्रुटि के बाद। worker 2 सेकंड से शुरू होकर 5 मिनट तक दोगुनी होती रुकावट के बाद चरण दोहराता है। एक विफल मिरर बाकी को नहीं रोकता।

एक इंस्टॉलेशन में अधिकतम 64 मिरर किए गए रिपॉज़िटरियाँ हो सकती हैं। कॉपियाँ क्षमता सीमा और मिरर की डिस्क में गिनी जाती हैं, इसलिए उतनी ही जगह की योजना बनाएँ जितनी स्रोत रिपॉज़िटरी को चाहिए। स्टोरेज देखें।

अगर स्रोत कुंजी निरस्त कर दी जाए या स्रोत पहुँच से बाहर हो, तो मिरर अपने पास पहले से मौजूद सामग्री परोसता रहता है और अपनी स्थिति में त्रुटि दिखाता है।

सिंक स्थिति जाँचें

कंसोल में

मेनू में मिरर हर उस मिरर और आयात को सूचीबद्ध करता है जिसकी रिपॉज़िटरी आप पढ़ सकते हैं, उसके स्रोत, स्थिति, अंतिम सिंक्रनाइज़ेशन और कॉपी की गई सामग्री के साथ। व्यवस्थापक यह पेज हमेशा देखते हैं; जब तक कोई मिरर नहीं है, यह बताता है कि मिरर कैसे सेट करें। पेज हर 20 सेकंड में अपने आप रीफ़्रेश होता है।

स्थिति	अर्थ
सिंक में	स्रोत के बराबर पहुँच चुका है
बराबरी पर आ रहा है	पिछली जाँच के बाद स्रोत पर हुए बदलाव कॉपी कर रहा है
शुरू हो रहा है	कॉन्फ़िगर किया गया है, और worker अभी इस तक नहीं पहुँचा
पहली कॉपी	पहला भरण, या स्रोत की पुनर्स्थापना के बाद नया भरण
सिंक त्रुटि	अंतिम प्रयास विफल हुआ। डाउनलोड काम करते रहते हैं, और worker अपने आप फिर कोशिश करता है

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

मिरर किए गए रिपॉज़िटरी से कनेक्ट होने पर कंसोल कैटलॉग के ऊपर एक badge भी दिखाता है: मिरर, मिरर · सिंक हो रहा है या मिरर · सिंक त्रुटि। सिंक्रनाइज़ेशन रुके रहने तक उसके नीचे कारण और अगला कदम दिखते हैं, और badge बिना पेज रीलोड किए सर्वर की स्थिति के साथ बदलता है। badge की सहायता (इस मिरर के बारे में) खोलकर स्रोत और अंतिम सिंक्रनाइज़ेशन का समय देखें। कंसोल मिरर किए गए रिपॉज़िटरी में upload और change बटन छिपा देता है।

API के साथ

getRepositoryMirror किसी रिपॉज़िटरी की स्थिति लौटाता है। इसे रिपॉज़िटरी पढ़ने का अधिकार चाहिए। साधारण रिपॉज़िटरी के लिए उत्तर 404 होता है।

फ़ील्ड	अर्थ
mode	mirror या import
phase	pending (worker शुरू नहीं हुआ), seeding (पहला भरण) या following
caughtUp	true जब सहेजी गई स्थिति स्रोत की नवीनतम स्थिति के बराबर हो। पहला भरण समाप्त होने से पहले null
checkedAt, syncedAt	जब worker ने अंतिम बार feed पढ़ा, और जब यह अंतिम बार पकड़ा गया
copiedArtifacts, copiedBytes	अब तक कॉपी किए गए कुल (copiedBytes दशमलव स्ट्रिंग है)
conflicts	अलग रखी गई स्रोत की प्रविष्टियाँ: count, oldestAt और sample में अधिकतम 10 प्रविष्टियाँ। अलग रखी गई प्रविष्टियाँ देखें
errorCode, errorAt	किसी चरण की अंतिम विफलता, या null

त्रुटि कोड

errorCode	अर्थ और क्या करें
mirror_mismatch	उसी artifact ID की सामग्री स्रोत पर अलग है। मिरर अपनी फ़ाइल रखता है। artifact की जाँच करें; कारण जानने से पहले कोई भी प्रति न हटाएँ
mirror_source_changed	रिपॉज़िटरी में पहले से किसी दूसरे स्रोत की प्रति है। उसे डिटैच करें, या नए स्रोत को नई रिपॉज़िटरी में मिरर करें
mirror_source_behind	स्रोत पुनर्स्थापित या फिर से इंस्टॉल किया गया: मिरर की स्थिति पर मौजूद बदलाव वह नहीं है जिसे मिरर ने वहाँ लागू किया था। मिरर स्रोत को फिर से पढ़ता है, और पकड़ लेने पर कोड साफ़ हो जाता है। पुनर्स्थापित स्रोत में न रही फ़ाइलें मिरर पर बनी रहती हैं
mirror_delete_blocked	स्रोत ने ऐसी फ़ाइल हटाई जिसे मिरर हटा नहीं सकता, क्योंकि यहाँ कोई चीज़ उसे अब भी इस्तेमाल करती है, जैसे कोई reference या फ़ाइल पथ इतिहास
mirror_detached	रिपॉज़िटरी डिटैच की गई थी और उसमें अपने बदलाव हैं। वह फिर कभी सिंक्रनाइज़ नहीं होती। स्रोत को एक नई रिपॉज़िटरी में मिरर करें
mirror_package_conflict	स्रोत के एक version में ऐसा package version है जिसे यह रिपॉज़िटरी अलग बाइट के साथ रखती है। प्रविष्टि अलग रख दी जाती है और सिंक्रनाइज़ेशन चलता रहता है: अलग रखी गई प्रविष्टियाँ देखें। पिछले releases यहाँ रुक जाते थे
mirror_id_taken	स्रोत का एक artifact इस इंस्टॉलेशन की किसी दूसरी रिपॉज़िटरी में है। प्रविष्टि अलग रख दी जाती है, अलग रखी गई प्रविष्टियाँ देखें; container image tags, Git LFS objects या npm packages के बदलाव में यह सिंक्रनाइज़ेशन रोक देता है। एक स्रोत रिपॉज़िटरी यहाँ केवल एक रिपॉज़िटरी भर सकती है
mirror_unreachable	स्रोत तक पहुँचा नहीं जा सकता: कनेक्शन अस्वीकार होता है या उसकी समय सीमा समाप्त हो जाती है, या नाम रिज़ॉल्व नहीं होता। worker अपने आप फिर कोशिश करता है। नेटवर्क, फ़ायरवॉल और यह जाँचें कि स्रोत चल रहा है
mirror_certificate	स्रोत का certificate भरोसेमंद नहीं है, समाप्त हो गया है या उसके नाम से मेल नहीं खाता। उसका authority --mirror-ca-file से जोड़ें (अपने certificate authority के साथ HTTPS देखें)
mirror_failed	अधिक विशिष्ट कोड के बिना एक विफलता। worker log पढ़ें
अन्य कोड	विफल अनुरोध का कोड: जब स्रोत कुंजी अब स्वीकार नहीं करता तो unauthorized (मिरर को नई कुंजी दें), जब कुंजी को रिपॉज़िटरी पढ़ने की अनुमति नहीं है तो forbidden, जब स्रोत रिपॉज़िटरी अब मौजूद नहीं है तो not_found, जब मिरर भर गया है तो capacity_exceeded

worker log (component mirror है) में mirror.started, errorCode और attempts के साथ mirror.step_failed, mirror.recovered और mirror.stopped होते हैं।

अलग रखी गई प्रविष्टियाँ

स्रोत के कुछ बदलाव यहाँ मौजूद सामग्री को तोड़े बिना लागू नहीं किए जा सकते। worker ऐसी प्रविष्टि को अलग रख देता है और बाकी बदलावों के साथ आगे बढ़ता है, ताकि एक version बाद के सभी बदलावों को न रोके। कुछ भी चुपचाप नहीं छोड़ा जाता: हर अलग रखी गई प्रविष्टि सुलझने तक दिखाई देती है।

कोड	अर्थ	क्या करें
mirror_package_conflict	version में ऐसा package version (group, name और version) है जिसे यह रिपॉज़िटरी अलग बाइट के साथ रखती है। clients को वही version मिलता रहता है जो यहाँ है; कॉपी की गई फ़ाइल पैकेज पंजीकरण के बिना रहती है	स्रोत पर stage या version हटाएँ, या उसे किसी दूसरे version के तहत प्रकाशित करें। आयात में आप यहाँ का version भी हटा सकते हैं
mirror_id_taken	इस इंस्टॉलेशन की कोई दूसरी रिपॉज़िटरी artifact ID रखती है	एक स्रोत रिपॉज़िटरी यहाँ एक रिपॉज़िटरी भरती है। दूसरा मिरर या आयात अलग करें, या दूसरी कॉपी हटाएँ

• worker हर प्रविष्टि को उसके अंतिम प्रयास के 10 मिनट बाद फिर से आज़माता है, हर बार स्रोत के बराबर पहुँचने पर अधिकतम 8 प्रविष्टियाँ। प्रविष्टि तब हटती है जब वह लागू हो जाए, या जब स्रोत पर वह न रहे: वहाँ version हटा दिया गया, या आयात के लिए उसका stage हटा दिया गया।
• स्थिति में conflicts दिखता है: कितनी प्रविष्टियाँ अलग रखी गई हैं, सबसे पुरानी कब अलग रखी गई, और अधिकतम 10 प्रविष्टियाँ, artifact ID, बदलाव (action और detail), कोड, पहले और अंतिम प्रयास और प्रयासों की संख्या के साथ।
• कंसोल उनकी संख्या मिरर पर और रिपॉज़िटरी के badge के नीचे दिखाता है। स्थिति नहीं बदलती, क्योंकि बाकी सिंक होता रहता है।
• worker log में हर विफल प्रयास पर mirror.conflict_set_aside (warning, artifactId, action, errorCode और attempts के साथ) और प्रविष्टि हटने पर mirror.conflict_resolved होता है।
• metric arkvory_mirror_conflicts उन्हें गिनता है, और नियम ArkvoryMirrorConflicts तब चेतावनी देता है जब 30 मिनट तक कोई प्रविष्टि अलग रखी रहे।

container image tags और manifests, Git LFS objects और npm packages के बदलाव कभी अलग नहीं रखे जाते: उनका क्रम मायने रखता है, और किसी को बाद में लागू करना किसी नए बदलाव को पलट सकता है। इनमें टकराव सुलझने तक सिंक्रनाइज़ेशन को अपने कोड के साथ रोक देता है।

मिरर की निगरानी करें

मिरर इंस्टॉलेशन का API हर मिरर किए गए रिपॉज़िटरी के लिए चार metrics उपलब्ध कराता है, repository और mode लेबल के साथ:

• arkvory_mirror_last_sync_timestamp_seconds: अंतिम बार जब मिरर पकड़ा गया।
• arkvory_mirror_last_check_timestamp_seconds: अंतिम बार जब उसने feed पढ़ा।
• arkvory_mirror_failing: अंतिम प्रयास विफल रहने पर 1; पर तब नहीं जब मिरर पुनर्स्थापित स्रोत को फिर से पढ़ रहा हो (mirror_source_behind)।
• arkvory_mirror_conflicts: अलग रखी गई प्रविष्टियों की संख्या।

तैयार Prometheus नियम हैं ArkvoryMirrorStale (एक घंटे से अधिक समय से नहीं पकड़ा, 15 मिनट तक) और ArkvoryMirrorFailing (विफलता 15 मिनट चलती है)। मॉनिटरिंग देखें। जिस मिरर तक worker नहीं पहुँचा उसका कोई sync time नहीं होता, इसलिए stale नियम उसके पहले सिंक्रनाइज़ेशन से पहले नहीं चलता। ArkvoryMirrorConflicts तब चेतावनी देता है जब प्रविष्टियाँ 30 मिनट तक अलग रखी रहें।

स्टेज से आयात करें

--mirror-stages के साथ, दूसरे इंस्टॉलेशन पर रिपॉज़िटरी मिरर नहीं होती। यह एक साधारण लिखने योग्य रिपॉज़िटरी होती है जो उन versions को ले लेती है जिन पर स्रोत के stages में से कोई हो। इसका उपयोग builds को development सर्वर से production सर्वर पर ले जाने के लिए करें।

sudo arkvory configure --root /opt/proanima-arkvory \
  --mirror releases --mirror-upstream https://dev.example \
  --mirror-token-file /root/dev.key --mirror-stages release

• आप 1 से 16 अलग stage नाम कॉमा से अलग करके सूचीबद्ध करते हैं।
• एक version एक बार कॉपी होता है, उसी ID, बाइट, labels और UPack पंजीकरण के साथ, और मेल खाते stages के साथ।
• उसके बाद यह इस इंस्टॉलेशन की हो जाती है। स्रोत पर बदलाव, stage हटाना और deletion इसे नहीं पहुँचते। यहाँ आपके हटाए version को फिर कभी आयात नहीं किया जाता। यहाँ आपका हटाया stage हटा ही रहता है। जब स्रोत बाद में version को कोई दूसरा कॉन्फ़िगर किया गया stage देता है, तो केवल वही stage जोड़ा जाता है।
• अपलोड और रिपॉज़िटरी की storage policy सामान्य रूप से काम करती हैं।
• Container image, Git LFS और npm registry डेटा आगे नहीं ले जाए जाते।
• stages बदलने से नया first fill शुरू होता है। यह केवल वे versions लाता है जो यहाँ अभी नहीं हैं, और जो यहाँ हैं उन्हें वैसा ही छोड़ देता है।
• स्रोत का ऐसा version, जिसका package version यह रिपॉज़िटरी पहले से अलग बाइट के साथ रखती है, mirror_package_conflict के साथ अलग रख दिया जाता है, और आयात अगले versions के साथ चलता रहता है। clients को वही version मिलता रहता है जो यहाँ है। अलग रखी गई प्रविष्टियाँ देखें।

दो इंस्टॉलेशन एक-दूसरे से आयात कर सकते हैं। उदाहरण के लिए, production staging से release लेता है, और staging production से hotfix लेता है। एक version दोनों तरफ़ अपनी ID रखता है, इसलिए कुछ भी दो बार कॉपी नहीं होता और न ही चक्कर में घूमता है:

• staging पर बना version जो production से वापस आता है, उसे केवल नया stage मिलता है।
• एक तरफ़ हटाया गया version दूसरी तरफ़ से फिर कभी आयात नहीं किया जाता, भले ही दूसरी तरफ़ बाद में उसे कोई stage दे।
• deletion कभी आगे नहीं भेजा जाता: दूसरी तरफ़ अपनी कॉपी तब तक रखती है जब तक आप उसे वहाँ भी नहीं हटाते।

दोनों दिशाओं के लिए अलग stages का उपयोग करें। दोनों दिशाओं में एक ही stage होने पर, एक तरफ़ आपका हटाया stage तब वापस आ जाता है जब दूसरी तरफ़ उस version को फिर से वह stage देती है।

कंसोल badge आयात दिखाता है, या अंतिम प्रयास विफल होने पर आयात · सिंक त्रुटि। स्रोत पर कुंजी को मिरर की तरह ही वही read-only अनुमतियाँ चाहिए।

स्रोत खो जाने पर फ़ेलओवर करें

यह दो साइटों पर दो स्वतंत्र इंस्टॉलेशन के लिए एक मैनुअल स्विच है। यह स्वचालित नहीं है। जो बदलाव मिरर अभी तक नहीं खींच पाया था वे खो जाते हैं।

पहले से तैयारी करें

1. दूसरी साइट को, जब संभव हो, स्रोत जैसी ही रिलीज़ के साथ इंस्टॉल करें, उसके अपने PostgreSQL और अपनी डिस्क के साथ। दोनों साइटें कुछ भी साझा नहीं करतीं।
2. स्रोत पर एक read-only कुंजी बनाएँ और हर रिपॉज़िटरी को मिरर के रूप में अटैच करें। स्रोत पर बाद में बनी रिपॉज़िटरी अपने-आप मिरर पर नहीं आती, इसलिए उसे भी इसी तरह अटैच करें।
3. मिरर पर वे keys जारी करें जो आपके consumers इस्तेमाल करेंगे, जिनमें स्विच के बाद लिख सकने वाली keys भी शामिल हैं। स्रोत की अनुमतियाँ आगे नहीं जातीं, इसलिए compromised स्रोत मिरर तक पहुँच नहीं देता।
4. Consumers (CI, deployment agents) को डाउनलोड के लिए fallback के रूप में मिरर का पता सेट करें। इससे स्रोत के लिंक पर भार भी घटता है।
5. स्रोत का बैकअप उसकी साइट के बाहर किसी vault में लें। बैकअप देखें। मिरर इसका विकल्प नहीं है।
6. ऊपर के नियमों से मिरर की निगरानी करें।

स्विच

1. सुनिश्चित करें कि स्रोत clients के लिए वास्तव में अनुपलब्ध है और अपने-आप वापस नहीं आएगा। जो दो साइटें एक ही logical रिपॉज़िटरी में लिखना स्वीकार करती हैं, उन्हें बाद में मिलाया नहीं जा सकता। अगर स्रोत आंशिक रूप से पहुँच योग्य है, तो उसकी सेवाएँ रोक दें या उसका पोर्ट बंद कर दें।

2. मिरर पर हर रिपॉज़िटरी का syncedAt पढ़ें। उस समय के बाद स्रोत पर किए बदलाव मिरर पर नहीं हैं।

3. मिरर पर हर मिरर किए गए रिपॉज़िटरी को डिटैच करें। यह उसी artifact IDs और अपने सारे डेटा के साथ साधारण लिखने योग्य रिपॉज़िटरी बन जाती है।

   sudo arkvory configure --root /opt/proanima-arkvory --mirror-detach releases,prod

   कई रिपॉज़िटरी कॉमा से अलग करके दें, या हर मिरर और आयात के लिए all। कमांड API और worker को एक बार रीस्टार्ट करता है, इसलिए थोड़ी रुकावट की अपेक्षा करें।

4. जो clients लिखते हैं उन्हें DNS या अपने CI के कॉन्फ़िगरेशन के ज़रिए मिरर की ओर इंगित करें।

5. मिरर पर एक control file अपलोड और डाउनलोड करें।

clients क्या देखते हैं:

• स्विच से पहले, मिरर से डाउनलोड काम करते हैं, और writes को 409 mirror_read_only मिलता है।
• डिटैच के बाद, writes काम करते हैं। badge गायब हो जाता है।
• स्रोत की keys और passwords मिरर पर काम नहीं करते, जब तक आपने वहाँ वही accounts न बनाए हों।

वापसी का कोई रास्ता नहीं है। डिटैच की गई रिपॉज़िटरी को फिर से मिरर के रूप में अटैच नहीं किया जा सकता: उसका सिंक्रनाइज़ेशन mirror_detached के साथ रुक जाता है। पुराने स्रोत को वापस लाने के लिए, उसे साफ़ करें या नए सिरे से इंस्टॉल करें और नए primary की रिपॉज़िटरियों को मिरर के रूप में अटैच करें। पुराने स्रोत और नए primary को writes चालू रखते हुए कभी साथ-साथ न चलाएँ।

अभ्यास करें

हर तिमाही और updates के बाद स्विच का अभ्यास करें। किसी अतिरिक्त प्रति पर एक रिपॉज़िटरी डिटैच करें, syncedAt, एक डाउनलोड और एक अपलोड जाँचें, और तारीख तथा परिणाम लिख लें। स्रोत के बैकअप को खाली इंस्टॉलेशन में पुनर्स्थापित करने का परीक्षण अलग से करें। पुनर्स्थापना का नियमित परीक्षण करें देखें।

सीमाएँ

• मिरर तब तक read-only रहता है जब तक आप उसे डिटैच नहीं करते। डिटैच की गई रिपॉज़िटरी फिर मिरर नहीं बन सकती।
• मिरर बैकअप नहीं है। इसके पास accounts, keys या grants की प्रति नहीं होती, और यह references, attachments, audit trails या storage policies कॉपी नहीं करता।
• Import मोड container images, Git LFS या npm डेटा कॉपी नहीं करता।
• नया पहला भरण केवल जोड़ता और अपडेट करता है: स्रोत की पुनर्स्थापना के बाद, स्रोत से खोई फ़ाइलें मिरर पर बनी रहती हैं।
• एक स्रोत रिपॉज़िटरी किसी इंस्टॉलेशन की एक ही रिपॉज़िटरी भरती है: artifact IDs दोनों तरफ़ समान होती हैं, इसलिए उसका दूसरा मिरर या आयात कॉन्फ़िगर करते समय अस्वीकार कर दिया जाता है। इसी कारण, एक-दूसरे से आयात करने वाले दो इंस्टॉलेशन को दोनों तरफ़ एक ही रिपॉज़िटरी नाम इस्तेमाल करना होगा: दूसरी तरफ़ से आया version यहाँ किसी दूसरी रिपॉज़िटरी में नहीं लिया जा सकता, और वह mirror_id_taken के साथ अलग रख दिया जाता है।
• ऐसा version, जिसका package version यहाँ पहले से अलग बाइट के साथ रखा है, कॉपी हो जाता है, फिर mirror_package_conflict के साथ अलग रख दिया जाता है। कॉपी पैकेज पंजीकरण के बिना रिपॉज़िटरी में तब तक रहती है जब तक आप उसे हटा न दें।
• अलग रखी गई प्रविष्टि सुलझने तक यहाँ नहीं होती। container image tags, Git LFS objects या npm packages के बदलाव में टकराव अब भी सिंक्रनाइज़ेशन रोकता है।
• मिरर इंस्टॉलेशन को बैकअप से पुनर्स्थापित करने के बाद, जो versions बैकअप लेने के बाद आयात और हटाए गए थे, वे फिर से आयात हो सकते हैं।
• दोनों इंस्टॉलेशन अपने-अपने हिसाब से अपडेट होते हैं। स्रोत को मिरर change feed उपलब्ध कराना चाहिए।
• स्रोत के भरोसेमंद authorities का समूह पूरे worker पर लागू होता है।
• कोई स्वचालित failover नहीं, पुराने स्रोत का कोई fencing नहीं और कोई reverse synchronization नहीं।

संबंधित पेज

• बैकअप
• रीड गेटवे
• स्टोरेज
• मॉनिटरिंग
• एनवायरनमेंट वेरिएबल
• खाते और पहुँच