---
title: "ການອັບເດດໂດຍບໍ່ມີເວລາຢຸດບໍລິການ"
description: "ອັບເດດ Quire ຕິດຕັ້ງເອງໂດຍບໍ່ມີເວລາຢຸດບໍລິການ."
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/lo/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. **ຂະຫຍາຍ**: ເພີ່ມຖານ, ຕາຕະລາງ ຫຼື index ໃໝ່. ລະຫັດເກົ່າເບິ່ງ
   ຂ້າງມັນ.
2. **ການປ່ຽນຜ່ານ**, ສຳລັບຢ່າງໜ້ອຍໜຶ່ງສະບັບ: ລະຫັດໃໝ່ຂຽນ
   ທັງສອງຮູບແບບ ແລະ ອ່ານອັນໃໝ່; ງານທີ່ສາມາດສືບຕໍ່ໄດ້ເຕີມ
   ແຖວເກົ່າ.
3. **ຫັກເອົາ**: ລຶບຮູບແບບເກົ່າ, ໃນສະບັບຕໍ່ມາ, ໂດຍລະບຽວ.

ດັ່ງນັ້ນໃນທຸກໆເຄື່ອງມືຂອງການອັບເດດແບບໜ້າໄປຕໍ່ໜ້າ ຂະບວນການ
ເກົ່າ ແລະ ໃໝ່ສາມາດແບ່ງຖານຂໍ້ມູນດຽວກັນ. ບໍ່ມີການຍ້າຍກັບ
ລຸ່ມ: ການຍ້າຍທີ່ລຶບຖານໜຶ່ງໃນເມື່ອຊົ່ວໂມງກ່ອນບໍ່ສາມາດຄືບ
້ານແຖວທີ່ຂຽນໄວ້ໃນຊົ່ວໂມງນັ້ນຄືນໄດ້.

ງານ CI `schema-compat` ກວດສອບການຮັບປະກັນໃນທຸກສະບັບໂດຍການ
ແລ່ນການທົດສອບຂອງສະບັບກ່ອນໜ້ານີ້ກັບ schema ໃໝ່.

## ກ່ອນທີ່ທ່ານຈະເລີ່ມ <!--quire:before-you-start-->

1. ອ່ານບັນທຶກການເຜີຍແຜ່. ສະບັບທີ່ຕ້ອງການຊ່ວງເວລາບຳລຸງບອກ
   ດັ່ງນັ້ນ ພ້ອມການປະເມີນ; ສູງສຸດໜຶ່ງຄັ້ງຕໍ່ສະບັບ.
2. ແລ່ນການຝຶກການກູ້ຄືນ ຫຼື ຢືນຢັນວ່າມັນແລ່ນຜ່ານສຳລັບ
   ສະບັບນີ້ ([backup-restore.md](/lo/ops/backup-restore/)). ການຝຶກທີ່ລົ້ມ
   ແຫຼວກັດການອັບເດດ.
3. ເຮັດ base backup: `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. **ຍ້າຍກ່ອນ**, ໃນຂະນະທີ່ສະບັບເກົ່າບໍລິການການຈຳກັດ. ການ
   ຍ້າຍຂະຫຍາຍເຫັນບໍ່ເຫັນສຳລັບມັນ.
2. **ຊັ້ນເວັບຕໍ່ໄປ.** ໃນ SIGTERM ຂະບວນການເວັບແຕ່ລະອັນສະຫຼັບ
   `/readyz` ເປັນ `draining`, ສຳເລັດຄຳຮ້ອງຂໍທີ່ກຳລັງດຳເນີນພາຍ
   ໃນ 30 ວິນາທີ, ປິດ streams ພ້ອມ hints ການເຊື່ອມຕໍ່ຄືນ, ແລະ
   ອອກ. `stop_grace_period` ແມ່ນ 40 ວິນາທີ ດັ່ງນັ້ນ Compose ບໍ່ເຄີຍ
   ຕັດການ drain ທີ່ສະບາຍດີ.
3. **Workers ສຸດທ້າຍ**, ເພື່ອໃຫ້ຮູບແບບເຫດການໃໝ່ສຸດຖືກຜະລິດ
   ກ່ອນທີ່ຜູ້ບໍລິໂພກໃໝ່ສຸດຈະຄາດໝາຍ. Workers ຢຸດການດຶງທັນທີ
   ແລະໄດ້ 120 ວິນາທີ; ງານທີ່ສຳເລັດບໍ່ໄດ້ຈະຖືກດຶງຄືນໃນບ່ອນ
   ອື່ນ ເຊິ່ງປອດໄພເພາະງານທຸກໆອັນເປັນ idempotent. Scheduler
   ມອບການນຳໜ້າໃນ tick ຕໍ່ໄປຂອງມັນ.

ຢູ່ເຊີບເວີດຽວ Compose ແທນທີ່ແຕ່ລະ container ເທື່ອລະອັນ ດັ່ງນັ້ນ
ມີຊ່ວງຫວ່າງສັ້ນໆຕໍ່ບໍລິການ. ເພື່ອບໍ່ໃຫ້ມີຊ່ວງຫວ່າງເລີຍ
ແລ່ນຊັ້ນເວັບເປັນສອງ container ຢູ່ເບື້ອງຫຼັງ proxy ຂອງທ່ານເອງ
(ໄຟລ໌ override ທີ່ເພີ່ມບໍລິການ web ທີສອງໂດຍບໍ່ມີພອດທີ່ເຜີຍ
ແຜ່) ແລະສ້າງພວກມັນຄືນໜຶ່ງຄັ້ງຕໍ່ອັນ ລໍຖ້າແຕ່ລະອັນລາຍ
ງານວ່າສະບາຍດີກ່ອນຄັ້ງຕໍ່ໄປ.

## ເຊີບເວີຫຼາຍໜ່ວຍ ຫຼື orchestrator <!--quire:several-hosts-or-an-orchestrator-->

ໃຊ້ລຳດັບດຽວກັນ: ຍ້າຍໜຶ່ງຄັ້ງຈາກງານດຽວ, ຈາກນັ້ນແກວງຊັ້ນ
ເວັບດ້ວຍ surge ໜຶ່ງ ແລະ unavailable ສູນ, ຈາກນັ້ນ workers. ຊີ້
probes ການພ້ອມໄປ `/readyz` ແລະ liveness ໄປ `/healthz`.

ດ້ວຍຖານຂໍ້ມູນ tenant ສະເພາະ ຂັ້ນຕອນ `migrate` ເຮັດທັງສອງຢ່າງ:
ມັນຍ້າຍຖານຂໍ້ມູນຄວບຄຸມກ່ອນ, ຈາກນັ້ນຖານຂໍ້ມູນທຸກໆແຫ່ງທີ່
ລາຍຊື່ໃນ `ops.tenant_database`, ທີ່ລະຄັ້ງ, ແຕ່ລະອັນພາຍໃຕ້ lock
ຂອງຕົນເອງ. ການລົ້ມແຫຼວໃນຖານຂໍ້ມູນ tenant ໜຶ່ງບໍ່ຢຸດຄົນ
ອື່ນ. ເມື່ອຖານຂໍ້ມູນທຸກໆແຫ່ງສຳເລັດ ມັນປຽບທຽບບົດບັນທຶກ
ການຍ້າຍ ແລະອອກດ້ວຍຄ່າບໍ່ສູນເວັ້ນແຕ່ຖ້າຖານຂໍ້ມູນທຸກໆແຫ່ງ
ໄດ້ນຳໃຊ້ການຍ້າຍທີ່ຖານຂໍ້ມູນຄວບຄຸມມີຢ່າງແນ່ນອນ ໂດຍລະບຸ
ແຕ່ລະອັນທີ່ຊ້າ ຫຼື ໄວກວ່າ. ຄຳສັ່ງດຽວກັນຕິດຕັ້ງຕາຕະລາງ
queue ໃນແຕ່ລະຖານຂໍ້ມູນ ເພາະ 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: ມີແຕ່ເນື້ອໃນພາສາອັງກິດທີ່ຂາດ ແລະ ເນື້ອໃນ placeholder ທີ່ແນ່ນອນທີ່ການໂອນຍ້າຍໄດ້ສ້າງໄວ້ເທົ່ານັ້ນທີ່ຖືກປ່ຽນແທນ. Seeds ຖືກເກັບເຂົ້າຄັງ ແລະ ເພີ່ມເວີຊັນເຜີຍແຜ່ໃໝ່; ເອກະສານອ້າງອີງການຍອມຮັບປະຫວັດສາດ ແລະ ເນື້ອໃນຍັງຄົງຢູ່. ເວີຊັນແທ້ໃດທີ່ຜູ້ດຳເນີນງານຂຽນ ລວມທັງຮ່າງ ຖືກຮັກສາໄວ້ ແລະ ຕ້ອງຈັດການຜ່ານຄອນໂຊນນະໂຍບາຍຂອງແພລດຟອມ. ເອກະສານ ເວີຊັນ ແລະ ຄວາມຍິນຍອມນະໂຍບາຍຂອງຜູ້ເຊົ່າບໍ່ເຄີຍປ່ຽນແປງດ້ວຍການຕັດໂອນນີ້. ນີ້ແມ່ນການເຜີຍແຜ່ຂໍ້ຄວາມຂອງຜູ້ດຳເນີນງານ ບໍ່ແມ່ນການຮັບຮອງທາງກົດໝາຍ ຫຼື ການປະຕິບັດຕາມສັນຍາໂດຍອັດຕະໂນມັດ.


ຖານຂໍ້ມູນສະເພາະແຕ່ລະແຫ່ງເຂົ້າເຖິງຜ່ານຊື່ທີ່ມັນລົງທະບຽນ.
ຖານຂໍ້ມູນທີ່ລົງທະບຽນເປັນ `env:QUIRE_DB_NORTHWIND_URL` ຕ້ອງການ:

| ຕົວແປ | ໃຊ້ສຳລັບ |
| --- | --- |
| `QUIRE_DB_NORTHWIND_URL` | ບົດບາດແອັບພັກ, ສຳລັບຊັ້ນເວັບ ແລະ worker |
| `QUIRE_DB_NORTHWIND_URL_MIGRATOR` | ບົດບາດ migrator, ສຳລັບຄຳສັ່ງນີ້ ແລະການຍ້າຍ |
| `QUIRE_DB_NORTHWIND_URL_SUPERUSER` | ທາງເລືອກ: ນຳໃຊ້ bootstrap ຄືນ (ບົດບາດ, schemas, helpers) ກ່ອນການຍ້າຍ |

ຖານຂໍ້ມູນທີ່ລົງທະບຽນແລ້ວທີ່ບໍ່ມີການເຊື່ອມຕໍ່ `_MIGRATOR` ຈະ
ຖືກລາຍງານເປັນຄວາມລົ້ມແຫຼວ ບໍ່ເຄີຍຂ້າມ. ຊັ້ນເວັບສາມາດ
ແກວງໄດ້ເມື່ອຖານຂໍ້ມູນຄວບຄຸມສຳເລັດແລ້ວ. ຖານຂໍ້ມູນ tenant
ທີ່ຊ້າໜຶ່ງຊົ່ວໂມງຈະເຕືອນ; ໜຶ່ງມື້ຈະແຈ້ງເຕືອນໃຫຍ່.

## pgvector <!--quire:pgvector-->

ນັບແຕ່ການຍ້າຍ 0264 corpus ຂອງການອ້າງອີງໃຊ້ index pgvector HNSW
ບ່ອນທີ່ເຊີບເວີມີ extension; ບໍລິການ `postgres` ຂອງ Compose ຖືກ
ສ້າງດ້ວຍມັນ (`docker/postgres.Dockerfile`). `migrate` ຄັ້ງທຳອິດ
ຫຼັງຈາກສະຫຼັບຮູບລະບົບສ້າງ extension ຜ່ານ superuser bootstrap
ແລະ 0264 ຈາກນັ້ນເພີ່ມຖານ vector ທີ່ສ້າງຂຶ້ນມາ ແລະສ້າງ index.
ການເພີ່ມຖານຂຽນ `app.ai_chunk` ໜຶ່ງຄັ້ງພາຍໃຕ້ lock ທີ່ຖືກ
ກະທຳກັນ ດັ່ງນັ້ນຄຳຮ້ອງຂໍຂອງ groundingລໍຖ້າມັນ; ບໍ່ມີຫຍັງ
ອື່ນແຕะຕາຕະລາງນັ້ນ.

ເທິງເຊີບເວີໂດຍບໍ່ມີ pgvector 0264 ບັນທຶກ notice ໜຶ່ງແລະບໍ່
ປ່ຽນຫຍັງ ແລະການດຶງຍັງຖືກຕ້ອງ. ດ້ວຍ pgvector ທີ່ເກົ່າກວ່າ
0.8 ຖານ ແລະ index ຖືກສ້າງແຕ່ການດຶງຍັງຖືກຕ້ອງຈົນກວ່າ extension
ຈະຖືກອັບເດດ (`alter extension vector update`) ເພາະການສະແກນ
HNSW ທີ່ຖືກກອງຕ້ອງການ iterative scans ຂອງ 0.8. ເພື່ອເປີດມັນ
ຕໍ່ມາໃນເຊີບເວີທີ່ບໍ່ມີມັນ ຕິດຕັ້ງ extension, ແລ່ນ 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();
```

ມັນເປັນ idempotent ແລະຄືບ້ານ `enabled` ຫຼື `unavailable`. ແລ່ນ
ມັນໃນຖານຂໍ້ມູນ tenant ສະເພາະແຕ່ລະແຫ່ງດ້ວຍ.

## ການກັບຄືນ <!--quire:rolling-back-->

ການກັບຄືນ **ລະຫັດ** ມີໃຫ້ສະເໝີ: ຕັ້ງ `QUIRE_RELEASE` ເປັນ
tag ກ່ອນໜ້າ ແລະ `up -d` ອີກຄັ້ງ. ມັນເຮັດວຽກເພາະ schema ເປັນ
ເຂົ້າກັນໄດ້ໃນທັງສອງທິດທາງພາຍໃນສະບັບໜຶ່ງ.

ການກັບຄືນ **schema** ບໍ່ຖືກສະເໜີ. ສິ່ງທີ່ຍົກເລີກບໍ່ໄດ້ ແລະ
ວິທີຟື້ນຟູຈາກມັນ:

| ບໍ່ສາມາດກັບຄືນ | ການຟື້ນຟູ |
| --- | --- |
| ການຍ້າຍ contract ທີ່ລຶບຖານໜຶ່ງ | ການກູ້ຄືນຕາມຈຸດເວລາກ່ອນການລຶບເຂົ້າຖານຂໍ້ມູນໃໝ່, ດຶງອອກ, ລວມເຂົ້າກັນ |
| ການປ່ຽນຂໍ້ມູນໃນສະຖານທີ່ | ສິ່ງດຽວກັນ, ຈາກນັ້ນປະສົງກັບການຂຽນນັບແຕ່ນັ້ນມາ |
| webhook ແລະ ເຫດການທີ່ສົ່ງແລ້ວ | ເຫດການຊົດເຊີຍ, ບໍ່ເຄີຍລຶບ |
| ອີເມວທີ່ສົ່ງແລ້ວ | ຄົນເຂົ້າຂໍ້ຄວາມຕິດຕາມ |
| ແສນ hash chain ການກວດກາ | ບໍ່ເຄີຍຂຽນທັບ; ເພີ່ມລາຍການແກ້ໄຂ |

ນັ້ນແມ່ນເຫດຜົນທີ່ການຍ້າຍ 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/lo/ops/upgrade/index.mdx