---
title: "ಡೌಟೈಮ್ ಇಲ್ಲದೆ ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡುವುದು"
description: "ಡೌಟೈಮ್ ಇಲ್ಲದೆ ಸ್ವ-ಹೋಸ್ಟ್ ಮಾಡಿದ Quire ಅನ್ನು ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡಿ."
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/kn/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 ಸ್ಕೀಮಾ R ಮತ್ತು ಸ್ಕೀಮಾ R ಕಿರಿದಾದ ಒಂದರ ವಿರುದ್ಧ ಸರಿಯಾಗಿ ನಡೆಯುತ್ತದೆ.** ಪ್ರತಿ
ಸ್ಕೀಮಾ ಬದಲಾವಣೆಯನ್ನೂ ವಿಸ್ತರಣೆ, ಪರಿವರ್ತನೆ ಮತ್ತು ಒಪ್ಪಂದಕ್ಕೆ ಹಂಚಲಾಗುತ್ತದೆ:

1. **ವಿಸ್ತರಿಸಿ**: ಹೊಸ ಕಾಲಮ್, ಕೋಷ್ಟಕ ಅಥವಾ ಸೂಚಿ ಸೇರಿಸಿ. ಹಳೆಯ ಕೋಡ್ ಅದನ್ನು
   ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ.
2. **ಪರಿವರ್ತಿಸಿ**, ಕನಿಷ್ಠ ಒಂದು ಆವೃತ್ತಿಯವರೆಗೆ: ಹೊಸ ಕೋಡ್ ಎರಡೂ ರೂಪಗಳಲ್ಲಿ ಬರೆಯುತ್ತದೆ ಮತ್ತು
   ಹೊಸದನ್ನು ಓದುತ್ತದೆ; ಮರುಪ್ರಾರಂಭಿಸಬಹುದಾದ ಕೆಲಸವು ಹಳೆಯ ಸಾಲುಗಳನ್ನು ತುಂಬುತ್ತದೆ.
3. **ಒಪ್ಪಿಸಿ**: ಹಳೆಯ ರೂಪವನ್ನು ಒಂದು ನಂತರದ ಆವೃತ್ತಿಯಲ್ಲಿ, ಒಂಟಿಯಾಗಿ, ಬಿಟ್ಟುಬಿಡಿ.

ಆದ್ದರಿಂದ ರೋಲಿಂಗ್ ಅಪ್‌ಗ್ರೇಡ್‌ನ ಪ್ರತಿ ಕ್ಷಣದಲ್ಲೂ, ಹಳೆಯ ಮತ್ತು ಹೊಸ ಪ್ರಕ್ರಿಯೆಗಳು ಒಂದೇ
ಡೇಟಾಬೇಸ್ ಹಂಚಿಕೊಳ್ಳಬಹುದು. ಡೌನ್ ವಲಸೆಗಳಿಲ್ಲ: ಒಂದು ಗಂಟೆಯ ಹಿಂದೆ ಒಂದು ಕಾಲಮ್ ಬಿಟ್ಟುಬಿಟ್ಟ
ವಲಸೆಯು ಆ ಗಂಟೆಯಲ್ಲಿ ಬರೆಯಲಾದ ಸಾಲುಗಳನ್ನು ಮರಳಿಸಲಾಗದು.

`schema-compat` CI ಕೆಲಸವು ಪ್ರತಿ ಆವೃತ್ತಿಯಲ್ಲಿ ಹಿಂದಿನ ಆವೃತ್ತಿಯ ಪರೀಕ್ಷೆಗಳನ್ನು ಹೊಸ ಸ್ಕೀಮಾ
ವಿರುದ್ಧ ಚಲಾಯಿಸುವ ಮೂಲಕ ಖಾತರಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ.

## ನೀವು ಆರಂಭಿಸುವ ಮೊದಲು <!--quire:before-you-start-->

1. ಬಿಡುಗಡೆ ಟಿಪ್ಪಣಿಗಳನ್ನು ಓದಿ. ನಿರ್ವಹಣಾ ಕಾಲಾವಧಿಯ ಅಗತ್ಯವಿರುವ ಆವೃತ್ತಿಯು ಅದನ್ನು
   ಅಂದಾಜಿನೊಂದಿಗೆ ಹೇಳುತ್ತದೆ; ಪ್ರತಿ ಆವೃತ್ತಿಗೆ ಗರಿಷ್ಠ ಒಂದು.
2. ಮರುಸ್ಥಾಪನಾ ಡ್ರಿಲ್ ಚಲಾಯಿಸಿ, ಅಥವಾ ಈ ಆವೃತ್ತಿಗಾಗಿ ಅದು ಹಸಿರಾಗಿ ಓಡಿದೆ ಎಂದು
   ದೃಢೀಕರಿಸಿ ([backup-restore.md](/kn/ops/backup-restore/)). ವಿಫಲ ಡ್ರಿಲ್ ಅಪ್‌ಗ್ರೇಡ್ ಅನ್ನು
   ತಡೆಯುತ್ತದೆ.
3. ಒಂದು ಮೂಲ ಬ್ಯಾಕಪ್ ತೆಗೆದುಕೊಳ್ಳಿ:
   `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 ಸೆಕೆಂಡ್‌ಗಳೊಳಗೆ ಚಾಲನೆಯಲ್ಲಿರುವ ವಿನಂತಿಗಳನ್ನು ಮುಗಿಸುತ್ತದೆ,
   ಮರುಸಂಪರ್ಕ ಸೂಚನೆಯೊಂದಿಗೆ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಮುಚ್ಚುತ್ತದೆ, ಮತ್ತು ನಿರ್ಗಮಿಸುತ್ತದೆ.
   `stop_grace_period` 40 ಸೆಕೆಂಡ್‌ಗಳು, ಆದ್ದರಿಂದ Compose ಆರೋಗ್ಯಕರ ಡ್ರೇನ್ ಅನ್ನು ಎಂದಿಗೂ
   ಕತ್ತರಿಸುವುದಿಲ್ಲ.
3. **ಕೊನೆಗೆ ವರ್ಕರ್‌ಗಳು**, ಆಗ ಅತಿ ಹೊಸ ಕೆಲಸದ ರೂಪವನ್ನು ಅತಿ ಹೊಸ ಸ್ವೀಕರಿಸುವವನು
   ನಿರೀಕ್ಷಿಸುವ ಮೊದಲು ಉತ್ಪಾದಿಸಲಾಗುತ್ತದೆ. ವರ್ಕರ್‌ಗಳು ತಕ್ಷಣ ಪಡೆಯುವುದನ್ನು ನಿಲ್ಲಿಸಿ 120
   ಸೆಕೆಂಡ್ ಪಡೆಯುತ್ತವೆ; ಮುಗಿಸಲು ಸಾಧ್ಯವಲ್ಲದ ಕೆಲಸವನ್ನು ಬೇರೆಡೆ ಮತ್ತೆ ಪಡೆಯಲಾಗುತ್ತದೆ,
   ಇದು ಸುರಕ್ಷಿತ ಏಕೆಂದರೆ ಪ್ರತಿ ಕೆಲಸವೂ idempotent. ಶೆಡ್ಯೂಲರ್ ತನ್ನ ಮುಂದಿನ ಟಿಕ್‌ನಲ್ಲಿ
   ನಾಯಕತ್ವವನ್ನು ಹಸ್ತಾಂತರಿಸುತ್ತದೆ.

ಒಂದೇ ಹೋಸ್ಟ್‌ನಲ್ಲಿ, Compose ಪ್ರತಿ ಕಂಟೈನರ್ ಅನ್ನೂ ಒಬ್ಬರ ನಂತರ ಒಬ್ಬರಂತೆ ಬದಲಾಯಿಸುತ್ತದೆ,
ಆದ್ದರಿಂದ ಪ್ರತಿ ಸೇವೆಗೆ ಒಂದು ಸಣ್ಣ ಅಂತರ ಇರುತ್ತದೆ. ಯಾವುದೇ ಅಂತರವಿಲ್ಲದಿರಲು, ವೆಬ್ ಹಂತವನ್ನು
ನಿಮ್ಮದೇ ಪ್ರಾಕ್ಸಿ ಹಿಂದೆ ಎರಡು ಕಂಟೈನರ್‌ಗಳಾಗಿ ಚಲಾಯಿಸಿ (ಪ್ರಕಟಿಸಿದ ಪೋರ್ಟ್ ಇಲ್ಲದೆ ಎರಡನೇ
web ಸೇವೆ ಸೇರಿಸುವ ಒಂದು override ಫೈಲ್), ಮತ್ತು ಅವುಗಳನ್ನು ಒಂದೊಂದಾಗಿ ಮರುರಚಿಸಿ, ಮುಂದಿನದಕ್ಕೂ
ಮೊದಲು ಪ್ರತಿಯೊಂದೂ ಆರೋಗ್ಯವೆಂದು ವರದಿ ಮಾಡುವವರೆಗೆ ಕಾಯಿರಿ.

## ಹಲವು ಹೋಸ್ಟ್‌ಗಳು ಅಥವಾ ಒಂದು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ <!--quire:several-hosts-or-an-orchestrator-->

ಅದೇ ಕ್ರಮ ಬಳಸಿ: ಒಂದೇ ಕೆಲಸದಿಂದ ಒಮ್ಮೆ ವಲಸೆ ಮಾಡಿ, ನಂತರ surge ಒಂದು ಮತ್ತು
unavailable ಶೂನ್ಯದೊಂದಿಗೆ ವೆಬ್ ಹಂತವನ್ನು ರೋಲ್ ಮಾಡಿ, ನಂತರ ವರ್ಕರ್‌ಗಳು. ಸಿದ್ಧತಾ
ಪ್ರಯೋಗಗಳನ್ನು `/readyz` ಗೆ ಮತ್ತು ಜೀವಂತತಾ ಪ್ರಯೋಗಗಳನ್ನು `/healthz` ಗೆ ಸೂಚಿಸಿ.

ಪ್ರತ್ಯೇಕ ಟೆನಂಟ್ ಡೇಟಾಬೇಸ್‌ಗಳೊಂದಿಗೆ, `migrate` ಹಂತವು ಎರಡನ್ನೂ ಮಾಡುತ್ತದೆ: ಅದು ಮೊದಲು
ನಿಯಂತ್ರಣ ಡೇಟಾಬೇಸ್ ವಲಸೆ ಮಾಡುತ್ತದೆ, ನಂತರ `ops.tenant_database` ನಲ್ಲಿ ಪಟ್ಟಿಯಾದ ಪ್ರತಿ
ಡೇಟಾಬೇಸ್, ಒಂದೊಂದಾಗಿ, ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಲಾಕ್ ಅಡಿಯಲ್ಲಿ. ಒಂದು ಟೆನಂಟ್ ಡೇಟಾಬೇಸ್‌ನ
ವಿಫಲತೆಯು ಇತರವುಗಳನ್ನು ನಿಲ್ಲಿಸುವುದಿಲ್ಲ. ಪ್ರತಿ ಡೇಟಾಬೇಸ್ ಮುಗಿದ ನಂತರ ಅದು ವಲಸಾ ಪುಸ್ತಕಗಳನ್ನು
ಹೋಲಿಸಿ ಶೂನ್ಯಕ್ಕಿಂತ ಹೊರತಾಗಿ ನಿರ್ಗಮಿಸುತ್ತದೆ, ಪ್ರತಿ ಡೇಟಾಬೇಸೂ ನಿಯಂತ್ರಣ ಡೇಟಾಬೇಸ್ ಅನ್ವಯಿಸಿದ
ವಲಸೆಗಳನ್ನು ನಿಖರವಾಗಿ ಅನ್ವಯಿಸದಿದ್ದರೆ ಮಾತ್ರ, ಹಿಂದೆ ಅಥವಾ ಮುಂದೆ ಇರುವ ಪ್ರತಿಯೊಂದರ ಹೆಸರನ್ನೂ
ಹೆಸರಿಸುತ್ತದೆ. ಅದೇ ಆದೇಶವು ಪ್ರತಿ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಕೆಲಸ ಕ್ಯೂ ಕೋಷ್ಟಕಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ,
ಏಕೆಂದರೆ ವರ್ಕರ್ ಬಂಧಿತ ಟೆನಂಟ್‌ನ ಕೆಲಸಗಳನ್ನು ಅವು ಬರೆಯಲ್ಪಟ್ಟ ಜಾಗದಲ್ಲಿ ಸೇವಿಸುತ್ತದೆ.

```sh
bun apps/worker/src/migrate.ts   # what the Compose step runs
bun run db:migrate:all                            # the same, from a checkout
```
ಸಾಮಾನ್ಯ ಮೈಗ್ರೇಶನ್ ಮತ್ತು ಮೊದಲ-ಚಾಲನೆಯ ಸೆಟಪ್ `ops.platform_policy_version` ಗೆ Quire ಆಪರೇಟರ್‌ನ ಪ್ರಾಮಾಣಿಕ ಇಂಗ್ಲಿಷ್ ಕಾನೂನು ದಾಖಲೆಗಳನ್ನು ಸಹ ಸ್ಥಾಪಿಸುತ್ತದೆ. ಸ್ಥಾಪಕವು ಐಡೆಂಪೊಟೆಂಟ್ ಆಗಿದೆ: ಕಾಣೆಯಾದ ಇಂಗ್ಲಿಷ್ ಬಾಡಿಗಳು ಮತ್ತು ಮೈಗ್ರೇಶನ್ ಸೀಡ್ ಮಾಡಿದ ನಿಖರ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ಬಾಡಿಗಳು ಮಾತ್ರ ಬದಲಾಯಿಸಲ್ಪಡುತ್ತವೆ. ಸೀಡ್‌ಗಳನ್ನು ಆರ್ಕೈವ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಹೊಸ ಪ್ರಕಟಿತ ಆವೃತ್ತಿಯನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ; ಐತಿಹಾಸಿಕ ಸ್ವೀಕೃತಿ ಉಲ್ಲೇಖಗಳು ಮತ್ತು ಬಾಡಿಗಳು ಉಳಿಯುತ್ತವೆ. ಆಪರೇಟರ್ ನಿಜವಾಗಿಯೂ ಬರೆದ ಯಾವುದೇ ಆವೃತ್ತಿ, ಕರಡು ಸೇರಿದಂತೆ, ಸಂರಕ್ಷಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ನೀತಿಗಳ ಕನ್ಸೋಲ್ ಮೂಲಕ ನಿರ್ವಹಿಸಬೇಕು. ಈ ಕಟ್ಓವರ್‌ನಿಂದ ಟೆನೆಂಟ್ ನೀತಿ ದಾಖಲೆಗಳು, ಆವೃತ್ತಿಗಳು ಮತ್ತು ಒಪ್ಪಿಗೆ ಎಂದಿಗೂ ಬದಲಾಗುವುದಿಲ್ಲ. ಇದು ಆಪರೇಟರ್ ಪಠ್ಯದ ಪ್ರಕಟಣೆ, ಕಾನೂನು ಪ್ರಮಾಣೀಕರಣವಲ್ಲ ಅಥವಾ ಅದರ ಭರವಸೆಗಳ ಸ್ವಯಂಚಾಲಿತ ಪೂರೈಕೆಯಲ್ಲ.


ಪ್ರತಿ ಪ್ರತ್ಯೇಕ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅದು ನೋಂದಾಯಿಸಲ್ಪಟ್ಟ ಹೆಸರಿನ ಮೂಲಕ ತಲುಪಲಾಗುತ್ತದೆ.
`env:QUIRE_DB_NORTHWIND_URL` ಆಗಿ ನೋಂದಾಯಿಸಲ್ಪಟ್ಟ ಡೇಟಾಬೇಸ್‌ಗೆ ಇದರ ಅಗತ್ಯವಿದೆ:

| ಚರ | ಇದಕ್ಕೆ ಬಳಸಲಾಗುತ್ತದೆ |
| --- | --- |
| `QUIRE_DB_NORTHWIND_URL` | ಅಪ್ಲಿಕೇಶನ್ ಪಾತ್ರ, ವೆಬ್ ಹಂತ ಮತ್ತು ವರ್ಕರ್ ಗಾಗಿ |
| `QUIRE_DB_NORTHWIND_URL_MIGRATOR` | ವಲಸಾ ಪಾತ್ರ, ಈ ಆದೇಶ ಮತ್ತು ಸ್ಥಳಾಂತರಗಳಿಗಾಗಿ |
| `QUIRE_DB_NORTHWIND_URL_SUPERUSER` | ಐಚ್ಛಿಕ: ವಲಸೆ ಮಾಡುವ ಮೊದಲು ಬೂಟ್‌ಸ್ಟ್ರಾಪ್ (ಪಾತ್ರಗಳು, ಸ್ಕೀಮಾಗಳು, ಸಹಾಯಕಗಳು) ಮತ್ತೆ ಅನ್ವಯಿಸುತ್ತದೆ |

`_MIGRATOR` ಸಂಪರ್ಕ ಇಲ್ಲದ ನೋಂದಾಯಿತ ಡೇಟಾಬೇಸ್ ವಿಫಲತೆಯಾಗಿ ವರದಿಯಾಗುತ್ತದೆ, ಎಂದಿಗೂ
ಕಳೆದುಹೋಗುವುದಿಲ್ಲ. ನಿಯಂತ್ರಣ ಡೇಟಾಬೇಸ್ ಮುಗಿದ ನಂತರ ವೆಬ್ ಹಂತವು ರೋಲ್ ಆಗಬಹುದು. ಒಂದು
ಗಂಟೆ ಹಿಂದೆ ಇರುವ ಟೆನಂಟ್ ಡೇಟಾಬೇಸ್ ಎಚ್ಚರಿಕೆ ನೀಡುತ್ತದೆ; ಒಂದು ದಿನ ಹಿಂದೆ ಇದ್ದರೆ ಪೇಜ್ ಮಾಡುತ್ತದೆ.

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

ವಲಸೆ 0264 ರಿಂದ grounding ಕಾರ್ಪಸ್ ಸರ್ವರ್‌ನಲ್ಲಿ ವಿಸ್ತರಣೆ ಇದ್ದಾಗ ಒಂದು pgvector HNSW
ಸೂಚಿ ಬಳಸುತ್ತದೆ; Compose `postgres` ಸೇವೆಯನ್ನು ಅದರೊಂದಿಗೆ ನಿರ್ಮಿಸಲಾಗಿದೆ
(`docker/postgres.Dockerfile`). ಇಮೇಜ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಿದ ನಂತರದ ಮೊದಲ `migrate`
ಸೂಪರ್‌ಯೂಸರ್ ಬೂಟ್‌ಸ್ಟ್ರಾಪ್ ಮೂಲಕ ವಿಸ್ತರಣೆಯನ್ನು ರಚಿಸುತ್ತದೆ, ಮತ್ತು 0264 ನಂತರ ಒಂದು
ರಚಿಸಲಾದ ವೆಕ್ಟರ್ ಕಾಲಮ್ ಸೇರಿಸಿ ಸೂಚಿಯನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ. ಕಾಲಮ್ ಸೇರಿಸುವಿಕೆಯು
ಒಂದು ವಿಶೇಷಾಧಿಕಾರದ ಲಾಕ್ ಅಡಿಯಲ್ಲಿ `app.ai_chunk` ಅನ್ನು ಒಮ್ಮೆ ಮರುಬರೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ
grounding ವಿನಂತಿಗಳು ಅದಕ್ಕಾಗಿ ಕಾಯುತ್ತವೆ; ಬೇರೇನೂ ಆ ಕೋಷ್ಟಕವನ್ನು ಮುಟ್ಟುವುದಿಲ್ಲ.

pgvector ಇಲ್ಲದ ಸರ್ವರ್‌ನಲ್ಲಿ, 0264 ಒಂದು ಸೂಚನೆ ದಾಖಲಿಸುತ್ತದೆ ಮತ್ತು ಏನೂ ಬದಲಾಯಿಸುವುದಿಲ್ಲ,
ಮತ್ತು ಪುನರ್‌ಪಡೆಯುವಿಕೆ ನಿಖರವಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ. 0.8 ಗಿಂತ ಹಳೆಯ pgvector ನೊಂದಿಗೆ ಕಾಲಮ್
ಮತ್ತು ಸೂಚಿಯನ್ನು ನಿರ್ಮಿಸಲಾಗುತ್ತದೆ ಆದರೆ ವಿಸ್ತರಣೆಯನ್ನು ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡುವವರೆಗೂ ಪುನರ್‌ಪಡೆಯುವಿಕೆ
ನಿಖರವಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ (`alter extension vector update`), ಏಕೆಂದರೆ ಫಿಲ್ಟರ್ ಮಾಡಲಾದ
HNSW ಸ್ಕ್ಯಾನ್‌ಗಳಿಗೆ 0.8 ನ iterative scans ಬೇಕು. ನಂತರ ಅದಿಲ್ಲದ ಸರ್ವರ್‌ನಲ್ಲಿ ಅದನ್ನು
ಸಕ್ರಿಯಗೊಳಿಸಲು, ವಿಸ್ತರಣೆ ಸ್ಥಾಪಿಸಿ, ಬೂಟ್‌ಸ್ಟ್ರಾಪ್ ಮತ್ತೆ ಚಲಾಯಿಸಿ (ಅಥವಾ ಸೂಪರ್‌ಯೂಸರ್ ಆಗಿ
`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();
```

ಇದು idempotent ಆಗಿದೆ ಮತ್ತು `enabled` ಅಥವಾ `unavailable` ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಇದನ್ನು ಪ್ರತಿ
ಪ್ರತ್ಯೇಕ ಟೆನಂಟ್ ಡೇಟಾಬೇಸ್‌ನಲ್ಲೂ ಚಲಾಯಿಸಿ.

## ಹಿಂತಿರುಗಿಸುವುದು <!--quire:rolling-back-->

**ಕೋಡ್** ಹಿಂತಿರುಗಿಸುವುದು ಯಾವಾಗಲೂ ಲಭ್ಯವಿದೆ: `QUIRE_RELEASE` ಅನ್ನು ಹಿಂದಿನ ಟ್ಯಾಗ್‌ಗೆ
ಹೊಂದಿಸಿ ಮತ್ತೆ `up -d`. ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಏಕೆಂದರೆ ಒಂದೇ ಆವೃತ್ತಿಯೊಳಗೆ ಸ್ಕೀಮಾವು ಎರಡೂ
ದಿಕ್ಕುಗಳಲ್ಲಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ.

**ಸ್ಕೀಮಾ** ಹಿಂತಿರುಗಿಸುವುದನ್ನು ನೀಡಲಾಗುವುದಿಲ್ಲ. ಏನು ರದ್ದುಗೊಳಿಸಲಾಗದು, ಮತ್ತು ಅದರಿಂದ
ಹೇಗೆ ಚೇತರಿಸಿಕೊಳ್ಳಬೇಕು:

| ರದ್ದುಗೊಳಿಸಲಾಗದು | ಚೇತರಿಕೆ |
| --- | --- |
| ಒಂದು ಕಾಲಮ್ ಬಿಟ್ಟುಬಿಟ್ಟ ಒಂದು ಒಪ್ಪಂದ ವಲಸೆ | ಬಿಟ್ಟುಬಿಡುವಿಕೆಯ ಮೊದಲಿಗೆ ಹೊಸ ಡೇಟಾಬೇಸ್‌ಗೆ ಸಮಯದ ಮೊದಲು ಮರುಸ್ಥಾಪನೆ, ಹೊರತೆಗೆಯಿರಿ, ವಿಲೀನಗೊಳಿಸಿ |
| ಸ್ಥಳದಲ್ಲಿನ ಡೇಟಾ ಬದಲಾವಣೆ | ಅದೇ, ನಂತರ ನಂತರಿನ ಬರೆಯುವಿಕೆಗಳನ್ನು ಹೊಂದಿಸಿ |
| ಕಳುಹಿಸಲಾದ webhooks ಮತ್ತು ಈವೆಂಟ್‌ಗಳು | ಪರಿಹಾರ ಈವೆಂಟ್‌ಗಳು, ಎಂದಿಗೂ ಅಳಿಸುವಿಕೆ ಅಲ್ಲ |
| ಕಳುಹಿಸಲಾದ ಇಮೇಲ್ | ಒಬ್ಬ ಮಾನವರು ಅನುಸರಣೆ ಬರೆಯುತ್ತಾರೆ |
| ಆಡಿಟ್ ಹ್ಯಾಶ್ ಸರಪಳಿ | ಎಂದಿಗೂ ಮರುಬರೆಯಲ್ಪಡುವುದಿಲ್ಲ; ಒಂದು ತಿದ್ದುಪಡಿ ನಮೂದು ಸೇರಿಸಿ |

ಆದ್ದರಿಂದ ಒಪ್ಪಂದ ವಲಸೆಯು ಒಂಟಿಯಾಗಿ ಬರುತ್ತದೆ: ಆಗ ಮರುಸ್ಥಾಪನೆಗೆ ಒಂದು ಸ್ವಚ್ಛ ಗಡಿ ಇರುತ್ತದೆ.

## ಅಪ್‌ಗ್ರೇಡ್ ಪರಿಶೀಲಿಸುವುದು <!--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/kn/ops/upgrade/index.mdx