ການອັບເດດໂດຍບໍ່ມີເວລາຢຸດບໍລິການ

ກົດລະບຽບຢູ່ໃນ docs/architecture/23-ops.md ບົດທີ 7 ແລະ docs/architecture/07-data.md ບົດທີ 4.1. ນີ້ແມ່ນຂັ້ນຕອນການດຳເນີນງານ.

ການຮັບປະກັນທີ່ເຮັດໃຫ້ມັນປອດໄພ

ສະບັບເຜີຍແຜ່ R ແລ່ນຖືກຕ້ອງກັບ schema R ແລະ schema R ລວມໜຶ່ງ. ການປ່ຽນແປງ schema ທຸກໆຄັ້ງຖືກແບ່ງເປັນ expand, transition ແລະ contract:

1. ຂະຫຍາຍ: ເພີ່ມຖານ, ຕາຕະລາງ ຫຼື index ໃໝ່. ລະຫັດເກົ່າເບິ່ງ ຂ້າງມັນ.
2. ການປ່ຽນຜ່ານ, ສຳລັບຢ່າງໜ້ອຍໜຶ່ງສະບັບ: ລະຫັດໃໝ່ຂຽນ ທັງສອງຮູບແບບ ແລະ ອ່ານອັນໃໝ່; ງານທີ່ສາມາດສືບຕໍ່ໄດ້ເຕີມ ແຖວເກົ່າ.
3. ຫັກເອົາ: ລຶບຮູບແບບເກົ່າ, ໃນສະບັບຕໍ່ມາ, ໂດຍລະບຽວ.

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

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

ກ່ອນທີ່ທ່ານຈະເລີ່ມ

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

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

ເຊີບເວີຫຼາຍໜ່ວຍ ຫຼື orchestrator

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

ດ້ວຍຖານຂໍ້ມູນ tenant ສະເພາະ ຂັ້ນຕອນ migrate ເຮັດທັງສອງຢ່າງ: ມັນຍ້າຍຖານຂໍ້ມູນຄວບຄຸມກ່ອນ, ຈາກນັ້ນຖານຂໍ້ມູນທຸກໆແຫ່ງທີ່ ລາຍຊື່ໃນ ops.tenant_database, ທີ່ລະຄັ້ງ, ແຕ່ລະອັນພາຍໃຕ້ lock ຂອງຕົນເອງ. ການລົ້ມແຫຼວໃນຖານຂໍ້ມູນ tenant ໜຶ່ງບໍ່ຢຸດຄົນ ອື່ນ. ເມື່ອຖານຂໍ້ມູນທຸກໆແຫ່ງສຳເລັດ ມັນປຽບທຽບບົດບັນທຶກ ການຍ້າຍ ແລະອອກດ້ວຍຄ່າບໍ່ສູນເວັ້ນແຕ່ຖ້າຖານຂໍ້ມູນທຸກໆແຫ່ງ ໄດ້ນຳໃຊ້ການຍ້າຍທີ່ຖານຂໍ້ມູນຄວບຄຸມມີຢ່າງແນ່ນອນ ໂດຍລະບຸ ແຕ່ລະອັນທີ່ຊ້າ ຫຼື ໄວກວ່າ. ຄຳສັ່ງດຽວກັນຕິດຕັ້ງຕາຕະລາງ queue ໃນແຕ່ລະຖານຂໍ້ມູນ ເພາະ worker ບໍລິໂພກງານຂອງ tenant ທີ່ຖືກ pin ໃນບ່ອນທີ່ພວກມັນຖືກຂຽນ.

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 ຕ້ອງການ:

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

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:

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_RELEASE ເປັນ tag ກ່ອນໜ້າ ແລະ 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