Database / DevOps

    Database Migrations

    Flyway, Liquibase, Alembic — wersjonowanie schematu bazy, zero-downtime migrations, expand-contract pattern i rollback w mikrousługach.

    Flyway
    SQL-first Java
    Liquibase
    Enterprise rollback
    Alembic
    Python autogenerate
    Zero-downtime
    Bez blokady

    6 narzędzi do migracji baz danych

    Każde narzędzie jest dopasowane do innego ekosystemu i poziomu zaawansowania wymagań dotyczących rollback i automatyzacji.

    Narzędzie Język/Format Rollback Autogenerowanie Bazy Kiedy
    Flyway Java / SQL Tylko Teams (płatny) Nie PostgreSQL, MySQL, Oracle, SQL Server, inne Simple SQL-first, Java ecosystem
    Liquibase XML/YAML/SQL/JSON Wbudowany Nie Wszystkie (50+ baz) Enterprise, multi-DB, rollback wymagany
    Alembic Python downgrade() Tak (z SQLAlchemy) PostgreSQL, MySQL, SQLite, MS SQL Python/FastAPI/Django projekty
    Django Migrations Python migrate do poprzedniej wersji Tak (automatyczne) PostgreSQL, MySQL, SQLite, Oracle Django aplikacje
    Prisma Migrate TypeScript Manual SQL Tak (z Prisma schema) PostgreSQL, MySQL, SQLite, MongoDB Node.js/TypeScript projekty
    Goose Go / SQL down() function Nie PostgreSQL, MySQL, SQLite, MS SQL Go microservices

    Często zadawane pytania

    Co to są database migrations i jakie narzędzia wybrać?

    Database migrations: skrypty zmieniające schemat bazy danych w kontrolowany, wersjonowany sposób. Bez migracji: każdy developer ma inną wersję schematu. Środowisko staging różni się od produkcji. Nie ma historii zmian. Problem rollback. Z migracjami: każda zmiana schematu = osobny plik migracji. Numerowane lub timestampowane (20240413_001_add_user_table.sql). Narzędzie wykonuje pending migracje w kolejności. Śledzi które zostały wykonane (tabela schema_migrations lub flyway_schema_history). Narzędzia migracji: Flyway (Java/JVM, ale działa dla każdej DB): wersjonowane SQL lub Java migracje. V1__init.sql, V2__add_index.sql. Repeatable migracje (R__) dla views/functions. Baseline dla istniejących baz. Liquibase: XML/YAML/JSON/SQL changesets. Changeset tracking per author i id. Rollback support (wbudowany). Alembic (Python, SQLAlchemy): autogenerate migracji z modeli. Revision system. Goose (Go): SQL lub Go migracje. Wbudowany w wiele Go frameworków. Flyway vs Liquibase: Flyway — prostszy, SQL-first. Liquibase — bardziej zaawansowany, rollback, wieloplatformowy. Rails ActiveRecord Migrations: Ruby DSL. up/down methods. Zero-downtime migrations gems.

    Zero-downtime database migrations — jak nie blokować produkcji?

    Wyzwanie: ALTER TABLE na dużej tabeli (miliony wierszy) blokuje tabelę na minuty lub godziny. Użytkownicy nie mogą czytać ani pisać. Problem: dodanie NOT NULL kolumny, zmiana typu, dodanie constraint. Strategie zero-downtime: 1. Dodaj kolumnę jako nullable: ALTER TABLE orders ADD COLUMN new_field VARCHAR(255). Nie blokuje, bo domyślnie nullable. 2. Backfill danych: UPDATE orders SET new_field = compute(old_field) WHERE new_field IS NULL LIMIT 1000. Batch update (nie blokuj cały UPDATE). 3. Dodaj NOT NULL constraint z DEFAULT: ALTER TABLE orders ALTER COLUMN new_field SET NOT NULL. 4. Usuń starą kolumnę (po migracji kodu). Expand-Contract pattern: Expand — dodaj nowe pole/tabelę. Contract — usuń stare po migracji kodu. Rolling rename: kolumna renamed -> dodaj nową, kopiuj dane, stara pozostaje jako alias, usuń starą. pg_repack / online DDL: pg_repack — przebudowuje tabelę bez blokowania. CREATE TABLE AS SELECT, swap. Percona pt-online-schema-change dla MySQL. MySQL 8+ / PostgreSQL 12+ mają wbudowane online DDL. gh-ost (GitHub): ghost table approach. Online schema migration dla MySQL. Używany przez GitHub. Liquibase Pro: wbudowane runAlways migrations. Flyway Dry Runs: weryfikacja przed produkcją.

    Flyway — jak skonfigurować i używać w CI/CD?

    Flyway konfiguracja: flyway.url = jdbc:postgresql://localhost:5432/mydb. flyway.user = dbuser. flyway.password = secret. flyway.locations = classpath:db/migration. Konwencja nazw: V{version}__{description}.sql. V1__Create_users_table.sql. V2__Add_email_index.sql. V2.1__Add_role_column.sql. Repeatable: R__{description}.sql — wykonywane gdy checksum zmieni się. Dobre dla views, functions, stored procedures. Baseline: flyway baseline — oznacz istniejącą DB jako wyjściowy punkt. Flyway Maven/Gradle plugin: mvn flyway:migrate — wykonaj pending migracje. mvn flyway:info — pokaż status migracji. mvn flyway:validate — sprawdź checksum. mvn flyway:repair — napraw failed migracje. CI/CD integration: Spring Boot auto-migrate przy starcie (spring.flyway.enabled=true). Kubernetes init container: wywołaj flyway:migrate przed startem aplikacji. GitHub Actions: krok 'Run DB migrations' przed 'Deploy application'. Multiple environments: osobna konfiguracja flyway per environment. flyway.out-of-order=false — nie pozwól na migracje poza kolejnością. Checksum validation: Flyway oblicza checksum dla każdego pliku. Zmodyfikowanie wykonanej migracji = błąd. Nigdy nie modyfikuj wykonanych migracji — twórz nowe. Flyway Teams: undo support (V1__create.sql -> U1__undo_create.sql). Dry run. Cherry-pick.

    Rollback database migrations — jak cofnąć zmiany?

    Rollback schematu bazy: trudniejszy niż rollback kodu (nie możesz po prostu wrócić do poprzedniej wersji). Podejścia: Up/Down migrations: każda migracja ma up() i down(). up() = wykonaj zmianę. down() = cofnij zmianę. Problem: przy dużej ilości danych down() może nie odtworzyć usuniętych danych. Liquibase rollback: OOTB support. rollback przez tag lub date. Odwraca changesets w odwrotnej kolejności. Flyway Undo (Teams): U{version}__{description}.sql. flyway:undo — cofnij ostatnią migrację. Expand-Contract rollback: Contract krok (usunięcie starego) = osobny deploy. Rollback = nie wykonaj Contract kroku. Stare i nowe istnieją razem. Feature Flags: aplikacja ma feature flag per migration. Rollback = wyłącz flag (nie cofaj schematu). Backup przed migracją: snapshot DB przed dużą migracją. Rollback = restore snapshot (downtime ale bezpieczne). Incremental backup (WAL-G dla PostgreSQL). Blue-Green Deployment: dwa środowiska (Blue = stare, Green = nowe). Migration na Green. Switch traffic na Green. Rollback = switch z powrotem na Blue. Wymaga synchronizacji danych między Blue i Green. Migration testing: sprawdź migrację na staging przed produkcją. Test down() przed produkcją. Automated rollback tests w CI.

    Database schema evolution w mikrousługach — jak zarządzać?

    Wyzwanie mikrousług: każda mikrousługa ma własną bazę danych. Każda może być deployowana niezależnie. Musimy zapewnić backward compatibility podczas rolling deployment. Zasady schema evolution: Additive changes only (dodaj, nie modyfikuj/usuwaj): dodanie nowej kolumny (nullable). dodanie nowej tabeli. dodanie nowego indeksu (CONCURRENTLY). Never remove columns that code uses: deprecate -> aplikacja przestaje używać -> usuń kolumnę. Two-phase deployment: faza 1 — deploy nowego kodu który obsługuje zarówno stary jak i nowy schemat. Wykonaj migrację. faza 2 — deploy kodu który wymaga nowego schematu (usuwa obsługę starego). Shared Database Anti-Pattern: wiele mikrousług na jednej bazie. Trudne migracje bo wiele serwisów zależy od jednego schematu. Rozwiązanie: oddzielna baza per mikrousługa. Consumer-Driven Contract Testing: definiuje kontrakt między serwisem a jego bazą. Schemaspy: automatyczna dokumentacja schematu. Diagram ER z istniejącej bazy. Liquibase Checks: automated compliance checks. Blokuj kolumny bez default przy NOT NULL. Enforced naming conventions. Database Schema Registry: centralne repozytorium schematów. Event Schema Registry (Confluent) dla event-driven. Avro/Protobuf schema evolution (backward/forward compatible). Migration in large teams: każdy developer tworzy własną gałąź migracji. Sequentialna numeracja przez CI (timestamp). Merge konflikty na numerach = CI blokuje.

    Czytaj dalej

    Powiązane artykuły

    Kontakt

    Skontaktuj się z nami

    Porozmawiajmy o Twoim projekcie. Bezpłatna wycena w ciągu 24 godzin.

    Wyślij zapytanie

    Bezpłatna wycena w 24h
    Bez zobowiązań
    Indywidualne podejście
    Ekspresowa realizacja

    Telefon

    +48 790 814 814

    Pon-Pt: 9:00 - 18:00

    Email

    adam@fotz.pl

    Odpowiadamy w ciągu 24h

    Adres

    Plac Wolności 16

    61-739 Poznań

    Godziny pracy

    Pon - Pt9:00 - 18:00
    Sob - NdzZamknięte

    Wolisz porozmawiać?

    Zadzwoń teraz i porozmawiaj z naszym specjalistą o Twoim projekcie.

    Zadzwoń teraz