---
title: "ការធ្វើឱ្យប្រសើរដោយគ្មានការផ្អាក"
description: "ធ្វើឱ្យប្រសើរ Quire self-hosted ដោយគ្មានការផ្អាក។"
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/km/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 ដំណើរការត្រឹមត្រូវប្រឆាំងនឹង schema R និង schema R បូកសូន្យមួយ។** ការផ្លាស់ប្តូរ schema នីមួយៗត្រូវបានបែកចេញជា expand, transition និង contract៖

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

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

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

## មុននឹងអ្នកចាប់ផ្តើម <!--quire:before-you-start-->

1. អានកំណត់ត្រាការចេញផ្សាយ។ កំណែដែលត្រូវការកាលបរិច្ឆេទថែទាំប្រាប់ដូច្នេះ ជាមួយការប៉ាន់ស្មាន។ យ៉ាងច្រើនប៉ុន្មានមួយក្នុងមួយកំណែ។
2. ដំណើរការលំហាត់ស្តារឡើងវិញ ឬបញ្ជាក់ថាវាបានដំណើរការជោគជ័យសម្រាប់កំណែនេះ ([backup-restore.md](/km/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. **ផ្លាស់ប្តូរជាមុនសិន** ខណៈកំណែចាស់បម្រើចរាចរ។ ការផ្លាស់ប្តូរ 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 <!--quire:several-hosts-or-an-orchestrator-->

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

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

```sh
bun apps/worker/src/migrate.ts   # what the Compose step runs
bun run db:migrate:all                            # the same, from a checkout
```
ការធ្វើចំណាកស្រុកធម្មតា និងការរៀបចំដំណើរការលើកដំបូងក៏ដំឡើងឯកសារច្បាប់ភាសាអង់គ្លេសផ្លូវការរបស់ប្រតិបត្តិករ Quire ទៅក្នុង `ops.platform_policy_version` ផងដែរ។ កម្មវិធីដំឡើងគឺ idempotent៖ មានតែតួអង់គ្លេសដែលបាត់ និងតួរកន្លែងពិតប្រាកដដែលការធ្វើចំណាកស្រុកបានបង្កើតទេដែលត្រូវជំនួស។ គ្រាប់ពូជត្រូវបានទុកក្នុងប័ណ្ណសារ ហើយកំណែបោះពុម្ពថ្មីត្រូវបានបញ្ចូល។ ឯកសារយោងទទួលយកប្រវត្តិសាស្ត្រ និងតួរក្សាទុក។ កំណែពិតប្រាកដណាមួយដែលប្រតិបត្តិករបានសរសេរ រួមទាំងសេចក្តីព្រាង ត្រូវបានរក្សាទុក ហើយត្រូវគ្រប់គ្រងតាមរយៈកុងសូលគោលការណ៍របស់វេទិកា។ ឯកសារ កំណែ និងការយល់ព្រមគោលការណ៍របស់អ្នកជួលមិនត្រូវបានផ្លាស់ប្តូរដោយការកាត់ផ្តាច់នេះឡើយ។ នេះគឺការបោះពុម្ពអត្ថបទប្រតិបត្តិករ មិនមែនវិញ្ញាបនបត្រច្បាប់ ឬការបំពេញសន្យារបស់ខ្លួនដោយស្វ័យប្រវត្តិទេ។


មូលដ្ឋានទិន្នន័យលាក់នីមួយៗឈានដល់តាមឈ្មោះដែលវាបានចុះឈ្មោះ។ មូលដ្ឋានទិន្នន័យដែលបានចុះឈ្មោះជា `env:QUIRE_DB_NORTHWIND_URL` ត្រូវការ៖

| អថេរ | ប្រើសម្រាប់ |
| --- | --- |
| `QUIRE_DB_NORTHWIND_URL` | តួនាទីកម្មវិធី សម្រាប់ស្រទាប់ web និង worker |
| `QUIRE_DB_NORTHWIND_URL_MIGRATOR` | តួនាទី migrator សម្រាប់ពាក្យបញ្ជានេះ និងសម្រាប់ការផ្លាស់ទី |
| `QUIRE_DB_NORTHWIND_URL_SUPERUSER` | ជម្រើស៖ អនុវត្តឡើងវិញនូវ bootstrap (តួនាទី schema helper) មុនការផ្លាស់ប្តូរ |

មូលដ្ឋានទិន្នន័យដែលបានចុះឈ្មោះដែលគ្មានការតភ្ជាប់ `_MIGRATOR` ត្រូវបានរាយការណ៍ជាកំហុស មិនដែលរំលងទេ។ ស្រទាប់ web អាចចង្កោមបាននៅពេលមូលដ្ឋានទិន្នន័យត្រួតពិនិត្យចប់។ មូលដ្ឋានទិន្នន័យ tenant ដែលនៅក្រោយមួយម៉ោងព្រមាន។ មួយថ្ងៃវាបញ្ជូនសារ។

## pgvector <!--quire: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`៖

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

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

## ការត្រឡប់ក្រោយ <!--quire:rolling-back-->

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

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

| មិនអាចត្រឡប់បាន | ការស្តារ |
| --- | --- |
| ការផ្លាស់ប្តូរ contract ដែលបានទម្លាក់ជួរមួយ | ការស្តារចំពោះពេលវេលាទៅមុនការទម្លាក់ទៅក្នុងមូលដ្ឋានទិន្នន័យថ្មី យកចេញ បូករួម |
| ការផ្លាស់ប្តូរទិន្នន័យក្នុងកន្លែង | ដដែល រួចផ្គូផ្គងការសរសេរចាប់តាំងពីនោះ |
| webhooks និងព្រឹត្តិការណ៍ដែលបានផ្ញើ | ព្រឹត្តិការណ៍សងសឹក មិនដែលលុបទេ |
| អ៊ីមែលដែលបានផ្ញើ | មនុស្សសរសេរការតាមដាន |
| ខ្សែ hash សវនកម្ម | មិនដែលសរសេរឡើងវិញទេ។ បន្ថែមធាតុកែតម្រូវ |

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

## ការពិនិត្យការធ្វើឱ្យប្រសើរ <!--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/km/ops/upgrade/index.mdx