განახლება გათიშვის გარეშე

წესებია 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. ბოლოს worker-ები, რათა უახლესი მოვლენის ფორმა შეიქმნას, სანამ უახლესი მომხმარებელი მას მოელის. Worker-ები მაშინვე წყვეტენ აღებას და იღებენ 120 წამს; სამუშაო, რომელიც ვერ სრულდება, სხვაგან ხელახლა აიღება, რაც უსაფრთხოა, რადგან ყოველი სამუშაო იდემპოტენტურია. განრიგი ლიდერობას შემდეგ ტაქტზე გადასცემს.

ერთ ჰოსტზე Compose სათითაოდ ცვლის თითოეულ კონტეინერს, ასე რომ სერვისზე მოკლე წყვეტაა. წყვეტის გარეშე საერთოდ გაუშვით ვებ-დონე, როგორც ორი კონტეინერი თქვენი საკუთარი პროქსის უკან (გადაფარვის ფაილი, რომელიც ამატებს მეორე ვებსერვისს გამოქვეყნებული პორტის გარეშე), და ხელახლა შექმენით ისინი სათითაოდ, თითოეულის ჯანმრთელობის ანგარიშამდე ლოდინით შემდეგამდე.

რამდენიმე ჰოსტი ან ორკესტრატორი

გამოიყენეთ იგივე თანმიმდევრობა: მიგრაცია ერთხელ ერთი სამუშაოდან, შემდეგ ვებ-დონის გადახვევა მატებით ერთი და მიუწვდომლით ნული, შემდეგ worker-ები. მზაობის ზონდები /readyz-ზე მიმართეთ, ხოლო სიცოცხლის — /healthz-ზე.

გამოყოფილი მოიჯარის მონაცემთა ბაზებით migrate ნაბიჯი ორივეს აკეთებს: ის ატარებს მიგრაციას ჯერ საკონტროლო მონაცემთა ბაზაზე, შემდეგ ყველა მონაცემთა ბაზაზე, ჩამოთვლილს ops.tenant_database-ში, სათითაოდ, თითოეული საკუთარი საკეტის ქვეშ. წარუმატებლობა ერთ მოიჯარის მონაცემთა ბაზაში არ აჩერებს დანარჩენებს. როცა ყველა მონაცემთა ბაზა მზადაა, ის ადარებს მიგრაციის რეესტრებს და გამოდის არანულით, თუ ყველა მონაცემთა ბაზას არ აქვს გამოყენებული ზუსტად ის მიგრაციები, რაც საკონტროლო მონაცემთა ბაზას აქვს, თითოეულის დასახელებით, რომელიც ჩამორჩება ან უსწრებს. იგივე ბრძანება აყენებს რიგის ცხრილებს თითოეულ მონაცემთა ბაზაში, რადგან worker-ი მოიჯარის მიბმული სამუშაოებს იქ მოიხმარს, სადაც ისინი დაიწერა.

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 წერს შეტყობინებას და არაფერს ცვლის, ხოლო მოძიება ზუსტი რჩება. pgvector-ით 0.8-ზე ძველით სვეტი და ინდექსი აგებულია, მაგრამ მოძიება ზუსტი რჩება, სანამ გაფართოება არ განახლდება (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