ડાઉનટાઇમ વિના અપગ્રેડ

નિયમો docs/architecture/23-ops.md ના વિભાગ 7 અને docs/architecture/07-data.md ના વિભાગ 4.1 માં છે. આ પ્રક્રિયા અનુસરો.

આને સુરક્ષિત બનાવતી ખાતરી

રિલીઝ R, સ્કીમા R અને સ્કીમા R માઇનસ એક બંને સાથે યોગ્ય રીતે ચાલે છે. દરેક સ્કીમા ફેરફારને વિસ્તરણ, સંક્રમણ અને સમાપન એમ ત્રણ તબક્કામાં વહેંચવામાં આવે છે:

1. વિસ્તરણ: નવો કૉલમ, ટેબલ અથવા ઇન્ડેક્સ ઉમેરો. જૂનો કોડ તેને અવગણે છે.
2. સંક્રમણ, ઓછામાં ઓછી એક રિલીઝ સુધી: નવો કોડ બંને આકારોમાં લખે છે અને નવો આકાર વાંચે છે; ફરી શરૂ કરી શકાય તેવી જોબ જૂની પંક્તિઓ ભરે છે.
3. સમાપન: પછીની એકલ રિલીઝમાં જૂનો આકાર દૂર કરો.

આથી ક્રમશઃ અપગ્રેડના દરેક સમયે જૂની અને નવી પ્રક્રિયાઓ એક જ ડેટાબેઝ વહેંચી શકે છે. ડાઉન માઇગ્રેશન નથી: એક કલાક પહેલાં કૉલમ કાઢી નાખતી માઇગ્રેશન તે કલાકમાં લખાયેલી પંક્તિઓ પાછી આપી શકતી નથી.

દરેક રિલીઝ પર schema-compat CI જોબ નવી સ્કીમા સામે અગાઉની રિલીઝની કસોટીઓ ચલાવીને આ ખાતરી તપાસે છે.

શરૂ કરતાં પહેલાં

1. રિલીઝ નોંધો વાંચો. જાળવણી સમયગાળો જરૂરી હોય તેવી રિલીઝ અંદાજ સહિત જણાવે છે; દરેક રિલીઝમાં વધુમાં વધુ એક આવી રિલીઝ હોય છે.
2. પુનઃસ્થાપન અભ્યાસ ચલાવો, અથવા ખાતરી કરો કે આ રિલીઝ માટે તે સફળ રહ્યો છે (backup-restore.md). અભ્યાસ નિષ્ફળ જાય તો અપગ્રેડ અટકે છે.
3. આધાર બેકઅપ લો: docker compose -f docker/compose.yaml --profile backup run --rm backup.

Docker Compose, એક હોસ્ટ

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 ફાઇલથી), અને દરેકને એક પછી એક ફરી બનાવો; આગળ વધતાં પહેલાં દરેક સ્વસ્થ હોવાની ખાતરી કરો.

ઘણા હોસ્ટ અથવા ઓર્કેસ્ટ્રેટર

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

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

bun apps/worker/src/migrate.ts   # what the Compose step runs
bun run db:migrate:all                            # the same, from a checkout

દરેક સમર્પિત ડેટાબેઝ તેના નોંધાયેલા નામથી જોડાય છે. env:QUIRE_DB_NORTHWIND_URL તરીકે નોંધાયેલા ડેટાબેઝ માટે આ જરૂરી છે:

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

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 તરીકે:

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_RELEASE ને અગાઉના tag પર સેટ કરો અને ફરી up -d ચલાવો. તે ચાલે છે કારણ કે એક રિલીઝની અંદર સ્કીમા બંને દિશામાં સુસંગત છે.

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

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

અપગ્રેડની તપાસ

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