---
title: "तोंड बंदीशिवाय अपग्रेड"
description: "तोंड बंदीशिवाय स्वतः-होस्ट Quire अपग्रेड करा."
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/mr/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](/mr/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-->

त्याच क्रम वापरा: एका जॉबमधून एकदाच मायग्रेट करा, नंतर surge
एक आणि unavailable शून्य घेऊन वेब थिअर रोल करा, नंतर वर्कर.
रेडीनेस प्रोब `/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/mr/ops/upgrade/index.mdx