DB séma kezelés Liquibase-el

Zoltán Németh
Zoltán NémethSenior Engineering Manager at IBM Watson Media, Budapest Lab (former Ustream)
DB séma kezelés Liquibase-el

Németh Zoltán
Backend lead, Ustream
A probléma
• gyakran változó, nagy db sémák
• sok fejlesztő, saját local db a fejlesztéshez
-> hibaforrás (eltérő db-re fejleszt mint az éles)
• ahhoz hogy működjön localban a site kellenek a db-be
adatok is
• automatizált DB tesztek futtatásához is egységes db kell
schema.sql fileok a repoban
• első megoldási kísérlet, így mindenkinek hozzáférhető
legalább a séma
• nem futtatható inkrementálisan, nem alter-ek hanem mindig
a pillanatnyi állapot leképezése, mint egy dump
• nincs rollback
• teljesen manuális, azon múlik minden hogy
o rendesen updatelik-e
o rendesen lefuttatják-e
• részben automatizálható, pl mysqldump
Liquibase

"Liquibase is an open source (Apache 2.0 Licensed), databaseindependent library for tracking, managing and applying
database changes. It is built on a simple premise: All database
changes are stored in a human readable yet trackable form
and checked into source control."
 
http://www.liquibase.org/ 
Fő jellemzők
•
•
•
•
•
•

Java executable
többféleképp futtatható: pl Ant, Maven, command line
XML changelogok
Update
Rollback
Generate changelog
Changelog
Changelog
Changelog (alter xml)
XML tagekkel leírható műveletek
•
•
•
•
•
•
•
•

add column, remove column
modify column, rename column
create / rename / drop table
create / rename / drop view
constraint műveletek (not null, unique, foreign key)
auto increment, default value
create / drop index
adat kezelés (insert, load, stb)
Changelog (alter sql)
Futtatás
liquibase --changeLogFile
sql/liquibase/<changelog>.xml --url
jdbc:mysql://localhost/<adatbazisnev>
<parancs>
• fontosabb parancsok:
o update
o rollback
o dry run: updateSql, rollbackSql
o changeset szám alapján: updateCount, rollbackCount
o tag
Update
• Changeset azonosítás id, author, filename alapján
• DATABASECHANGELOG nevű táblában tárolja a már
lefutott changeseteket
• az update parancs hatására lefuttatja azokat amik
nincsenek még a táblában
Rollback
• ha xml tagekkel adtuk meg az altert, vannak módosítás
típusok amiknél adott a rollback módja (pl addColumn)
• ha custom sql-el adjuk meg (illetve ha nem egyértelmű a
rollback módja pl drop), meg kell adnunk rollback sql-t is
• tagelni lehet a db állapotát
• rollbacknek meg lehet adni hogy melyik tagre menjen vissza
vagy hány changesetet
Bevezetés
• eredeti elképzelés: folyamatos automatikus generálás
o initial changelog az éles db alapján
o periodikusan futtatva diff megállapítása
o ebből diff changelog generálása
• végül ezt elvetettük mert
o changelog generálás nem volt túl gyors
o diff generálás időnként hibázott illetve elhalt
o rollback statement-ek generálása nem nagyon ment
Választott megoldás
• initial changelog generálás (végül a repoban levő
schema.sql alapján, majd később az éles db alapján
kiegészítettük)
• változások manuális managementje:
o changelog xml-ek kézzel íródnak
o commitoljuk őket
o az éles db-t nem automatikusan változtatjuk
(ez a backend review miatt is fontos)
• tesztekhez használt local db updatelését bekötöttük a test
bootstrap-be
Mit sikerült megoldani
• minden fejlesztőnek rendelkezésre áll a központival
megegyező db
• a szükséges kiinduló dataset is megvan
• egységes a db tesztkörnyezet, a CI környezet számára is
• viszonylag egyszerű a változás kezelése a korábbiakhoz
képest (schema.sql kézi módosítgatása)
• minden adatbázisunk le van fedve liquibase-el
Mit szeretnénk még megoldani
• Legyen legenerálható bármely db teljes séma sql-je (pl ha új
gépet húzunk fel). Ezt több módon is el lehet képzelni:
o liquibase-el felhúzzuk egy local db-be majd onnan
mysqldump
o vagy a fapados megoldás, egy script kiszedi az xml-ekből
az sql-eket - viszont akkor a tag-es changesetek kezelése
lesz macerás
• Minél több dolgot xml tagekkel írjunk le custom sql helyett
• Legyen mindenhez rollback statement ;)
Kérdések
Köszönöm a figyelmet
1 of 19

More Related Content

Similar to DB séma kezelés Liquibase-el(10)

LESS, mint css preprocessorLESS, mint css preprocessor
LESS, mint css preprocessor
Levente Kiraly1.1K views
PHP alkalmazások minőségbiztosításaPHP alkalmazások minőségbiztosítása
PHP alkalmazások minőségbiztosítása
Ferenc Kovács1.5K views
Advanced PL/SQL (HUN)Advanced PL/SQL (HUN)
Advanced PL/SQL (HUN)
Attila Budacsik1.3K views
A webes űrlapok csodálatos világaA webes űrlapok csodálatos világa
A webes űrlapok csodálatos világa
Szabolcs Bobor216 views
Termék-életciklus és a verziókezelésTermék-életciklus és a verziókezelés
Termék-életciklus és a verziókezelés
Attila Gábor Nagy459 views
Alumni Release ProcessAlumni Release Process
Alumni Release Process
Gábor Nagymajtényi177 views
Fejlesszünk okosan, közösenFejlesszünk okosan, közösen
Fejlesszünk okosan, közösen
Ákos Gábriel156 views

More from Zoltán Németh(11)

Reveal The Secrets of Your VideosReveal The Secrets of Your Videos
Reveal The Secrets of Your Videos
Zoltán Németh88 views
Scalable service architectures @ VDB16Scalable service architectures @ VDB16
Scalable service architectures @ VDB16
Zoltán Németh506 views
Scalable service architectures @ BWS16Scalable service architectures @ BWS16
Scalable service architectures @ BWS16
Zoltán Németh495 views
Content protection with UMSContent protection with UMS
Content protection with UMS
Zoltán Németh386 views
Scalable Service ArchitecturesScalable Service Architectures
Scalable Service Architectures
Zoltán Németh1.2K views
Implementing DevOps In PracticeImplementing DevOps In Practice
Implementing DevOps In Practice
Zoltán Németh1.5K views
Building our own CDNBuilding our own CDN
Building our own CDN
Zoltán Németh2K views
Culture @ Velocity UKCulture @ Velocity UK
Culture @ Velocity UK
Zoltán Németh725 views
On-demand real time transcoding On-demand real time transcoding
On-demand real time transcoding
Zoltán Németh387 views
Daemons in PHPDaemons in PHP
Daemons in PHP
Zoltán Németh663 views

DB séma kezelés Liquibase-el

  • 1. DB séma kezelés Liquibase-el Németh Zoltán Backend lead, Ustream
  • 2. A probléma • gyakran változó, nagy db sémák • sok fejlesztő, saját local db a fejlesztéshez -> hibaforrás (eltérő db-re fejleszt mint az éles) • ahhoz hogy működjön localban a site kellenek a db-be adatok is • automatizált DB tesztek futtatásához is egységes db kell
  • 3. schema.sql fileok a repoban • első megoldási kísérlet, így mindenkinek hozzáférhető legalább a séma • nem futtatható inkrementálisan, nem alter-ek hanem mindig a pillanatnyi állapot leképezése, mint egy dump • nincs rollback • teljesen manuális, azon múlik minden hogy o rendesen updatelik-e o rendesen lefuttatják-e • részben automatizálható, pl mysqldump
  • 4. Liquibase "Liquibase is an open source (Apache 2.0 Licensed), databaseindependent library for tracking, managing and applying database changes. It is built on a simple premise: All database changes are stored in a human readable yet trackable form and checked into source control."   http://www.liquibase.org/ 
  • 5. Fő jellemzők • • • • • • Java executable többféleképp futtatható: pl Ant, Maven, command line XML changelogok Update Rollback Generate changelog
  • 9. XML tagekkel leírható műveletek • • • • • • • • add column, remove column modify column, rename column create / rename / drop table create / rename / drop view constraint műveletek (not null, unique, foreign key) auto increment, default value create / drop index adat kezelés (insert, load, stb)
  • 11. Futtatás liquibase --changeLogFile sql/liquibase/<changelog>.xml --url jdbc:mysql://localhost/<adatbazisnev> <parancs> • fontosabb parancsok: o update o rollback o dry run: updateSql, rollbackSql o changeset szám alapján: updateCount, rollbackCount o tag
  • 12. Update • Changeset azonosítás id, author, filename alapján • DATABASECHANGELOG nevű táblában tárolja a már lefutott changeseteket • az update parancs hatására lefuttatja azokat amik nincsenek még a táblában
  • 13. Rollback • ha xml tagekkel adtuk meg az altert, vannak módosítás típusok amiknél adott a rollback módja (pl addColumn) • ha custom sql-el adjuk meg (illetve ha nem egyértelmű a rollback módja pl drop), meg kell adnunk rollback sql-t is • tagelni lehet a db állapotát • rollbacknek meg lehet adni hogy melyik tagre menjen vissza vagy hány changesetet
  • 14. Bevezetés • eredeti elképzelés: folyamatos automatikus generálás o initial changelog az éles db alapján o periodikusan futtatva diff megállapítása o ebből diff changelog generálása • végül ezt elvetettük mert o changelog generálás nem volt túl gyors o diff generálás időnként hibázott illetve elhalt o rollback statement-ek generálása nem nagyon ment
  • 15. Választott megoldás • initial changelog generálás (végül a repoban levő schema.sql alapján, majd később az éles db alapján kiegészítettük) • változások manuális managementje: o changelog xml-ek kézzel íródnak o commitoljuk őket o az éles db-t nem automatikusan változtatjuk (ez a backend review miatt is fontos) • tesztekhez használt local db updatelését bekötöttük a test bootstrap-be
  • 16. Mit sikerült megoldani • minden fejlesztőnek rendelkezésre áll a központival megegyező db • a szükséges kiinduló dataset is megvan • egységes a db tesztkörnyezet, a CI környezet számára is • viszonylag egyszerű a változás kezelése a korábbiakhoz képest (schema.sql kézi módosítgatása) • minden adatbázisunk le van fedve liquibase-el
  • 17. Mit szeretnénk még megoldani • Legyen legenerálható bármely db teljes séma sql-je (pl ha új gépet húzunk fel). Ezt több módon is el lehet képzelni: o liquibase-el felhúzzuk egy local db-be majd onnan mysqldump o vagy a fapados megoldás, egy script kiszedi az xml-ekből az sql-eket - viszont akkor a tag-es changesetek kezelése lesz macerás • Minél több dolgot xml tagekkel írjunk le custom sql helyett • Legyen mindenhez rollback statement ;)