ಡೌಟೈಮ್ ಇಲ್ಲದೆ ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡುವುದು

ನಿಯಮಗಳು 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 ಸೆಕೆಂಡ್ ಪಡೆಯುತ್ತವೆ; ಮುಗಿಸಲು ಸಾಧ್ಯವಲ್ಲದ ಕೆಲಸವನ್ನು ಬೇರೆಡೆ ಮತ್ತೆ ಪಡೆಯಲಾಗುತ್ತದೆ, ಇದು ಸುರಕ್ಷಿತ ಏಕೆಂದರೆ ಪ್ರತಿ ಕೆಲಸವೂ idempotent. ಶೆಡ್ಯೂಲರ್ ತನ್ನ ಮುಂದಿನ ಟಿಕ್‌ನಲ್ಲಿ ನಾಯಕತ್ವವನ್ನು ಹಸ್ತಾಂತರಿಸುತ್ತದೆ.

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

ಹಲವು ಹೋಸ್ಟ್‌ಗಳು ಅಥವಾ ಒಂದು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್

ಅದೇ ಕ್ರಮ ಬಳಸಿ: ಒಂದೇ ಕೆಲಸದಿಂದ ಒಮ್ಮೆ ವಲಸೆ ಮಾಡಿ, ನಂತರ surge ಒಂದು ಮತ್ತು unavailable ಶೂನ್ಯದೊಂದಿಗೆ ವೆಬ್ ಹಂತವನ್ನು ರೋಲ್ ಮಾಡಿ, ನಂತರ ವರ್ಕರ್‌ಗಳು. ಸಿದ್ಧತಾ ಪ್ರಯೋಗಗಳನ್ನು /readyz ಗೆ ಮತ್ತು ಜೀವಂತತಾ ಪ್ರಯೋಗಗಳನ್ನು /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 ರಿಂದ 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 ಆಗಿ:

set maintenance_work_mem = '1GB';  -- the HNSW build is much faster in memory
select ops.ai_chunk_enable_vector_index();

ಇದು idempotent ಆಗಿದೆ ಮತ್ತು 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