--- title: "ရပ်နားမှုမရှိဘဲ အဆင့်မြှင့်ခြင်း" description: "ကိုယ်တိုင်လက်ခံသော Quire ကို ရပ်နားမှုမရှိဘဲ အဆင့်မြှင့်ပါ။" image: "https://docs.quirelms.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://docs.quirelms.com/my/llms.txt > Use this file to discover all available pages before exploring further. # ရပ်နားမှုမရှိဘဲ အဆင့်မြှင့်ခြင်း စည်းမျဉ်းများက `docs/architecture/23-ops.md` အပိုင်း ၇ နှင့် `docs/architecture/07-data.md` အပိုင်း 4.1 တွင် ရှိသည်။ ဤက လုပ်ထုံးလုပ်နည်း ဖြစ်သည်။ ## ၎င်းကို ဘေးကင်းစေသောအာမခံချက် **ထုတ်ဝေမှု R က schema R နှင့် schema R အနုတ် တစ်နှင့် မှန်ကန်စွာ လည်ပတ်သည်။** Schema ပြောင်းလဲမှုတိုင်းကို ချဲ့ထွင်မှု၊ အသွင်ကူးပြောင်းမှုနှင့် စာချုပ်ဟူ၍ ခွဲသည်– 1. **ချဲ့ထွင်ပါ**– ကော်လံ၊ ဇယား သို့မဟုတ် အညွှန်းအသစ် ထည့်ပါ။ ကုဒ်ဟောင်းက ၎င်းကို လျစ်လျူရှုသည်။ 2. **အသွင်ကူးပြောင်းပါ**၊ ထုတ်ဝေမှုအနည်းဆုံးတစ်ခုအတွက်– ကုဒ်အသစ်က ပုံသဏ္ဌာန်နှစ်ခုစလုံး ရေးပြီး အသစ်ကို ဖတ်သည်။ ပြန်စလို့ရသောအလုပ်က အတန်းဟောင်းများ ပြန်ဖြည့်သည်။ 3. **စာချုပ်**– ပုံသဏ္ဌာန်ဟောင်း ဖြုတ်ချပါ၊ နောက်ထုတ်ဝေမှုတစ်ခု တည်းတင်။ ထို့ကြောင့် လှိမ့်အဆင့်မြှင့်မှု၏ခဏတိုင်းတွင် လုပ်ငန်းစဉ်ဟောင်းနှင့် အသစ်က ဒေတာဘေ့စ်တစ်ခု မျှဝေနိုင်သည်။ အဆင်းရွှေ့ပြောင်းမှုများ မရှိပါ– တစ်နာရီအလို ကော်လံတစ်ခု ဖြုတ်ချသောရွှေ့ပြောင်းမှုက ထိုတစ်နာရီတွင် ရေးခဲ့သောအတန်းများ ပြန်ပေး၍မရပါ။ `schema-compat` CI အလုပ်က ထုတ်ဝေမှုတိုင်းတွင် ယခင်ထုတ်ဝေမှု၏စမ်းသပ်မှုများကို schema အသစ်နှင့် လည်ပတ်စေခြင်းဖြင့် အာမခံချက် စစ်ဆေးသည်။ ## မစတင်မီ 1. ထုတ်ဝေမှုမှတ်စုများ ဖတ်ပါ။ ထိန်းသိမ်းမှုပြတင်းပေါက် လိုသောထုတ်ဝေမှုက ခန့်မှန်းခြေနှင့်အတူ ထိုအကြောင်း ဆိုသည်။ ထုတ်ဝေမှုတစ်ခုလျှင် အများဆုံး တစ်ခု။ 2. ပြန်လည်ဖော်ထုတ်လေ့ကျင့်မှု လည်ပတ်ပါ၊ သို့မဟုတ် ဤထုတ်ဝေမှုအတွက် စိမ်းလျက် လည်ပတ်ခဲ့သည်ကို အတည်ပြုပါ ([backup-restore.md](/my/ops/backup-restore/))။ မအောင်သောလေ့ကျင့်မှုက အဆင့်မြှင့်မှုကို ပိတ်ဆို့သည်။ 3. အခြေအရန်တစ်ခု ယူပါ– `docker compose -f docker/compose.yaml --profile backup run --rm backup`။ ## Docker Compose၊ အိမ်ရှင်တစ်ခု ```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` သို့ လှန်သည်၊ ပျံသန်းနေသောတောင်းဆိုမှုများကို စက္ကန့် ၃၀ အတွင်း ပြီးဆုံးစေသည်၊ ပြန်ချိတ်ဆက်အရိပ်အမြွက်ဖြင့် စီးဆင်းမှုများ ပိတ်ပြီး ထွက်သည်။ `stop_grace_period` က စက္ကန့် ၄၀ ဖြစ်သောကြောင့် Compose က ကျန်းမာသောရေနုတ်မြောင်းကို ဘယ်တော့မှ မဖြတ်ပါ။ 3. **အလုပ်သမားများ နောက်**၊ ထို့ကြောင့် အသစ်ဆုံးဖြစ်ရပ်ပုံသဏ္ဌာန်က အသစ်ဆုံးစားသုံးသူ မျှော်လင့်မည့်အလား ထုတ်လုပ်သည်။ အလုပ်သမားများ တစ်ပြိုင်နက် ယူခြင်းရပ်ပြီး စက္ကန့် ၁၂၀ ရသည်။ မပြီးနိုင်သောအလုပ်ကို အခြားနေရာ၌ ထပ်ယူသည်၊ အလုပ်တိုင်း ထပ်တူညီမှုကင်းသောကြောင့် ဘေးကင်းသည်။ အချိန်ဇယားဆွဲသူက ၎င်းနောက်အမှန်ခြစ်တွင် ဦးဆောင်မှု လွှဲပေးသည်။ အိမ်ရှင်တစ်ခုတွင် Compose က ကွန်တိန်နာတစ်ခုစီကို အလှည့်ဖြင့် အစားထိုးသည်၊ ထို့ကြောင့် ဝန်ဆောင်မှုတစ်ခုလျှင် ကွာဟမှုတို ရှိသည်။ ကွာဟမှုလုံးဝမရှိရန်၊ ဝဘ်အဆင့်ကို သင့်ကိုယ်ပိုင်ပရောက်ဆီနောက် ကွန်တိန်နာနှစ်ခုအဖြစ် လည်ပတ်ပါ (ထုတ်ဝေထားသော port မပါသော ဒုတိယဝဘ်ဝန်ဆောင်မှု ထည့်သောလွှမ်းမိုးဖိုင်)၊ ၎င်းတို့ကို တစ်ကြိမ်တစ်ခုစီ ပြန်ဖန်တီးပါ၊ နောက်တစ်ခုမပြုမီ တစ်ခုစီ ကျန်းမာကြောင်း အစီရင်ခံရန် စောင့်ပါ။ ## အိမ်ရှင်များစွာ သို့မဟုတ် စီစဉ်သူ တူညီသောအစီအစဉ် အသုံးပြုပါ– အလုပ်တစ်ခုတည်းမှ တစ်ကြိမ်ရွှေ့ပြောင်းပါ၊ ထို့နောက် ဝဘ်အဆင့် လှိမ့်ပါ၊ ထို့နောက် အလုပ်သမားများ။ အသင့်ဖြစ်မှုစစ်ဆေးမှုများကို `/readyz` သို့၊ ရှင်သန်မှုကို `/healthz` သို့ ညွှန်ပါ။ သီးသန့် tenant ဒေတာဘေ့စ်များဖြင့် `migrate` အဆင့်က နှစ်ခုစလုံး လုပ်သည်– ထိန်းချုပ်ဒေတာဘေ့စ်ကို အရင်ရွှေ့ပြောင်းပြီး၊ ထို့နောက် `ops.tenant_database` တွင် စာရင်းပြုစုထားသောဒေတာဘေ့စ်တိုင်း၊ တစ်ကြိမ်တစ်ခု၊ တစ်ခုစီ ၎င်း၏ကိုယ်ပိုင်သော့အောက်၌။ tenant ဒေတာဘေ့စ်တစ်ခုရှိ မအောင်မှုက အခြားအရာများ မရပ်ပါ။ ဒေတာဘေ့စ်တိုင်း ပြီးသည့်အခါ ရွှေ့ပြောင်းမှုစာရင်းများကို နှိုင်းယှဉ်ပြီး ဒေတာဘေ့စ်တိုင်း ထိန်းချုပ်ဒေတာဘေ့စ်ရှိရွှေ့ပြောင်းမှုများအတိအကျ အသုံးချသည်မှလွဲ၍ သုညမဟုတ်ဖြင့် ထွက်သည်၊ နောက်ကျ သို့မဟုတ် ရှေ့ရောက်တစ်ခုစီကို အမည်ပေး၍။ တူညီသောအမိန့်က ဒေတာဘေ့စ်တစ်ခုစီတွင် တန်းစီဇယားများ တပ်ဆင်သည်၊ အလုပ်သမားက ချိတ်ထားသော tenant ၏အလုပ်များကို ရေးခဲ့သည့်နေရာတွင် စားသုံးသောကြောင့်။ ```sh 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` အဖြစ် မှတ်ပုံတင်ထားသောဒေတာဘေ့စ်က လိုအပ်သည်– | ကိန်းရှင် | အတွက် အသုံးပြုသည် | | --- | --- | | `QUIRE_DB_NORTHWIND_URL` | အက်ပလီကေးရှင်းအခန်းကဏ္ဍ၊ ဝဘ်အဆင့်နှင့် အလုပ်သမားအတွက် | | `QUIRE_DB_NORTHWIND_URL_MIGRATOR` | ရွှေ့ပြောင်းသူအခန်းကဏ္ဍ၊ ဤအမိန့်နှင့် ရွှေ့မှုများအတွက် | | `QUIRE_DB_NORTHWIND_URL_SUPERUSER` | ရွေးချယ်နိုင်– ရွှေ့ပြောင်းမှုမပြုမီ အခြေခံတည်ဆောက်မှု (အခန်းကဏ္ဍများ၊ schema များ၊ အကူများ) ပြန်သုံးသည် | `_MIGRATOR` ချိတ်ဆက်မှုမရှိသော မှတ်ပုံတင်ထားသောဒေတာဘေ့စ်ကို မအောင်မှုအဖြစ် အစီရင်ခံသည်၊ ဘယ်တော့မှ မကျော်ပါ။ ထိန်းချုပ်ဒေတာဘေ့စ် ပြီးသည်နှင့် ဝဘ်အဆင့် လှိမ့်နိုင်သည်။ တစ်နာရီ နောက်ကျသော tenant ဒေတာဘေ့စ်က သတိပေးသည်။ တစ်ရက်ဆိုပါက စာမျက်နှာခေါ်သည်။ ## pgvector ရွှေ့ပြောင်းမှု 0264 မှ အခြေခံစာရွက်စာတမ်းစုက ဆာဗာတွင် extension ရှိသည့်နေရာ၌ pgvector HNSW အညွှန်း အသုံးပြုသည်။ Compose `postgres` ဝန်ဆောင်မှုက ၎င်းဖြင့် တည်ဆောက်ထားသည် (`docker/postgres.Dockerfile`)။ image များ ပြောင်းပြီးနောက် ပထမ `migrate` က superuser အခြေခံတည်ဆောက်မှုမှတစ်ဆင့် extension ဖန်တီးသည်၊ 0264 က ထုတ်လုပ်သော vector ကော်လံတစ်ခု ထည့်ပြီး အညွှန်း တည်ဆောက်သည်။ ကော်လံထည့်ခြင်းက `app.ai_chunk` ကို သီးသန့်သော့အောက်၌ တစ်ကြိမ် ပြန်ရေးသည်၊ ထို့ကြောင့် အခြေခံတောင်းဆိုမှုများ ၎င်းကို စောင့်သည်။ အခြားဘာမှ ထိုဇယားကို မထိပါ။ pgvector မရှိသောဆာဗာတွင် 0264 က အသိပေးချက်တစ်ခု မှတ်တမ်းတင်ပြီး ဘာမှ မပြောင်းပါ၊ ပြန်လည်ရယူမှု အတိအကျ ဆက်ရှိနေသည်။ 0.8 ထက် ဟောင်းသော pgvector ဖြင့် ကော်လံနှင့် အညွှန်း တည်ဆောက်သော်လည်း extension အဆင့်မြှင့်သည်အထိ (`alter extension vector update`) ပြန်လည်ရယူမှု အတိအကျ ဆက်ရှိနေသည်၊ စစ်ထုတ်ထားသော HNSW စကင်များက 0.8 ၏ ထပ်ခါစကင်များ လိုသောကြောင့်။ ၎င်းမရှိသောဆာဗာတွင် နောက်ပိုင်း ဖွင့်ရန် extension တပ်ဆင်ပါ၊ အခြေခံတည်ဆောက်မှု ထပ်လည်ပတ်ပါ (သို့မဟုတ် superuser အဖြစ် `create extension vector`)၊ ထို့နောက် `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_RELEASE` ကို ယခင် tag အဖြစ် သတ်မှတ်ပြီး `up -d` ထပ်လုပ်ပါ။ ထိုအလုပ် ဖြစ်သည်မှာ ထုတ်ဝေမှုတစ်ခုအတွင်း schema က ဦးတည်ချက်နှစ်ဖက်စလုံး ကိုက်ညီသောကြောင့် ဖြစ်သည်။ **schema** ပြန်လှည့်ခြင်းကို မပေးပါ။ ပြန်ဖျက်၍မရသည့်အရာ၊ ၎င်းမှ မည်သို့ပြန်ကောင်းလာမည်နည်း– | ပြန်ဖျက်၍မရပါ | ပြန်ကောင်းလာမှု | | --- | --- | | ကော်လံတစ်ခု ဖြုတ်ချသောစာချုပ်ရွှေ့ပြောင်းမှု | ဖြုတ်ချမှုမပြုမီ အချိန်အမှတ်သို့ ဒေတာဘေ့စ်အသစ်အဖြစ် ပြန်လည်ဖော်ထုတ်ပါ၊ ထုတ်ယူပါ၊ ပေါင်းပါ | | နေရာတွင်ဒေတာပြောင်းလဲမှု | တူညီသည်၊ ထို့နောက် ကတည်းက ရေးမှုများ ပြန်ညှိပါ | | ပို့ပြီးသား webhook များနှင့် ဖြစ်ရပ်များ | လျော်ကြေးဖြစ်ရပ်များ၊ ဖျက်ခြင်းဘယ်တော့မှ မဟုတ်ပါ | | ပို့ပြီးသား အီးမေးလ် | လူက နောက်ဆက်တွဲ ရေးသည် | | စာရင်းစစ်အချက်အလက်ကွင်းဆက် | ဘယ်တော့မှ ပြန်မရေးပါ။ တည့်မတ်မှုထည့်သွင်းမှု ထပ်ထည့်ပါ | ထို့ကြောင့် စာချုပ်ရွှေ့ပြောင်းမှုက တည်းတင် ပို့ဆောင်သည်– ပြန်လည်ဖော်ထုတ်မှုတွင် သန့်ရှင်းသောနယ်နိမိတ် ရှိသည်။ ## အဆင့်မြှင့်မှု စစ်ဆေးခြင်း ```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/my/ops/upgrade/index.mdx