Migrace databáze (Database migration)

Příklady z praxe

1. 01

   Nový povinný sloupec v tabulce uživatelů

   E-shop přidává souhlas se zasíláním marketingu ke všem účtům. Migrace nejdřív přidá nový sloupec, doplní hodnotu pro stávající uživatele a teprve potom nastaví omezení NOT NULL. Aplikace po nasazení může číst jednotné hodnoty místo směsi NULL a boolean.

   BEGIN;
   ALTER TABLE users ADD COLUMN marketing_consent boolean;
   UPDATE users SET marketing_consent = false WHERE marketing_consent IS NULL;
   ALTER TABLE users ALTER COLUMN marketing_consent SET DEFAULT false;
   ALTER TABLE users ALTER COLUMN marketing_consent SET NOT NULL;
   COMMIT;

2. 02

   Kontrola po přesunu objednávek

   Firma převádí objednávky ze staré tabulky do nové struktury s oddělenými položkami. Po dávkovém přesunu tým porovná počty záznamů a hledá objednávky, které v cíli chybí. Produkční přepnutí proběhne až po opravě rozdílů a kontrole několika reálných objednávek.

   SELECT COUNT(*) AS old_count FROM legacy_orders;
   SELECT COUNT(*) AS new_count FROM orders;
   SELECT order_id FROM legacy_orders
   EXCEPT
   SELECT external_id FROM orders;

Časté omyly

MýtusMigrace databáze je jen ALTER TABLE, který se spustí při nasazení.

Ve skutečnostiMigrace databáze může obsahovat ALTER TABLE, ale tím práce nekončí. Bez testu, zálohy, kontroly dat a plánu nasazení může jednoduchý příkaz způsobit výpadek nebo nekonzistenci.

MýtusKdyž máme zálohu, nemusíme řešit rollback migrace.

Ve skutečnostiZáloha je důležitá pojistka, ale obnova celé databáze může znamenat ztrátu nových dat a dlouhý výpadek. Rollback nebo kompenzační migrace řeší menší problém rychleji, pokud je připravená předem.

Časté dotazy

Má migrace databáze vždy obsahovat rollback?

Migrace databáze by měla mít plán návratu, ale rollback skript není vždy dostatečný. Změny schématu se často vracejí snáz než změny dat, protože přepsané nebo smazané hodnoty nemusí být bez zálohy obnovitelné. U rizikových migrací je bezpečnější kombinovat rollback, zálohu, auditní tabulku a možnost zastavit nasazení před bodem, kde by návrat byl nákladný.

Jak se migrace databáze testuje před produkcí?

Migrace databáze se testuje na prostředí, které se co nejvíc podobá produkci strukturou, verzí databáze a objemem dat. Důležité je ověřit nejen syntaxi skriptu, ale také dobu běhu, zámky, dopad na běžné dotazy a výsledek po opakovaném spuštění, pokud má být skript idempotentní. Samostatný test s prázdnou databází často nestačí.

Proč se migrace databáze spouští ze skriptů místo ručních úprav?

Migrace databáze se nemá dělat ručně v administraci, protože ruční změna se špatně opakuje, recenzuje a dohledává. Verzovaný migrační skript ukazuje, kdo změnu vytvořil, proč vznikla a v jakém pořadí má běžet. Stejný skript lze spustit ve vývoji, testu i produkci, což výrazně snižuje rozdíly mezi prostředími.

Co dělat, když migrace databáze trvá příliš dlouho?

Migrace databáze, která trvá příliš dlouho, se obvykle rozdělí na menší kroky. Častý postup je přidat nové pole bez blokujícího omezení, doplňovat data po dávkách a teprve po kontrole přidat finální constraint nebo přepnout aplikaci. U velkých tabulek je potřeba sledovat zámky, replikaci, růst logů a dopad na běžné uživatele.

Zdroje

1. PostgreSQL Documentation(otevře se v novém okně)PostgreSQL Global Development Group
2. ALTER TABLE(otevře se v novém okně)SQLite Consortium
3. Migrations Overview(otevře se v novém okně)Microsoft
4. Database Migration Service documentation(otevře se v novém okně)Google Cloud

Související pojmy

• Zero downtime deploymentZero downtime deployment je způsob nasazení nové verze aplikace tak, aby uživatelé během změny neviděli výpadek služby. Opírá se o postupné přepínání provozu, kompatibilní databázové migrace, health checky a možnost rychlého návratu, protože stará a nová verze často krátce běží současně.
• RollbackRollback je návrat systému do posledního známého konzistentního stavu poté, co změna selhala nebo způsobila problém. V databázi ruší všechny zápisy rozpracované transakce, v nasazení vrací aplikaci na předchozí verzi. Cílem je odstranit následky neúspěšné operace bez ručního dohledávání toho, co se stihlo změnit.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• Adaptive IconAdaptivní ikona je formát ikony aplikace na Androidu, který se místo jedné hotové bitmapy skládá z oddělených vrstev: pozadí a popředí. Systém výsledný tvar sám ořízne podle masky výrobce zařízení a může vrstvy animovat nebo přebarvit. Vývojář tak dodá jeden zdroj a launcher z něj vytvoří kruh, čtverec i squircle.
• Adresa v pamětiAdresa v paměti je číslo, kterým procesor jednoznačně označuje konkrétní buňku operační paměti, obvykle jeden bajt. Program pomocí adresy říká, odkud má data načíst nebo kam je zapsat. Adresy tvoří souvislý číselný rozsah, jehož velikost určuje šířka adresní sběrnice a architektura, typicky 32 nebo 64 bitů.
• AI agentAI agent je softwarový systém, který pomocí modelu umělé inteligence vnímá zadaný kontext, plánuje další kroky a samostatně volá nástroje nebo služby k dosažení cíle. Na rozdíl od jednorázového promptu udržuje stav úlohy, vyhodnocuje výsledky akcí a může opakovat postup, dokud nesplní zadání nebo nenarazí na limit.
• AndroidAndroid je operační systém postavený nad linuxovým jádrem, který vyvíjí Google a otevřeně uvolňuje jako projekt AOSP. Android pohání převážnou většinu chytrých telefonů, dále tablety, televize, hodinky i palubní systémy aut. Aplikace se pro něj píší hlavně v Kotlinu nebo Javě a distribuují přes Google Play i alternativní obchody.
• APIAPI je smluvené rozhraní, přes které spolu dva programy komunikují, aniž by jeden musel znát vnitřní fungování druhého. Definuje, jaké operace lze volat, jaká data se posílají a co se vrátí zpět.