ការធ្វើឱ្យប្រសើរដោយគ្មានការផ្អាក

ច្បាប់ស្ថិតក្នុង docs/architecture/23-ops.md ផ្នែក 7 និង docs/architecture/07-data.md ផ្នែក 4.1។ នេះជាដំណើរការ។

ការធានាដែលធ្វើឱ្យវាសុវត្ថិភាព

កំណែ R ដំណើរការត្រឹមត្រូវប្រឆាំងនឹង schema R និង schema R បូកសូន្យមួយ។ ការផ្លាស់ប្តូរ schema នីមួយៗត្រូវបានបែកចេញជា expand, transition និង contract៖

1. Expand៖ បន្ថែមជួរឈ្មោះ តារា ឬ index ថ្មី។ កូឌូចាស់មិនឃើញវា។
2. Transition យ៉ាងតិចសម្រាប់មួយកំណែ៖ កូឌូថ្មីសរសេរទម្រង់ទាំងពីរ និងអានថ្មី។ ការងារដែលអាចបន្តបានបំពេញជួរចាស់។
3. Contract៖ ទម្លាក់ទម្រង់ចាស់ ក្នុងកំណែក្រោយមក ដោយឡែក។

ដូច្នេះនៅគ្រប់ពេលនៃការធ្វើឱ្យប្រសើរ rolling ដំណើរការចាស់ និងថ្មីអាចចែករំលែកមូលដ្ឋានទិន្នន័យមួយ។ គ្មានការផ្លាស់ប្តូរចុះក្រោមទេ៖ ការផ្លាស់ប្តូរដែលបានទម្លាក់ជួរមួយម៉ោងមុនមិនអាចប្រគល់ជួរដែលបានសរសេរក្នុងម៉ោងនោះត្រឡប់វិញបានទេ។

ការងារ CI schema-compat ពិនិត្យការធានារាល់កំណែដោយដំណើរការការសាកល្បងនៃកំណែមុនប្រឆាំងនឹង schema ថ្មី។

មុននឹងអ្នកចាប់ផ្តើម

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. ផ្លាស់ប្តូរជាមុនសិន ខណៈកំណែចាស់បម្រើចរាចរ។ ការផ្លាស់ប្តូរ expand មិនឃើញសម្រាប់វាទេ។
2. ស្រទាប់ web បន្ទាប់។ លើ SIGTERM ដំណើរការ web នីមួយៗប្តូរ /readyz ទៅ draining បញ្ចប់សំណើដែលកំពុងហោះហើរក្នុង 30 វិនាទី បិទ stream ជាមួយសញ្ញាតភ្ជាប់ឡើងវិញ ហើយចេញ។ stop_grace_period ជា 40 វិនាទី ដូច្នេះ Compose មិនដែលកាត់ការបង្ហូរដែលសុខភាពល្អទេ។
3. Worker ចុងក្រោយ ដូច្នេះទម្រង់ព្រឹត្តិការណ៍ថ្មីបំផុតត្រូវបានផលិតមុនអ្នកទទួលថ្មីបំផុតរំពឹង។ Worker ឈប់ទទួលភ្លាមៗ ហើយទទួល 120 វិនាទី។ ការងារដែលមិនអាចបញ្ចប់បានត្រូវបានទទួលម្តងទៀតនៅកន្លែងផ្សេង ដែលសុវត្ថិភាពព្រោះការងារនីមួយៗស្ថិតនិរន្តរ៍។ scheduler ប្រគល់ភាពជាអ្នកដឹកនាំក្នុង tick បន្ទាប់របស់វា។

លើម៉ាស៊ីនមួយ Compose ជំនួស container នីមួយៗជាបន្តបន្ទាប់ ដូច្នេះមានគម្លាតខ្លីក្នុងមួយសេវា។ ដើម្បីគ្មានគម្លាតទាំងស្រុង ដំណើរការស្រទាប់ web ជា container ពីរនៅក្រោម proxy ផ្ទាល់របស់អ្នក (ឯកសារ override ដែលបន្ថែមសេវា web ទីពីរដោយគ្មានច្រកដែលបានផ្សាយ) ហើយបង្កើតឡើងវិញមួយម្តងៗ រង់ចាំមួយៗរាយការណ៍ថាសុខភាពល្អមុនបន្ទាប់។

ម៉ាស៊ីនច្រើន ឬ orchestrator

ប្រើលំដាប់ដដែល៖ ផ្លាស់ប្តូរមួយដងពីការងារមួយ រួចចង្កោមស្រទាប់ web ជាមួយ surge one និង unavailable zero រួច worker។ ចង្អុល probe ភាពរួចរាល់ទៅ /readyz និងភាពរស់ទៅ /healthz។

ជាមួយមូលដ្ឋានទិន្នន័យ tenant លាក់ ជំហាន migrate ធ្វើរឿងទាំងពីរ៖ វាផ្លាស់ប្តូរមូលដ្ឋានទិន្នន័យត្រួតពិនិត្យជាមុនសិន រួចមូលដ្ឋានទិន្នន័យទាំងអស់ដែលបានរាយក្នុង ops.tenant_database មួយម្តងៗ នីមួយៗក្រោម lock ផ្ទាល់របស់វា។ ការបរាជ័យក្នុងមូលដ្ឋានទិន្នន័យ tenant មួយមិនឈប់អ្នកដទៃទេ។ នៅពេលមូលដ្ឋានទិន្នន័យទាំងអស់ចប់ វាប្រៀបធៀប ledger នៃការផ្លាស់ប្តូរ ហើយចេញ non-zero លើកលែងតែមូលដ្ឋានទិន្នន័យនីមួយៗបានអនុវត្តចំណុចផ្លាស់ប្តូរដែលមូលដ្ឋានទិន្នន័យត្រួតពិនិត្យបានអនុវត្តពិតប្រាកដ ដោយដាក់ឈ្មោះនីមួយៗដែលនៅក្រោយ ឬនៅមុន។ ពាក្យបញ្ជាដដែលដំឡើងតារាងជញ្ជាំងការងារក្នុងមូលដ្ឋានទិន្នន័យនីមួយៗ ព្រោះ worker ប្រើបញ្ជីការងារនៃ tenant ដែលបាន pin នៅកន្លែងដែលពួកវាត្រូវបានសរសេរ។

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 ត្រូវបានរាយការណ៍ជាកំហុស មិនដែលរំលងទេ។ ស្រទាប់ web អាចចង្កោមបាននៅពេលមូលដ្ឋានទិន្នន័យត្រួតពិនិត្យចប់។ មូលដ្ឋានទិន្នន័យ tenant ដែលនៅក្រោយមួយម៉ោងព្រមាន។ មួយថ្ងៃវាបញ្ជូនសារ។

pgvector

ចាប់ពីការផ្លាស់ប្តូរ 0264 corpus នៃ grounding ប្រើ index HNSW pgvector នៅពេលម៉ាស៊ីនបម្រើមានកម្មវិធីជំនួយ។ សេវា postgres របស់ Compose ត្រូវបានសង់ជាមួយវា (docker/postgres.Dockerfile)។ migrate ដំបូងបន្ទាប់ពីការផ្លាស់រូបភាពបង្កើតកម្មវិធីជំនួយតាម bootstrap superuser ហើយ 0264 បន្ទាប់មកបន្ថែមជួរ vector ដែលបានបង្កើត ហើយសង់ index។ ការបន្ថែមជួរសរសេរ app.ai_chunk មួយដងក្រោម lock exclusive ដូច្នេះសំណើ grounding រង់ចាំវា។ គ្មានអ្វីផ្សេងប៉ះតារាងនោះទេ។

លើម៉ាស៊ីនបម្រើដែលគ្មាន pgvector 0264 កត់ត្រាការជូនដំណឹងមួយ ហើយមិនផ្លាស់ប្តូរអ្វី ហើយការទាញយកនៅតែពិតប្រាកដ។ ជាមួយ pgvector ចាស់ជាង 0.8 ជួរ និង index ត្រូវបានសង់ ប៉ុន្តែការទាញយកនៅតែពិតប្រាកដរហូតដល់កម្មវិធីជំនួយត្រូវបានធ្វើឱ្យប្រសើរ (alter extension vector update) ព្រោះការស្វែងរក HNSW ដែលបានចម្រាញ់ត្រូវការ iterative scans នៃ 0.8។ ដើម្បីបើកវាក្រោយមកលើម៉ាស៊ីនបម្រើដែលគ្មានវា ដំឡើងកម្មវិធីជំនួយ ដំណើរការ bootstrap ម្តងទៀត (ឬ create extension vector ជា superuser) រួចជា quire_migrator៖

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

វាស្ថិតនិរន្តរ៍ ហើយត្រឡប់ enabled ឬ unavailable។ ដំណើរការវាលើមូលដ្ឋានទិន្នន័យ tenant លាក់នីមួយៗផង។

ការត្រឡប់ក្រោយ

ការត្រឡប់កំណែ កូឌូ មានជានិច្ច៖ កំណត់ QUIRE_RELEASE ទៅស្លាកមុន ហើយ up -d ម្តងទៀត។ នេះដំណើរការព្រោះ schema ឆែកឆេងគ្នាទាំងពីរទិសក្នុងកំណែមួយ។

ការត្រឡប់ schema មិនត្រូវបានផ្តល់ទេ។ អ្វីដែលមិនអាចលុបបំពានបាន និងរបៀបស្តារឡើងវិញពីវា៖

នេះហើយជាមូលហេតុដែលការផ្លាស់ប្តូរ contract ចេញផ្សាយដោយឡែក៖ ការស្តារបន្ទាប់មកមានដែនសម្អាតច្បាស់។

ការពិនិត្យការធ្វើឱ្យប្រសើរ

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