---
title: "बिना अवरोध स्तरोन्नति"
description: "स्व-होस्टेड Quire लाई बिना अवरोध स्तरोन्नति गर्नुहोस्।"
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/ne/llms.txt
> Use this file to discover all available pages before exploring further.

# बिना अवरोध स्तरोन्नति

<span id="upgrading-without-downtime"></span>

नियम `docs/architecture/23-ops.md` खण्ड 7 र
`docs/architecture/07-data.md` खण्ड 4.1 मा छन्। यो प्रक्रिया हो।

## सुरक्षित बनाउने ग्यारेन्टी <!--quire:the-guarantee-that-makes-it-safe-->

**रिलिज R स्किमा R र स्किमा R माइनस एक विरुद्ध सही चल्छ।** हरेक
स्किमा परिवर्तन विस्तार, सङ्क्रमण र सम्झौतामा विभाजन हुन्छ:

1. **विस्तार**: नयाँ स्तम्भ, तालिका वा सूचकाङ्क थप्नुहोस्। पुरानो कोडले बेवास्ता गर्छ।
2. **सङ्क्रमण**, कम्तीमा एक रिलिजका लागि: नयाँ कोड दुवै आकार लेख्छ र
   नयाँ पढ्छ; पुनः सुरु हुने कामले पुराना पङ्क्ति ब्याकफिल गर्छ।
3. **सम्झौता**: पुरानो आकार हटाउनुहोस्, पछिल्लो रिलिजमा, एक्लै।

त्यसैले रोलिङ स्तरोन्नतिको हरेक क्षणमा, पुराना र नयाँ प्रक्रिया एउटा डेटाबेस साझा गर्न सक्छन्।
डाउन माइग्रेसन हुँदैनन्: एक घण्टाअघि स्तम्भ हटाउने माइग्रेसनले त्यो घण्टामा लेखिएका पङ्क्ति फिर्ता दिन सक्दैन।

`schema-compat` CI कामले हरेक रिलिजमा नयाँ स्किमाविरुद्ध अघिल्लो रिलिजका परीक्षण चलाएर ग्यारेन्टी जाँच्छ।

## सुरु गर्नुअघि <!--quire:before-you-start-->

1. रिलिज टिप्पणी पढ्नुहोस्। मर्मत विन्डो चाहिने रिलिजले अनुमानसहित त्यही भन्छ;
   प्रति रिलिज बढीमा एक।
2. पुनर्स्थापना अभ्यास चलाउनुहोस्, वा यस रिलिजका लागि हरियो चलेको पुष्टि गर्नुहोस्
   ([backup-restore.md](/ne/ops/backup-restore/))। असफल अभ्यासले स्तरोन्नति अवरुद्ध गर्छ।
3. आधार ब्याकअप लिनुहोस्: `docker compose -f docker/compose.yaml --profile backup
   run --rm backup`।

## Docker Compose, एउटा होस्ट <!--quire:docker-compose-one-host-->

```sh
export QUIRE_RELEASE=2026.10.0            # or set it in docker/.env
docker compose -f docker/compose.yaml pull   # or build
docker compose -f docker/compose.yaml run --rm migrate
docker compose -f docker/compose.yaml up -d --no-deps web content collab
docker compose -f docker/compose.yaml up -d --no-deps worker scheduler
```

क्रम जानाजानी हो:

1. **पहिले माइग्रेट**, पुरानो रिलिजले ट्राफिक दिँदै गर्दा। विस्तार माइग्रेसन
   यसलाई अदृश्य छन्।
2. **अर्को वेब तह।** SIGTERM मा हरेक वेब प्रक्रियाले `/readyz` लाई
   `draining` मा फर्काउँछ, 30 सेकेन्डभित्र चलिरहेका अनुरोध सकाउँछ, पुनः जडान सङ्केतसहित स्ट्रिम बन्द गर्छ,
   र बाहिरिन्छ। `stop_grace_period` 40 सेकेन्ड छ ताकि Compose ले स्वस्थ ड्रेन कहिल्यै काट्दैन।
3. **अन्त्यमा वर्कर**, ताकि नयाँ उपभोक्ताले अपेक्षा गर्नुअघि नवीनतम घटना आकार उत्पादन होस्।
   वर्करले एकैचोटि ल्याउन छोड्छन् र 120 सेकेन्ड पाउँछन्; सक्न नसक्ने काम अन्तै फेरि ल्याइन्छ,
   जुन सुरक्षित छ किनभने हरेक काम आइडेम्पोटेन्ट छ। सेड्युलरले अर्को टिकमा नेतृत्व हस्तान्तरण गर्छ।

एउटा होस्टमा, Compose ले हरेक कन्टेनर पालैपालो प्रतिस्थापन गर्छ, त्यसैले प्रति सेवा छोटो खाडल हुन्छ।
कुनै खाडलबिना नै, वेब तहलाई आफ्नै प्रोक्सीपछाडि दुई कन्टेनरका रूपमा चलाउनुहोस्
(प्रकाशित पोर्टबिना दोस्रो वेब सेवा थप्ने ओभरराइड फाइल), र अर्कोअघि हरेक स्वस्थ रिपोर्ट पर्खँदै एक-एक पुनः बनाउनुहोस्।

## धेरै होस्ट वा अर्केस्ट्रेटर <!--quire:several-hosts-or-an-orchestrator-->

उही क्रम प्रयोग गर्नुहोस्: एउटा कामबाट एकपटक माइग्रेट गर्नुहोस्, त्यसपछि वेब तहलाई सर्ज एक र अनुपलब्ध शून्यसहित रोल गर्नुहोस्,
त्यसपछि वर्कर। तयारी जाँच `/readyz` मा र जीवितता `/healthz` मा देखाउनुहोस्।

समर्पित टेनान्ट डेटाबेससँग, `migrate` चरणले दुवै गर्छ: यसले पहिले नियन्त्रण डेटाबेस माइग्रेट गर्छ,
त्यसपछि `ops.tenant_database` मा सूचीबद्ध हरेक डेटाबेस, एक-एक गर्दै, हरेक आफ्नै लकमा।
एउटा टेनान्ट डेटाबेसको असफलताले अरूलाई रोक्दैन। हरेक डेटाबेस सकिँदा यसले माइग्रेसन खाता तुलना गर्छ र
नियन्त्रण डेटाबेसले लगाएकै माइग्रेसन हरेक डेटाबेसले ठ्याक्कै नलगाएसम्म शून्येतर बाहिरिन्छ, पछाडि वा अगाडि रहेको हरेक नामसहित।
उही आदेशले हरेक डेटाबेसमा पङ्क्ति तालिका स्थापना गर्छ, किनभने वर्करले पिन गरिएको टेनान्टका काम लेखिएकै ठाउँमा उपभोग गर्छ।

```sh
bun apps/worker/src/migrate.ts   # what the Compose step runs
bun run db:migrate:all                            # the same, from a checkout
```
सामान्य माइग्रेसन र पहिलो पटकको सेटअपले `ops.platform_policy_version` मा Quire अपरेटरका प्रामाणिक अङ्ग्रेजी कानुनी कागजातहरू पनि स्थापना गर्छ। स्थापनाकर्ता आइडेम्पोटेन्ट छ: हराएका अङ्ग्रेजी बडी र माइग्रेसनले सीड गरेका ठ्याक्कै प्लेसहोल्डर बडी मात्र प्रतिस्थापन गरिन्छ। सीडहरू सङ्ग्रहित गरिन्छ र नयाँ प्रकाशित संस्करण घुसाइन्छ; ऐतिहासिक स्वीकृति सन्दर्भ र बडीहरू कायम रहन्छन्। अपरेटरले साँच्चै लेखेको कुनै पनि संस्करण, मस्यौदा सहित, सुरक्षित रहन्छ र प्लेटफर्मको नीति कन्सोलमार्फत व्यवस्थापन गरिनुपर्छ। यो कटओभरले टेनेन्ट नीति कागजात, संस्करण र सहमति कहिल्यै परिवर्तन गर्दैन। यो अपरेटर पाठको प्रकाशन हो, कानुनी प्रमाणीकरण वा यसका प्रतिज्ञाहरूको स्वचालित पूर्ति होइन।


हरेक समर्पित डेटाबेस दर्ता गरिएको नामबाट पुगिन्छ।
`env:QUIRE_DB_NORTHWIND_URL` का रूपमा दर्ता डेटाबेसलाई चाहिन्छ:

| चर | प्रयोग |
| --- | --- |
| `QUIRE_DB_NORTHWIND_URL` | वेब तह र वर्करका लागि अनुप्रयोग भूमिका |
| `QUIRE_DB_NORTHWIND_URL_MIGRATOR` | यस आदेश र सार्नका लागि माइग्रेटर भूमिका |
| `QUIRE_DB_NORTHWIND_URL_SUPERUSER` | वैकल्पिक: माइग्रेटअघि बुटस्ट्र्याप (भूमिका, स्किमा, सहायक) पुनः लागू गर्छ |

`_MIGRATOR` जडान नभएको दर्ता डेटाबेस असफलता रिपोर्ट हुन्छ, कहिल्यै छोडिँदैन।
नियन्त्रण डेटाबेस सकिएपछि वेब तह रोल हुन सक्छ। एक घण्टा पछाडि टेनान्ट डेटाबेसले चेतावनी दिन्छ;
एक दिनले पेज गर्छ।

## pgvector <!--quire:pgvector-->

माइग्रेसन 0264 बाट ग्राउन्डिङ कर्पसले pgvector HNSW सूचकाङ्क प्रयोग गर्छ जहाँ
सर्भरमा एक्सटेन्सन छ; Compose `postgres` सेवा यससहित निर्मित छ
(`docker/postgres.Dockerfile`)। छवि फेरेपछिको पहिलो `migrate` ले सुपरप्रयोगकर्ता बुटस्ट्र्यापमार्फत एक्सटेन्सन बनाउँछ,
र 0264 ले त्यसपछि निर्मित भेक्टर स्तम्भ थप्छ र सूचकाङ्क बनाउँछ। स्तम्भ थप्दा विशेष लकमा एकपटक
`app.ai_chunk` पुनः लेख्छ, त्यसैले ग्राउन्डिङ अनुरोध पर्खन्छन्; त्यो तालिकालाई अरू केही छुँदैन।

pgvector नभएको सर्भरमा, 0264 ले सूचना लग गर्छ र केही परिवर्तन गर्दैन, र पुनःप्राप्ति ठ्याक्कै रहन्छ।
0.8 भन्दा पुरानो pgvector सँग स्तम्भ र सूचकाङ्क बनाइन्छ तर एक्सटेन्सन स्तरोन्नति नभएसम्म पुनःप्राप्ति ठ्याक्कै रहन्छ
(`alter extension vector update`), किनभने फिल्टर गरिएको HNSW स्क्यानलाई 0.8 को
पुनरावृत्त स्क्यान चाहिन्छ। यसबिनाको सर्भरमा पछि सक्षम गर्न, एक्सटेन्सन स्थापना गर्नुहोस्,
बुटस्ट्र्याप फेरि चलाउनुहोस् (वा सुपरप्रयोगकर्ताका रूपमा `create extension vector`), त्यसपछि `quire_migrator` का रूपमा:

```sql
set maintenance_work_mem = '1GB';  -- the HNSW build is much faster in memory
select ops.ai_chunk_enable_vector_index();
```

यो आइडेम्पोटेन्ट छ र `enabled` वा `unavailable` फर्काउँछ। हरेक समर्पित टेनान्ट डेटाबेसमा पनि चलाउनुहोस्।

## फिर्ता रोल गर्ने <!--quire:rolling-back-->

**कोड** फिर्ता रोल सधैँ उपलब्ध छ: `QUIRE_RELEASE` लाई अघिल्लो ट्यागमा सेट गर्नुहोस् र फेरि `up -d`।
यो काम गर्छ किनभने स्किमा रिलिजभित्र दुवै दिशामा अनुकूल छ।

**स्किमा** फिर्ता रोल प्रस्ताव गरिँदैन। के उल्ट्याउन सकिँदैन, र यसबाट कसरी पुनःप्राप्ति गर्ने:

| उल्टाउन नसकिने | पुनःप्राप्ति |
| --- | --- |
| स्तम्भ हटाउने सम्झौता माइग्रेसन | हटाउनुअघिको बिन्दुमा नयाँ डेटाबेसमा पुनर्स्थापना, निकाल्ने, मिलाउने |
| ठाउँमै डेटा परिवर्तन | उही, त्यसपछि यताका लेखन मिलाउने |
| पठाइएका webhooks र घटना | क्षतिपूर्ति घटना, कहिल्यै मेट्ने होइन |
| पठाइएको इमेल | मानवले फलो-अप लेख्छ |
| अडिट ह्यास शृङ्खला | कहिल्यै पुनः लेखिँदैन; सुधार प्रविष्टि थप्नुहोस् |

त्यसैले सम्झौता माइग्रेसन एक्लै पठाइन्छ: पुनर्स्थापनासँग सफा सीमा हुन्छ।

## स्तरोन्नति जाँच्ने <!--quire:checking-the-upgrade-->

```sh
docker compose -f docker/compose.yaml ps           # every service healthy
curl -fsS http://localhost:8080/readyz             # ready, and what is configured
docker compose -f docker/compose.yaml logs migrate # the migrations applied
```

Source: https://docs.quirelms.com/ne/ops/upgrade/index.mdx