MariaDB - synchronizace DB schématu test/prod

[vesterna12]

Synchronizaci db schématu z testu do produkce provádím pomocí skriptu, který provádí všechny změny a zajišťuje, že schéma je ve verzi, která je v produkci očekávána. Skript obsahuje všechny příkazy pro aktualizaci schématu.
Někdy hrábnu do schématu pomocí phpMyAdmin a zapomenu změnu provést do skriptu pro aktualizaci schématu.
Existuje nějaké řešení jak exportovat pouze schéma, importovat ho do jiné databáze a zachovat existující data?

[Reklama]

[Google CTCCTCGGCGGGCACGTAG]

Existuje nějaké řešení jak exportovat pouze schéma, importovat ho do jiné databáze a zachovat existující data?

doporucil bych ORM s migracnim systemem, i v pripade, ze ho pouzijete jen pro migrace.

1. Vygenerovat ORM modely z ciloveho schematu (db, kterou chcete zmenit).
2. Vytvorit nad nimi (pocatecni) migraci a tu ulozit do db jako aplikovanou (v djangu volba --fake-initial).
3. Pregenerovat modely podle zdrojoveho schematu.
4. Vytvorit druhou migraci, ktera bude obsahovat rozdil oproti tomu prvnimu schematu.
5. Aplikovat tu migraci nad cilovym schematem.

ORM vas upozorni na vsechny pripadne problemy (chybejici defaultni hodnoty, odstraneni sloupcu s daty atd.)

[hurvajs spejbl]

Někdy hrábnu do schématu pomocí phpMyAdmin a zapomenu změnu provést do skriptu pro aktualizaci schématu.

Hodně v minulosti jsem to dělal také tak, ale pak se mi to vymstilo. Dnes na cokoliv jedině migrace. V migracích není potíž nejprve data upravit / zpracovat / odlet jinam, udělat vlastní změnu DB a zase data vrátit.

Jiný způsob než migrace je podle mne jen cesta do pekel a jednoho dne pohoříte.

[Death Walker]

Synchronizaci db schématu z testu do produkce provádím pomocí skriptu, který provádí všechny změny a zajišťuje, že schéma je ve verzi, která je v produkci očekávána. Skript obsahuje všechny příkazy pro aktualizaci schématu.
Někdy hrábnu do schématu pomocí phpMyAdmin a zapomenu změnu provést do skriptu pro aktualizaci schématu.
Existuje nějaké řešení jak exportovat pouze schéma, importovat ho do jiné databáze a zachovat existující data?

Ako bolo pisane vyssie tak migracie, napr pomocou https://sqitch.org/ Zmeny zanesene v migraciach, mozete totiz aplikovat na tolko kopii db kolko chcete, vysledok bude ten ze vsade budete mat rovnaku strukturu. Data vam v konkretnych db ostanu povodne, ak ich pomocou migracie nezmenite (ak hej, tak budu vo vsetkych kopiach db menene rovnakym sposobom)

[Death Walker]

Synchronizaci db schématu z testu do produkce provádím pomocí skriptu, který provádí všechny změny a zajišťuje, že schéma je ve verzi, která je v produkci očekávána. Skript obsahuje všechny příkazy pro aktualizaci schématu.
Někdy hrábnu do schématu pomocí phpMyAdmin a zapomenu změnu provést do skriptu pro aktualizaci schématu.
Existuje nějaké řešení jak exportovat pouze schéma, importovat ho do jiné databáze a zachovat existující data?

A k tomu ako sa vyhnut problemu ze modifikujete schemu cez pma: zakazat uzivatelovi pod ktorym mate pma vsetky DDL... To vas donuti vzdy k tomu aby ste to zapisal do migracie a nemusel po tyzdni hladat kde je problem. Po case uz budete pisat vetko primarne do migracii.

[Reklama]

[BoneFlute]

A k tomu ako sa vyhnut problemu ze modifikujete schemu cez pma: zakazat uzivatelovi pod ktorym mate pma vsetky DDL...

Používám prográmek, který spočítá checksum schematu, a pokud nesedí, tak odmítne aktualizovat. Příkazem diff mi ukáže co se změnilo a mohu uvést do původního stavu. Tím je zajištěno, že nebudu ničit databázi. Kontrolu provádí externí nástroj, takže nemusím nijak přizpůsobovat schema tomu verzování.

[Death Walker]

A k tomu ako sa vyhnut problemu ze modifikujete schemu cez pma: zakazat uzivatelovi pod ktorym mate pma vsetky DDL...

Používám prográmek, který spočítá checksum schematu, a pokud nesedí, tak odmítne aktualizovat. Příkazem diff mi ukáže co se změnilo a mohu uvést do původního stavu. Tím je zajištěno, že nebudu ničit databázi. Kontrolu provádí externí nástroj, takže nemusím nijak přizpůsobovat schema tomu verzování.

Pre take to domace bastlenie to staci. Aj v mensom teame je to vsak peklo. Ak sa budete chciet vyhnut koliziam s kolegami, tak sa udifujete k smrti. A ak budete chciet nasadit nejaku formu CI, tak sa bez tych migracii nezaobidete, budete ich musiet napisat dodatocne. Dalsia vyhoda je modularizacia. Kazdy modul moze mat vlastnu sadu migracii, nasadia sa len tie z pouzitych modulov. Naviac vyspelejsie databazy ako mysql uzatvaraju do transakcie aj DDL, nie len DML. Cize ak uzavriete migraciu do transakcie, tak pri chybe v migracii dojde na rollback a db mate v povodnom stave. Nemusite potom bud obnovovat db zo zalohy, alebo este horsie nemusite riesit rozbitu produkcnu db.

To ci prejdu niektore dotazy (namatkou alter stplca, vytvorenie cudzieho kluca a podobne) vam nezaruci ze budete mat rovnaku strukturu, dost to zavisi aj na tom ake data su v tej db ulozene. Cize pri rovnakej strukture na teste aj na produkcii, vam script moze zbehnut bez problemov na test db, ale pri produkcnej vam to moze rachnut kdekolvek v tom scripte a mate veselo.

[BoneFlute]

A k tomu ako sa vyhnut problemu ze modifikujete schemu cez pma: zakazat uzivatelovi pod ktorym mate pma vsetky DDL...

Používám prográmek, který spočítá checksum schematu, a pokud nesedí, tak odmítne aktualizovat. Příkazem diff mi ukáže co se změnilo a mohu uvést do původního stavu. Tím je zajištěno, že nebudu ničit databázi. Kontrolu provádí externí nástroj, takže nemusím nijak přizpůsobovat schema tomu verzování.

Pre take to domace bastlenie to staci. Aj v mensom teame je to vsak peklo. Ak sa budete chciet vyhnut koliziam s kolegami, tak sa udifujete k smrti. A ak budete chciet nasadit nejaku formu CI, tak sa bez tych migracii nezaobidete, budete ich musiet napisat dodatocne. Dalsia vyhoda je modularizacia. Kazdy modul moze mat vlastnu sadu migracii, nasadia sa len tie z pouzitych modulov.

Ve skutečnosti nemáš pravdu. Je to nasazené na celkem rozsáhlých projektech, od dvou, do šesti lidí. CI samozřejmě taky. Automatizace je moje druhé jméno.

Naviac vyspelejsie databazy ako mysql uzatvaraju do transakcie aj DDL, nie len DML. Cize ak uzavriete migraciu do transakcie, tak pri chybe v migracii dojde na rollback a db mate v povodnom stave. Nemusite potom bud obnovovat db zo zalohy, alebo este horsie nemusite riesit rozbitu produkcnu db.

Já vím.

To ci prejdu niektore dotazy (namatkou alter stplca, vytvorenie cudzieho kluca a podobne) vam nezaruci ze budete mat rovnaku strukturu, dost to zavisi aj na tom ake data su v tej db ulozene. Cize pri rovnakej strukture na teste aj na produkcii, vam script moze zbehnut bez problemov na test db, ale pri produkcnej vam to moze rachnut kdekolvek v tom scripte a mate veselo.

Je to tak jak říkáš. A?

Snažíš se narvat do otevřených dveří. Ten "script", o kterém mluvím je v tvojí řeči právě ty migrace. Jen to není svázáno s ORMkem, což je motivace proč ho upřednostňuju.

[Death Walker]

Snažíš se narvat do otevřených dveří. Ten "script", o kterém mluvím je v tvojí řeči právě ty migrace. Jen to není svázáno s ORMkem, což je motivace proč ho upřednostňuju.

Pisal som ja niekde o orm? To co som posielal ja funguje vzdy nad cli klientom db, ktoru sa rozhodnes pouzit. Je to riesenie, ktore spravuje komunita okolo toho projektu, ktore tym padom ma moznosti ktore pokryju vacsinu usecase. Migracie nie su o verzovani, to moc dobre ani nejde, sql je deklarativny jazyk, nie imperativny. I ked vies povedat kolko migracii si pozadu a ktore migracie boli z nejakeho dovodu vynechane.

I ked ak to spominas, tak sa s tym minimalne chces pochvalit. Mas link na repozitar? Inak o tom bude zbytocne pisat, ked to nikto nemoze pouzit.