Перайсці да змесціва

Абнаўленне без прастою

Абнавіце самастойна размешчаны Quire без прастою.

Праглядзець як Markdown

Працэдура вызначана ў раздзеле 7 docs/architecture/23-ops.md і раздзеле 4.1 docs/architecture/07-data.md.

Гарантыя бяспечнага абнаўлення

Выпуск R правільна працуе са схемай R і схемай R мінус адзін. Кожная змена схемы падзяляецца на пашырэнне, пераход і скарачэнне:

  1. Пашырэнне: дадаецца новы слупок, табліца або індэкс. Стары код яго ігнаруе.
  2. Пераход, прынамсі на працягу аднаго выпуску: новы код запісвае абедзве формы і чытае новую; заданне, якое можна аднавіць, пераносіць старыя радкі.
  3. Скарачэнне: старая форма выдаляецца асобна ў пазнейшым выпуску.

Такім чынам падчас паступовага абнаўлення старыя і новыя працэсы могуць карыстацца адной базай. Адкатных міграцый няма: міграцыя, якая гадзіну таму выдаліла слупок, не можа вярнуць радкі, запісаныя за гэтую гадзіну.

Заданне CI schema-compat правярае гэтую гарантыю для кожнага выпуску, запускаючы тэсты папярэдняга выпуску на новай схеме.

Перад пачаткам

  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 кожны працэс web змяняе стан /readyz на draining, завяршае актыўныя запыты за 30 секунд, закрывае патокі з падказкай перападключэння і спыняецца. stop_grace_period роўны 40 секундам, каб Compose не спыніў працэс да завяршэння карэктнага адключэння.
  3. Апошнія worker-ы, каб найноўшая форма падзеі пачала стварацца да таго, як яе чакае найноўшы спажывец. Worker адразу спыняе атрыманне новых заданняў і мае 120 секунд на завяршэнне; незавершанае заданне атрымае іншы працэс. Гэта бяспечна, бо ўсе заданні ідэмпатэнтныя. Планавальнік перадае лідарства пры наступным цыкле.

На адным хосце Compose замяняе кантэйнеры па чарзе, таму для кожнага сэрвісу будзе кароткі перапынак. Каб пазбегнуць яго цалкам, запусціце вэб-узровень у двух кантэйнерах за ўласным проксі (файл пераазначэння дадае другі сэрвіс web без апублікаванага порта) і перастварайце іх па адным, чакаючы паведамлення аб гатоўнасці кожнага перад наступным.

Некалькі хостаў або аркестратар

Выкарыстоўвайце той жа парадак: адзін раз запусціце міграцыю асобным заданнем, потым абнаўляйце вэб-узровень з surge адзін і unavailable нуль, затым 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

Звычайная міграцыя і першапачатковая налада таксама ўстаўляюць кананічныя англійскія праўныя дакументы аператара Quire у ops.platform_policy_version. Устаноўшчык ідэмапотэнтны: замяняюцца толькі адсутныя англійскія тэксты і дакладна тыя тэксты-запаволнікі, якія былі пасеяны міграцыяй. Пасевы архівуюцца і ўстаўляецца новая апублікаваная версія; гістарычныя спасылкі на прыняцце і тэксты захоўваюцца. Любая сапраўды аўтарская версія, уключаючы чарнавік, захоўваецца і павінна кіравацца праз кансоль палітык платформы. Дакументы, версіі і згода палітык тэнанта ніколі не змяняюцца гэтым пераходным этапам. Гэта публікацыя тэкстаў аператара, а не прававая сертыфікацыя і не аўтаматычнае выкананне яе абяцгаў.

Да кожнай выдзеленай базы звяртаюцца праз імя, пад якім яна зарэгістравана. Для базы з назвай env:QUIRE_DB_NORTHWIND_URL патрэбны:

Зменная Выкарыстанне
QUIRE_DB_NORTHWIND_URL Роля прыкладання для вэб-узроўню і worker
QUIRE_DB_NORTHWIND_URL_MIGRATOR Роля мігратара для гэтай каманды і пераносаў
QUIRE_DB_NORTHWIND_URL_SUPERUSER Неабавязкова: паўторна запускае пачатковую наладу (ролі, схемы, дапаможныя сродкі) перад міграцыяй

Зарэгістраваная база без злучэння _MIGRATOR адзначаецца як памылка, а не прапускаецца. Вэб-узровень можна абнаўляць пасля завяршэння базы кіравання. Адставанне базы кліента на гадзіну выклікае папярэджанне, на дзень — тэрміновае апавяшчэнне.

pgvector

Пачынаючы з міграцыі 0264, корпус кантэксту выкарыстоўвае індэкс pgvector HNSW, калі сервер мае гэтае пашырэнне; сэрвіс Compose postgres збіраецца з ім (docker/postgres.Dockerfile). Першая міграцыя migrate пасля змены вобраза стварае пашырэнне пачатковай наладай superuser, а 0264 дадае створаны вектарны слупок і будуе індэкс. Даданне слупка адзін раз перапісвае app.ai_chunk пад выключным блакаваннем, таму запыты кантэксту чакаюць; іншыя працэсы гэтую табліцу не змяняюць.

На серверы без pgvector міграцыя 0264 запісвае інфармацыйнае паведамленне і нічога не змяняе, а пошук застаецца дакладным. Калі версія pgvector ніжэйшая за 0.8, слупок і індэкс ствараюцца, але пошук застаецца дакладным да абнаўлення пашырэння (alter extension vector update), бо адфільтраваныя сканаванні HNSW патрабуюць ітэратыўнага пошуку з версіі 0.8. Каб пазней уключыць яго на серверы без пашырэння, усталюйце яго, паўтарыце пачатковую наладу (або выканайце 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. Запусціце яе таксама на кожнай выдзеленай базе кліента.

Адкат

Адкат кода заўсёды даступны: задайце 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
Навігацыя

Увядзіце запыт…

↑↓ навігацыя↵ выбрацьEsc закрыць