तोंड बंदीशिवाय अपग्रेड

नियम 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 सेकंद मिळवतात; पूर्ण होऊ शकणारी जॉब दुसरीकडे पुन्हा घेतली जाते, जे सुरक्षित आहे कारण प्रत्येक जॉब बहु-विनंती सुरक्षित असते. शेड्यूलर पुढच्या टिकवर नेतृत्व सोडतो.

एका होस्टवर Compose प्रत्येक कंटेनर एकमेकानंतर बदलतो, त्यामुळे प्रत्येक सेवेसाठी छोटी तुकडी राहते. जराही तुकडी न पाहिजे तर वेब थिअर स्वतःच्या प्रॉक्सीमागे दोन कंटेनर म्हणून चालवा (प्रकाशित पोर्टशिवाय दुसरी वेब सेवा जोडणारी ओव्हरराइड फाइल), आणि ते एकेकावेळी पुन्हा तयार करा, पुढच्यापूर्वी प्रत्येकाच्या निरोगी असल्याची वृत्ती प्रतीक्षा करत.

अनेक होस्ट किंवा ऑर्केस्ट्रेटर

त्याच क्रम वापरा: एका जॉबमधून एकदाच मायग्रेट करा, नंतर surge एक आणि unavailable शून्य घेऊन वेब थिअर रोल करा, नंतर वर्कर. रेडीनेस प्रोब /readyz कडे आणि लाइव्हनेस /healthz कडे निर्देश करा.

समर्पित टेनंट डेटाबेसअसताना migrate पायरी दोन्ही करते: ती आधी कंट्रोल डेटाबेस मायग्रेट करते, नंतर ops.tenant_database मध्ये नोंदणीकृत प्रत्येक डेटाबेस, एकेकावेळी, प्रत्येक स्वतःच्या लॉकखाली. एका टेनंट डेटाबेसमध्ये अपयश इतर थांबवत नाही. प्रत्येक डेटाबेस पूर्ण झाल्यावर ते मायग्रेशन लेजर तुलना करतात आणि प्रत्येक डेटाबेसने कंट्रोल डेटाबेसने लागू केलेली मायग्रेशन हूबहू लागू केली नसतील तर शून्याबाहेरच्या क्रमाने बाहेर पडतात, मागे किंवा पुढे असलेली प्रत्येक नावासह. त्याच कमांड प्रत्येक डेटाबेसमध्ये क्यू तक्ते स्थापित करते, कारण वर्कर बांधलेल्या टेनंटची जॉब तिथेच जिथे ती लिहिल्या गेल्या तिथे वापरतो.

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 कनेक्शन नसलेला नोंदणीकृत डेटाबेस अपयश म्हणून नोंदवला जातो, कधीही वगळला जात नाही. कंट्रोल डेटाबेस पूर्ण झाल्यावर वेब थिअर एकदाच रोल होऊ शकतो. एका तासाने मागे असलेला टेनंट डेटाबेस सूचित करतो; एका दिवसाने तो पेज करतो.

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 म्हणून:

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

ते बहु-विनंती सुरक्षित आहे आणि enabled किंवा unavailable परत करते. प्रत्येक समर्पित टेनंट डेटाबेसवरही ते चालवा.

मागे वळणे

कोड मागे वळणे नेहमी उपलब्ध आहे: QUIRE_RELEASE ला मागील टॅगवर सेट करा आणि पुन्हा up -d करा. ते काम करते कारण आवृत्तीत स्कीमा दोन्ही दिशांनी अनुकूल असते.

स्कीमा मागे वळणे दिले जात नाही. जे पूर्ववत करता येत नाही आणि त्यातून कसे बरे व्हायचे:

त्यामुळेच संकुचित मायग्रेशन स्वतंत्रपणे जाते: त्यानंतर रिस्टोअरला स्वच्छ मर्यादा असते.

अपग्रेड तपासणे

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