---
title: "ડાઉનટાઇમ વિના અપગ્રેડ"
description: "સ્વ-હોસ્ટ કરેલા Quire ને ડાઉનટાઇમ વિના અપગ્રેડ કરો."
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/gu/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](/gu/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 સેકન્ડ મળે છે;
   પૂર્ણ ન થઈ શકે તેવી જોબ બીજે ફરી લેવામાં આવે છે, જે સુરક્ષિત છે કારણ કે દરેક જોબ
   idempotent છે. શેડ્યૂલર તેની આગામી ટિક પર નેતૃત્વ સોંપે છે.

એક હોસ્ટ પર Compose દરેક કન્ટેનરને ક્રમે બદલે છે, તેથી દરેક સેવા માટે થોડો વિરામ આવે
છે. કોઈ વિરામ જ ન જોઈએ તો વેબ સ્તરને તમારા પોતાના પ્રોક્સી પાછળ બે કન્ટેનર તરીકે
ચલાવો (પ્રકાશિત પોર્ટ વગર બીજી વેબ સેવા ઉમેરતી override ફાઇલથી), અને દરેકને
એક પછી એક ફરી બનાવો; આગળ વધતાં પહેલાં દરેક સ્વસ્થ હોવાની ખાતરી કરો.

## ઘણા હોસ્ટ અથવા ઓર્કેસ્ટ્રેટર <!--quire:several-hosts-or-an-orchestrator-->

એ જ ક્રમ રાખો: એક જ જોબમાંથી એક વાર માઇગ્રેટ કરો, પછી surge એક અને unavailable
શૂન્ય રાખીને વેબ સ્તરને ક્રમે બદલો, ત્યારબાદ વર્કરો. Readiness probes ને `/readyz`
અને liveness ને `/healthz` પર રાખો.

સમર્પિત tenant ડેટાબેઝ હોય ત્યારે `migrate` પગલું બંને કામ કરે છે: પહેલાં નિયંત્રણ
ડેટાબેઝ, પછી `ops.tenant_database` માં નોંધાયેલ દરેક ડેટાબેઝ, એક સમયે એક અને
દરેક પોતાનાં lock હેઠળ. એક tenant ડેટાબેઝની નિષ્ફળતા બીજાઓને અટકાવતી નથી. બધા
ડેટાબેઝ પૂર્ણ થાય ત્યારે તે migration ledgers સરખાવે છે અને દરેક ડેટાબેઝમાં નિયંત્રણ
ડેટાબેઝ જેટલી જ માઇગ્રેશન લાગુ થઈ હોય તો જ સફળ થાય છે; પાછળ કે આગળ હોય તે દરેકનું
નામ દર્શાવીને અન્યથા non-zero સ્થિતિ સાથે બહાર નીકળે છે. એ જ આદેશ દરેક ડેટાબેઝમાં
queue tables પણ સ્થાપે છે, કારણ કે worker tenant પર નિશ્ચિત કરેલી jobs જ્યાં લખાઈ
હોય ત્યાં જ વાપરે છે.

```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`
તરીકે નોંધાયેલા ડેટાબેઝ માટે આ જરૂરી છે:

| Variable | Used for |
| --- | --- |
| `QUIRE_DB_NORTHWIND_URL` | એપ્લિકેશન ભૂમિકા, વેબ સ્તર અને worker માટે |
| `QUIRE_DB_NORTHWIND_URL_MIGRATOR` | migrator ભૂમિકા, આ આદેશ અને સ્થળાંતર માટે |
| `QUIRE_DB_NORTHWIND_URL_SUPERUSER` | વૈકલ્પિક: માઇગ્રેશન પહેલાં bootstrap (roles, schemas, helpers) ફરી લાગુ કરે છે |

`_MIGRATOR` જોડાણ વગરનો નોંધાયેલ ડેટાબેઝ નિષ્ફળતા તરીકે દર્શાવાય છે, ક્યારેય
છોડી દેવાતો નથી. નિયંત્રણ ડેટાબેઝ પૂર્ણ થાય પછી વેબ સ્તર ક્રમે બદલી શકાય છે. એક
કલાક પાછળ હોય તે tenant ડેટાબેઝ ચેતવણી આપે છે; એક દિવસ પાછળ હોય તો પેજર એલર્ટ આપે છે.

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

માઇગ્રેશન 0264 થી grounding corpus માં સર્વર પર extension હોય ત્યારે pgvector HNSW
ઇન્ડેક્સ વપરાય છે; Compose ની `postgres` સેવા તે સાથે બનાવાય છે
(`docker/postgres.Dockerfile`). ઇમેજ બદલ્યા પછીની પહેલી `migrate` superuser bootstrap
દ્વારા extension બનાવે છે, પછી 0264 એક generated vector column ઉમેરે છે અને ઇન્ડેક્સ
બનાવે છે. કૉલમ ઉમેરતાં `app.ai_chunk` exclusive lock હેઠળ એક વાર ફરી લખાય છે, તેથી
grounding વિનંતીઓ રાહ જુએ છે; બીજું કંઈ એ ટેબલને સ્પર્શતું નથી.

pgvector વિનાના સર્વર પર 0264 સૂચના લખે છે અને કશું બદલતું નથી; retrieval ચોક્કસ
રીતે જ રહે છે. 0.8 કરતાં જૂના pgvector સાથે કૉલમ અને ઇન્ડેક્સ બને છે, પરંતુ extension
અપગ્રેડ થાય ત્યાં સુધી retrieval ચોક્કસ જ રહે છે (`alter extension vector update`),
કારણ કે filtered HNSW scans માટે 0.8 ના iterative scans જોઈએ. પછીથી વિનાના સર્વર પર
તે સક્રિય કરવા extension સ્થાપો, bootstrap ફરી ચલાવો (અથવા superuser તરીકે
`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();
```

આ idempotent છે અને `enabled` અથવા `unavailable` આપે છે. દરેક સમર્પિત tenant
ડેટાબેઝ પર પણ ચલાવો.

## પાછા ફેરવવું <!--quire:rolling-back-->

**કોડ** પાછો ફેરવવો હંમેશાં શક્ય છે: `QUIRE_RELEASE` ને અગાઉના tag પર સેટ કરો અને
ફરી `up -d` ચલાવો. તે ચાલે છે કારણ કે એક રિલીઝની અંદર સ્કીમા બંને દિશામાં સુસંગત છે.

**સ્કીમા** પાછી ફેરવવાની સુવિધા નથી. જે પાછું ફેરવી શકાતું નથી અને તેમાંથી પુનઃપ્રાપ્તિ:

| Not reversible | Recovery |
| --- | --- |
| કૉલમ કાઢી નાખતી contract migration | કાઢી નાખવાના પહેલાંના સમય પર નવા ડેટાબેઝમાં પુનઃસ્થાપિત કરો, માહિતી બહાર કાઢો અને ભેળવો |
| સ્થળ પર કરેલો ડેટા ફેરફાર | એ જ રીતે, પછીથી થયેલા લખાણોનું સમાધાન કરો |
| મોકલેલા webhooks અને events | વળતરરૂપ events મોકલો, ક્યારેય કાઢી ન નાખો |
| મોકલેલો email | અનુસરણ સંદેશ માનવ લખે |
| audit hash chain | ક્યારેય ફરી લખાતી નથી; સુધારાની એન્ટ્રી ઉમેરો |

એટલા માટે contract migration એકલી જ રિલીઝ થાય છે: પુનઃસ્થાપન માટે સ્વચ્છ સીમા રહે છે.

## અપગ્રેડની તપાસ <!--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/gu/ops/upgrade/index.mdx