Dotaz: postgreSQL - udržování stejného schématu tabulek na více strojích

[serda]

zdravím,

mám několik desítek strojů a v každém z nich je mimo jiné jedna databáze s asi stovkou tabulek..

Poradí mi někdo nějaký jednoduchý nástroj, který mi zařídí, že když změním nějakou tabulku (přidám sloupec, či např. změním datový typ sloupce či defaultní hodnotu), aby se mi toto nové schéma tabulky změnilo i na ostatních strojích...

tyto stroje jsou offline, takže tento nástroj bych použil v nějakém skriptu, který bych musel na každým stroji spustit

díky za nějaký tipy

Odpovědi

[Filip Jirsák]

Opravdu ty změny budete dělat tak, že si sednete ke konzoli a začnete z hlavy bušit nějaké SQL příkazy a zkoušet, co to udělá? Pokud to s tou databází myslíte aspoň trochu vážně (a když jich je čtyřicet nebo kolik), budete spíš psát skript pro změnu schématu, který budete testovat na zkušební databázi, a teprve když bude odladěný, spustíte jej na produkční databázi. A pak už jej samozřejmě můžete spustit i na těch ostatních strojích. Když si do schématu přidáte i sekvenci s aktuálním číslem schématu, můžete si ten skript připravit i tak, že si sám zjistí aktuální verzi a provede postupně všechny změny až k aktuální (nebo jiné zvolené) verzi.

[serda]

no tu databazi vytvarim v pgadminu..a nechce se mi kdyz upravim nejaky sloupec, abych to musel jeste davat do nejakyho vlastniho skriptu..pac vim, ze obcas proste neco zapomenu...

potreboval bych nejaky nastroj, ktery mi ten skript vygeneruje sam..resp. nejaky nastroj, ktery mi zaridi, abych mohl ty databaze na ostatnich strojich udrovat se stejnym schematem

ten update ostatnich stroju delam napr jednou za mesic a kolikrat je v ty databazi strasne moc zmen (novy tabulky, novy sloupce v existujicich tabulkach,....), a nekdy treba zadna zmena

 

neco jako udelat backup schematu do plain textu a pak ty create table zduplikovat a udelat z jednotlivych sloupcu alter table add column (sice by to hlasilo milion chyb, ale snad bych zaridil ze sloupce tam budou nakonec vsechny...)

[Filip Jirsák]

Zkuste se podívat, jestli neumí PostgreSQL nebo pgAdmin logovat vykonávané SQL příkazy, ze kterých byste si vyfiltroval ALTERy a CREATE. Porovnávat změny ve schématu a dělat z toho ALTERy mi připadá jako ten nejsložitější možný způsob, už jenom proto, že jednotlivé změny na sobě mohou záviset a je tedy nutné je udělat ve správném pořadí.

[happy barney]

no tu databazi vytvarim v pgadminu.

hmm, 100 tabuliek, 10 strojov a samovražedné sklony k tomu?

[selfrule]

mrkni na tohle:

http://www.postgresql.org/docs/8.4/interactive/continuous-archiving.html

 

pouziva se to pro zalohovani, vzdycky by sis ty wal soubory zazalohoval a jednou za cas pustil na ostatni databaze

 

[Filip Jirsák]

To by se ale přenášela i data, nebo se mýlím?

[selfrule]

Jo to mas pravdu, hledal jsem to v rychlosti a tohle mi nedoslo :)

[serda]

tak sem to vyresil tak trochu krkolome a asi i nebezpecne..

 

1. zazalohuju celou puvodni databazi (to jen pro jistotu, kdyby nasledujici postup selhal)

2. zazalohuju jen data stare databaze

3. smazu vsechny tabulky v databazi

4. restoruju novou databazi, resp. nove schema (puvodni schema je vzdy podmnozinou - jelikoz o tom vim, tak si to proste ohlidam :)

5. restoruju puvodni data ...ty chybejici sloupce se doplni defaultnima hodnotama

 

je to trosku hnusne vyresene, ale provede to presne to co potrebuju :)

[FooBar]

To je dost sileny. Milionkrat lepsi, inteligentnejsi, konzistentnejsi, bezpecnejsi a obvyklejsi reseni je, jak rikal jiz kolega vyse, proste si pripravit SQL skript kterej poustis na testovacim stroji a pripadne modifikujes dokud neudela to co chces, a pak ho pustis na vsech ostatnich.

[default]

a pak ho pustis na vsech ostatnich.

A já se modlím i u tohoto kroku.

[okbob]

ALTER skripty je nejlepší psát v ruce - pak víte, co obsahují. Navíc v PostgreSQL lze alter skript obalit transakcí. Tudíž, když někte v půli spadne, tak se vůbec nic neděje. Tj.

BEGIN
  ALTER TABLE foo ADD COLUMN boo integer;
COMMIT

 

[kaaja]

Není nic jednoduššího, než ještě mezi vývojové prostředí a produkční vložit jedno, které je obrazem produkčního. A předtím než něco nasadím na produkci, tak to tam testnout.

[xkucf03]

BTW: neznáš nějaký testovací nástroj na porovnání dvou databází (jen model, ne data)? Něco na způsob: udělám dump (jen schématu) obou DB, odfiltruji komentáře (obsahují např. datum, nebo jiné věci, které se mohou měnit) a porovnám je.

Prostě pro kontrolu, abych měl jistotu, že ten skript s ALTER a CREATE… příkazy dělá přesně to, co chci.

[default]

Porovnání schémat umí třeba SQL Developer (měl by jít přes JDBC driver napojit na libovolnou databázi). Ale není to nic moc. Asi vůbec "nejjednodušší" je vylejt schémata do skriptů a porovnat klasickým diffem.

[happy barney]

select from pg_tables, pg_attribute, pg_index, pg_constraint (+ par referencii), sort, diff ...

[xkucf03]

jj, to můžu udělat, ale zajímalo mě, jestli už existuje nějaké hotové řešení

[misch]

Vážně ten výpadek (tzn. to že od bodu 1 k bodu 5 má kdokoli utrum s přístupem k databázi) stojí za ušetřených pár minut při psaní alteru?

[Tomáš]

Jak již tady někdo poradil. Já jsem na Sybase ASA také používal tu metodu, že jsem si nechal vždy přeložit log databáze do SQL, v něm jsem scriptem našel všechny potřebné DDL příkazy a z toho sestavil upgrade dávku.

Druhá možnost, která existuje, je najít nějaký nástroj na porovnání dvou DB, který by uměl vyrobit příslušný rozdílový scrip. Na to jsem používal nějaký předpotopní program dbdiff.exe (pro windoze), který se pomocí ODBC rozhraní připojil ke dvěma DB a vygeneroval rozdílový SQL script.

To co jste nakonec udělal, zkombinovat data ze staré DB s DDL z nové DB, do toho bych nešel, pravděpodobně Vám to funguje čirou náhodou

[Josef Kufner]

Potřebuješ dvě věci:

1. Diffovátko, které ti řekne jestli jsou nějaké odchylky od referenčního schématu. – To jen pro kontrolu.
2. Script, který jsi vytvořil při úpravách na testovací databázi.

To první seženeš, ale ten script si prostě musíš napsat sám. Dokud nebudeme mít použitelnou AI, tak to za tebe nikdo neudělá. Jediné co ti s tím může pomoct je, když ti nějaký nástroj ty příkazy napíše, abys je nemusel psát celé ručně. Další věc je, že do toho scriptu můžeš zahrnout i změny v datech – třeba když přidáš sloupeček a potřebuješ ho naplnit daty z jiných sloupečků.

[default]

Dokud nebudeme mít použitelnou AI, tak to za tebe nikdo neudělá.

Ale, ale! Vygenerovat DDL na základě rozdílu (MINUS) user_tables, user_tab_cols, user_indexes či user_partitions zvládne snad každý, ne?

[Filip Jirsák]

Teoreticky ano. Prakticky musíte zajistit, abyste indexovaný sloupec vytvořil před indexem, odkazovaný sloupec před ukazatelem (u referenční integrity) atd. A pak jsou tady takové chuťovky, jako nekompatibilní změna typu sloupce, případně přidání nového sloupce a jeho naplnění nějakou hodnotou závislou na ostatních datech, a tu konverzní funkci ze schématu nevykoukáte ani za sto let, protože tam nikde uložena není.

[default]

Vytvoření sloupce před indexem je snad základ, ne?

Migrace dat je ovšem jiná pohádka.

[misch]

Migrace dat je v tomhle případě přesně ta stejné pohádka, ne? Když už má autor původního ten zvláštní přístup, že raději na 10 strojích provede dump+dropdb+createdb+create_schema+load_data než aby si ručně napsal 5-řádkový alter skript, tak bych se dost divil kdyby se po přidání sloupečku chtěl sám starat o migraci dat

[Josef Kufner]

Migrace dat je ovšem jiná pohádka.

A právě tahle pohádka je důvod, proč automatika nestačí

[surda]

Zkusil bych pouzit Apachi DDLUtils. Jsou relativne pomale, ale spolehlive.

http://db.apache.org/ddlutils/