Dotaz: Synchronizace struktur databazí v PostgreSQL

[ZAH]

Potřebuji synchronizovat struktury databáze. Pokud možno bez negativních dopadů do dat. Jde tři databáze vývojovou, instalační a s kompletními daty.

Ve vývojové mám jen data na pokusy a hraju si s ní.Instalační by měla obsahovat pouze data nutná pro čistou instalaci databáze. Poslední obsahuje kompletní data firmy přenesená ze starého systému. Ztráta jakýchkoliv data tudíž není kritická, ale zdržuje.

Budu vděčný za nakopnutí správným směrem. ZAH

---

---

Odpovědi

[Kit]

Nejprve si definuj, co na čem závisí. Udělal bych to formou exportů a importů. Dá se tak definovat, kterou komponentu chceš kopírovat kompletně (např. číselníky) a ze které pouze strukturu.

[Josef Kufner]

To, co chceš, není synchronizace, ale migrace. Pro každou změnu struktury databáze si napíšeš skript, který požadovanou změnu provede. Ten skript spustíš na vývojové databázi, a když to funguje, tak pak později i na produkční databázi. Tím budeš mít na obojím provedeny stejné změny. Výhodou je, že taková migrace může také konvertovat data.

V opačném směru to je jednodušší, to prostě vývojovou či testovací databázi smažeš a nakopíruješ tam produkční. Obvykle je vhodné data anonymizovat, nebo ještě lépe zkopírovat jen strukturu a nagenerovat si anonymní data. Používá se ještě staging prostředí, kde se testuje na kopii produkčních dat těsně před nasazením do produkce.

Migrace můžeš používat i k inicializaci databáze, kde nultá migrace importuje nějaký postarší základ a následující migrace to posunou do aktuální podoby. V kombinaci se seedem (generátorem dat) se tento přístup hodí k nastavení lokálního vývojového prostředí.

Migrace krom změn v databázi musí udělat ještě jednu věc, každá si musí poznamenat, že se spustila a byla provedena. Migrační nástroje to typicky nějak řeší. Nejlepší je, když si to ten nástroj poznamená do extra tabulky v databázi (ta tabulka pak v podstatě obsahuje verzi databáze).

Docela rozumný je například Phinx.

[ZAH]

Souhlas9m s migrací verzí u koncového zákazníka pro vývoj mi to připadá poněkud těžkopádné. Má představu asi takto , ve vývojové databázi si hraju nakonec provedu export struktury. U druhých dvou databází provedu export dat a poté je asi smáznu provedu import nové struktury a následně import dat. Celé to nějak zautomatizovat a ošetřit alespoň základní problémy při importu dat. Opakuji, při ztráta části nebo úplná dat není tragédií, ale zdržuje.

Jinak díky na Phinx se podívám a dám zprávu. I když předpokládám, že nejlepší cestou bude zpracovat logy změn.

  V posgresql.conf zapnout
 
  log_statement = 'ddl'

  egrep -i "create|alter|drop" pg_server.log 
 

. Výsledek podhodit psql nebo něčemu podobného.

Jen bych nerad vynalézal a hlavně testoval kolo, a tak zjišťuji něco hotového.

[Josef Kufner]

Nijak těžkopádné to není. Na začátku, když si hraješ, tak ty tabulky na produkci obvykle vůbec neexistují, takže si je prostě naklikáš, poladíš a do migrace dáš create table příkazy získané exportem z té experimentální databáze (a tu pak zahodíš). Přidaná práce víceméně žádná.

Když pak děláš změny, tak už víš, co chceš a při provádění změn si průběžně odkopírováváš spouštěné příkazy. Většina klientů ti je ukáže. Tady nějaký overhead je, ale je to jen o vytvoření souboru a trochy ctrl+c, ctrl+v. Výhodou je, že když zjistíš, že jsi se někde seknul, tak můžeš prostě tu migraci upravit a nemusíš to klikat celé znovu.

Třetí scénář je, že už databázi máš a nevíš, co chceš (např. hledání té správné optimalizace). Pak si prostě chvíli hraješ, vývojovou databázi rozdrbeš, zahodíš a hraješ si znovu. Když zjistíš, co chceš, změny bývají na pár příkazů, které nakopíruješ do migrace.

Také velmi rychle narazíš na to, že některé změny chceš zachovat a jiné nikoliv. Ukecat automatický nástroj je prostě obtížné a zdržuje to. Oproti tomu při ručním kopírování SQL příkazů ty chtěné zkopíruješ a ty nechtěné ne.

Užitečné je automatizovat obnovení lokální vývojové databáze do produkčního stavu (je to jeden skript s importem dumpu). Hodí se příkaz na vytvoření prázdné migrace. A pak je nutnost mít automatizované provádění migrací (z ručního spuštění). Ideální je ještě navázat jednoduchou sadou testů, které oťukají, že nové schema dává smysl a je konzistentní s kódem.

Při běžném vývoji se mi ani nijak moc neosvědčily nástroje na porovnávání databází. Užitečnější je mít log spouštěných příkazů a případně export pro větší změny. Pak to ručně poskládat do migrace a spustit na to testy. Na první pohled se to sice zdá pracnější, ale ušetří to spoustu času právě svou jednoduchostí a hlavně předvídatelností.

Obrovskou výhodou tohoto přístupu je snadná integrovatelnost s continuous integration a verzováním. Ty migrace prostě hodíš do Gitu spolu s ostatním kódem a až se to mergne do masteru, tak se změny v databázi samy propíšou na testovací server. Jediné nutné pravidlo je, že na jednou mergnuté migrace už se nesahá.

[ZAH]

Jsem ve stavu, kdy zatím není produkční databáze. Tabulky projektu vznikly transformací 30 let staré dos databáze do současného SQL a já se snažim z nich udělat fungující projekt.

Takže si v podstatě hraju na funguje nefunguje aktuálně se dostávám do stavu funguje podmíněně a potřebuji testovat na skutečných datech nikoliv však produkčních. Tolik k vysvětlení, jinak děkuji za tvé poznámky budou se hodit určitě.

Jestli do dostanu v dohledné době do produkčního stavu tak určitě budu v této diskuzi pokračovat.

P.S. Musím si jí najít novou klávesnici tahle si už píše co chce, tím se omlouvám za počet překlepů ještě větší než je můj standart

[dustin]

Pokud si můžeš dovolit testovat na produkčních datech (samozřejmě vhodně anonymizovaných/obfuskovaných), je to z mé zkušenosti ta nejlepší databáze pro vývoj. Samozřejmě pokud její velikost nepřesahuje pár set GB, aby se v pohodě vešla na pracovní stanici nebo lokální server (což u dosové aplikace asi nehrozí).

[Josef Kufner]

V takovém případě bych ponechal staré tabulky stranou, jednou migrací vytvořil nové tabulky pomocí exportu schématu z libovolného hezkého nástroje a druhou migrací konvertoval data do nové struktury (INSERT—SELECT z těch starých tabulek ponechaných stranou). Tyto dvě migrace bych ladil a ladil, dokud bych nebyl spokojen a vedle toho bych napsal testy, které by ověřovaly funkčnost modelové vrstvy aplikace. Každé spuštění těchto migrací a testů by pak začínalo vždy s prázdnou novou databází, pokud by to tedy netrvalo půl hodiny, takže by bylo jasné, že vše funguje, jak má.

Pokud to aplikace dovolí, tak bych udělal takovýchto párů migrací víc – jeden pár pro každou oddělitelnou komponentu. To by také urychlilo opakované spouštění, neboť by se dalo vracet k nějakému snapshotu (dumpu) a nespouštět vždy vše.

Rozdělení na dvě migrace bych udělal kvůli tomu, aby se ta první se strukturou dala řešit exportem a nehrozilo, že si něco užitečného přepíšeš. Ten export struktury databáze pak můžeš celkem snadno automatizovat (pokud to za to stojí; např. dump vývojové předlohy), ale konverze dat se automatizovat moc nedá a budeš ji na konec potřebovat také – na finální přemigrování produkčních dat.

Celé se to vlastně točí kolem konceptu, že namísto přímé konverze databáze vyladíš skript, který tu konverzi provede. Výhodou je, že když pak mnohem později zjistíš, že jsi něco minul a zmigroval blbě, tak se budeš moct vrátit, migraci upravit a přemigrovat znovu. Další výhodou je, že takto zmigrovanou věc můžeš dát uživatelům k otestování a případné chyby v migraci snadno opravovat.

[Filip Jirsák]

Řekl bych, že sháníte Flyway nebo Liquibase. Ve VCS udržujete strukturu databáze popsanou nějakým skriptem. Oba nástroje si pak v databázi udržují aktuální verzi schématu a provedou postupně všechny aktualizační skripty až po nejnovější verzi schématu. Dá se to dělat i ručně (stačí číslovat skripty pro aktualizaci a někde si pamatovat aktuální verzi schématu), ale proč nepoužít už hotové nástroje…

[ZAH]

Dík jak bude chvilka vyzkouším.

[=]

To musí být člověk opravdu narcis, označit si svůj příspěvek za řešení..

[lazywriter]

Pouzivam https://github.com/perseas/Pyrseas a docela funguje.