Zero-downtime migrations — online DDL pattern PostgreSQL-en
A 4 órás karbantartási ablak a 2010-es évek öröksége. Mutatjuk, hogyan futtatunk nagy sémaváltozást 0 másodperc downtime alatt.
A "karbantartási ablak" az a pont, ahol az ügyfél először gondolkodik el, hogy van-e jobb szolgáltató.
A Nortinia egyetlen terméke sem állt le egyszer sem sémaváltozás miatt. Ez nem szerencse — ez egy pattern, amit minden Nortinia csapat tud kívülről. Az alábbi recept minden nagy sémaváltozásra alkalmazható, 1 GB-tól 500 GB-ig.
1. Soha "ALTER TABLE ... DROP COLUMN" egy lépésben
A klasszikus migration: ALTER TABLE users DROP COLUMN legacy_field. Ez a production-ön 2 percig tart egy 50 GB táblán, és minden azt követő query várakozik. Az ajánlott 4 lépés: (1) átnevezzük a kódot, hogy ne olvasson a mezőből, (2) deployolunk, (3) a következő release-ben DROP COLUMN IF EXISTS — most már senki nem használja, (4) ha mégis valami hibás, könnyen visszaállítható.
2. CREATE INDEX CONCURRENTLY
A sima CREATE INDEX blokkoló — a tábla írásai várnak, amíg az index kész. A CREATE INDEX CONCURRENTLY nem blokkoló, viszont 2-3x tovább tart. Mindig a CONCURRENTLY változatot használjuk. Trade-off: ha a CONCURRENTLY kézés alatt megszakad (pl. deploy rollback), az index "invalid" állapotba kerül, és manuálisan kell DROP és újraindítani.
3. Új oszlopok — NOT NULL csapda
- ALTER TABLE users ADD COLUMN age INT NOT NULL DEFAULT 0 — PG 11 előtt 100 GB táblán 20+ perces leállás
- PG 11+: ADD COLUMN ... DEFAULT nem írja újra a táblát, csak metadata
- De: NOT NULL + CHECK constraint most is tábla rewrite — kerülendő
- A helyes sorrend: ADD COLUMN (nullable) → backfill background job → ALTER COLUMN SET NOT NULL
- A backfill: UPDATE ... WHERE id IN (SELECT id FROM users WHERE age IS NULL LIMIT 1000), Loop
4. Rename — soha közvetlenül
A RENAME COLUMN egyetlen PG statement-ben, de minden deployolt kód azonnal hibát dob, amelyik a régi nevet használja. A helyes pattern: (1) új oszlop létrehozása, (2) trigger, ami mindkét oszlopot szinkronban tartja, (3) backfill, (4) kód migráció, (5) régi oszlop eltávolítása. 4 deploy, összesen 2 hét, zéró downtime. Az 5 perces "quick rename" ötvenszer rosszabb, mint ez a 2 hét.
Ezt a négy patternt a Nortinia minden backend mérnöke tudja. Minden migration PR-ben az első kérdés: "ez online DDL?". Ha nem, a PR nem merge-elhető. Ez kellemetlen, de ez az egyetlen módja annak, hogy 38 szerveren 0 leállást tartsunk fenn.