ഡൗൺടൈം ഇല്ലാതെ അപ്ഗ്രേഡ് ചെയ്യൽ

നിയമങ്ങൾ docs/architecture/23-ops.md-ലെ 7-ാം വിഭാഗത്തിലും docs/architecture/07-data.md-ലെ 4.1 വിഭാഗത്തിലുമാണ്. ഇതാണ് നടപടിക്രമം.

ഇത് സുരക്ഷിതമാക്കുന്ന ഉറപ്പ

റിലീസ് R സ്കീമ R-ലും സ്കീമ R കുറച്ച ഒന്നിലും ശരിയായി പ്രവർത്തിക്കും. ഓരോ സ്കീമ മാറ്റവും വികസിപ്പിക്കൽ, ഇടപാട്, ചുരുക്കൽ എന്നിങ്ങനെ ഭാഗിക്കപ്പെടും:

1. വികസിപ്പിക്കൂ: പുതിയ കോളം, ടേബിൾ അല്ലെങ്കിൽ ഇൻഡെക്സ് ചേർക്കൂ. പഴയ കോഡ് അത് അവഗണിക്കും.
2. ഇടപാട്, കുറഞ്ഞത് ഒരു റിലീസ് വരെ: പുതിയ കോഡ് രണ്ട് രൂപങ്ങളിലും എഴുതുകയും പുതിയത് വായിക്കുകയും ചെയ്യും; പുനരാരംഭിക്കാവുന്ന ഒരു ജോലി പഴയ വരികൾ നിറയ്ക്കും.
3. ചുരുക്കൂ: പിന്നീടുള്ള ഒരു റിലീസിൽ, ഒറ്റയ്ക്ക്, പഴയ രൂപം ഉപേക്ഷിക്കൂ.

അതിനാൽ ഒരു റോളിംഗ് അപ്ഗ്രേഡിന്റെ ഓരോ നിമിഷത്തിലും പഴയതും പുതിയതുമായ പ്രോസസ്സുകൾക്ക് ഒരു ഡാറ്റാബേസ് പങ്കിടാം. ഡൗൺ മൈഗ്രേഷനുകൾ ഇല്ല: ഒരു മണിക്കൂർ മുമ്പ് ഒരു കോളം ഉപേക്ഷിച്ച ഒരു മൈഗ്രേഷന് ആ മണിക്കൂറിൽ എഴുതിയ വരികൾ തിരികെ നൽകാൻ കഴിയില്ല.

ഓരോ റിലീസിലും പുതിയ സ്കീമിനെതിരായി മുൻപത്തെ റിലീസിന്റെ ടെസ്റ്റുകൾ പ്രവർത്തിപ്പിച്ച് schema-compat CI ജോലി ഈ ഉറപ്പ് പരിശോധിക്കും.

ആരംഭിക്കും മുമ്പ്

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-ൽ ഓരോ വെബ് പ്രോസസ്സും /readyz draining-ലേക്ക് മാറ്റും, 30 സെക്കൻഡിനുള്ളിൽ നടക്കുന്ന അഭ്യർത്ഥനകൾ പൂർത്തിയാക്കും, വീണ്ടും ബന്ധിപ്പിക്കാനുള്ള സൂചനയോടെ സ്ട്രീമുകൾ അടയ്ക്കും, പുറത്തുപോകും. stop_grace_period 40 സെക്കൻഡാണ്, അതിനാൽ Compose ആരോഗ്യമുള്ള ഒരു ഡ്രെയിനും ഒരിക്കലും മുറിക്കില്ല.
3. അവസാനം വർക്കറുകൾ, അങ്ങനെ ഏറ്റവും പുതിയ ഉപഭോക്താവ് പ്രതീക്ഷിക്കും മുമ്പ് ഏറ്റവും പുതിയ ഇവന്റ് രൂപം നിർമ്മിക്കപ്പെടും. വർക്കറുകൾ ഉടൻ എടുക്കൽ നിർത്തുകയും 120 സെക്കൻഡ് ലഭിക്കുകയും ചെയ്യും; പൂർത്തിയാക്കാൻ കഴിയാത്ത ഒരു ജോലി വേറെയിടത്ത് വീണ്ടും എടുക്കപ്പെടും, ഓരോ ജോലിയും ഇഡംപോട്ടന്റ് ആയതിനാൽ അത് സുരക്ഷിതമാണ്. ഷെഡ്യൂളർ അടുത്ത ടിക്കിൽ നേതൃത്വം കൈമാറും.

ഒരു ഹോസ്റ്റിൽ, ഓരോ കണ്ടെയ്നറും മാറിമാറി പകരം വയ്ക്കുന്നതിനാൽ, ഓരോ സേവനത്തിനും ഒരു ചെറിയ ഇടവേളയുണ്ടാകും. ഇടവേള തന്നെ വേണ്ടെങ്കിൽ, വെബ് ടയർ നിങ്ങളുടെ സ്വന്തം പ്രോക്സിക്ക് പിന്നിൽ രണ്ട് കണ്ടെയ്നറായി പ്രവർത്തിപ്പിക്കൂ (പ്രസിദ്ധീകരിച്ച പോർട്ടില്ലാതെ രണ്ടാമത്തെ web സേവനം ചേർക്കുന്ന ഒരു ഓവർറൈഡ് ഫയൽ), ഓരോന്നിന്റെയും ആരോഗ്യം റിപ്പോർട്ട് ചെയ്യും വരെ കാത്തിരുന്ന് ഒന്നിന് ശേഷം ഒന്നായി അവയെ വീണ്ടും നിർമ്മിക്കൂ.

ചില ഹോസ്റ്റുകൾ അല്ലെങ്കിൽ ഒരു ഓർക്കസ്ട്രേറ്റർ

ഒരേ ക്രമം ഉപയോഗിക്കൂ: ഒറ്റ ജോലിയിൽ നിന്ന് ഒരിക്കൽ മൈഗ്രേറ്റ് ചെയ്യൂ, പിന്നെ surge ഒന്നും unavailable പൂജ്യവുമായി വെബ് ടയർ റോൾ ചെയ്യൂ, പിന്നെ വർക്കറുകൾ. readiness probes /readyz-ലേക്കും liveness /healthz-ലേക്കും ചൂണ്ടൂ.

ഡെഡിക്കേറ്റഡ് ടെനന്റ് ഡാറ്റാബേസുകളുള്ളപ്പോൾ, migrate ഘട്ടം രണ്ടും ചെയ്യും: ആദ്യം കണ്ട്രോൾ ഡാറ്റാബേസ് മൈഗ്രേറ്റ് ചെയ്യും, പിന്നെ ops.tenant_database-ൽ പട്ടികപ്പെടുത്തിയ ഓരോ ഡാറ്റാബേസും, ഓരോന്നും സ്വന്തം ലോക്കിന് കീഴിൽ, ഒന്നിന് ശേഷം ഒന്നായി. ഒരു ടെനന്റ് ഡാറ്റാബേസിലെ പരാജയം മറ്റുള്ളവ നിർത്തില്ല. ഓരോ ഡാറ്റാബേസും കഴിഞ്ഞാൽ മൈഗ്രേഷൻ ലെഡ്ജറുകൾ താരതമ്യം ചെയ്ത്, ഓരോ ഡാറ്റാബേസും കണ്ട്രോൾ ഡാറ്റാബേസ് നടപ്പാക്കിയ മൈഗ്രേഷനുകൾ കൃത്യമായി നടപ്പാക്കിയിട്ടില്ലെങ്കിൽ പൂജ്യത്തിന് പുറത്തുപോകും, പിന്നിലോ മുന്നിലോ ഉള്ള ഓരോന്നിന്റെയും പേര് പറഞ്ഞ്. ഓരോ ഡാറ്റാബേസിലും ക്യൂ ടേബിളുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നത് അതേ കമാന്റാണ്, കാരണം വർക്കർ പിൻതിരിച്ച ടെനന്റിന്റെ ജോലികൾ അവ എഴുതിയ ഇടത്ത് തന്നെ ഉപഭോഗിക്കും.

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 എന്ന് രജിസ്റ്റർ ചെയ്ത ഒരു ഡാറ്റാബേസിന് ആവശ്യം:

_MIGRATOR കണക്ഷനില്ലാത്ത ഒരു രജിസ്റ്റർ ചെയ്ത ഡാറ്റാബേസ് ഒരിക്കലും ഒഴിവാക്കാതെ പരാജയമായി റിപ്പോർട്ട് ചെയ്യപ്പെടും. കണ്ട്രോൾ ഡാറ്റാബേസ് കഴിഞ്ഞാൽ വെബ് ടയർ റോൾ ചെയ്യാം. ഒരു മണിക്കൂർ പിന്നിലാണെങ്കിൽ ഒരു ടെനന്റ് ഡാറ്റാബേസ് മുന്നറിയിപ്പ് നൽകും; ഒരു ദിവസം പിന്നിലാണെങ്കിൽ അലേർട്ട് അയയ്ക്കും.

pgvector

സെർവറിൽ എക്സ്റ്റൻഷൻ ഉള്ളിടത്തോളം 0264 മൈഗ്രേഷനിൽ നിന്ന് ഗ്രൗണ്ടിംഗ് കോർപ്പസ് ഒരു pgvector HNSW ഇൻഡെക്സ് ഉപയോഗിക്കും; Compose-ന്റെ postgres സേവനം അതോടെയാണ് ബിൽഡ് ചെയ്യുന്നത് (docker/postgres.Dockerfile). ഇമേജുകൾ മാറ്റിയതിന് ശേഷമുള്ള ആദ്യത്തെ migrate സൂപ്പർയൂസർ ബൂട്ട്സ്ട്രാപ്പ് വഴി എക്സ്റ്റൻഷൻ നിർമ്മിക്കും, പിന്നെ 0264 ഒരു ജനറേറ്റഡ് വെക്ടർ കോളം ചേർത്ത് ഇൻഡെക്സ് നിർമ്മിക്കും. കോളം ചേർക്കുന്നത് ഒരു എക്സ്ക്ലൂസീവ് ലോക്കിന് കീഴിൽ app.ai_chunk ഒരിക്കൽ വീണ്ടും എഴുതും, അതിനാൽ ഗ്രൗണ്ടിംഗ് അഭ്യർത്ഥനകൾ അതിനായി കാത്തിരിക്കും; മറ്റൊന്നും ആ ടേബിളിനെ തൊടില്ല.

pgvector ഇല്ലാത്ത ഒരു സെർവറിൽ, 0264 ഒരു അറിയിപ്പ് ലോഗ് ചെയ്യുകയും ഒന്നും മാറ്റാതിരിക്കുകയും ചെയ്യും, റിട്രീവൽ കൃത്യമായി തുടരും. 0.8-ൽ പഴയ pgvector ഉള്ളപ്പോൾ കോളവും ഇൻഡെക്സും നിർമ്മിക്കപ്പെടും, പക്ഷേ എക്സ്റ്റൻഷൻ അപ്ഗ്രേഡ് ചെയ്യും വരെ (alter extension vector update) റിട്രീവൽ കൃത്യമായി തുടരും, കാരണം ഫിൽട്ടർ ചെയ്ത HNSW സ്കാനുകൾക്ക് 0.8-ന്റെ ഇറ്ററേറ്റീവ് സ്കാനുകൾ ആവശ്യമാണ്. പിന്നീട് അതില്ലാത്ത ഒരു സെർവറിൽ അത് പ്രാപ്തമാക്കാൻ, എക്സ്റ്റൻഷൻ ഇൻസ്റ്റാൾ ചെയ്ത്, ബൂട്ട്സ്ട്രാപ്പ് വീണ്ടും പ്രവർത്തിപ്പിക്കൂ (അല്ലെങ്കിൽ സൂപ്പർയൂസറായി create extension vector), പിന്നെ 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