AWS Database Migration Service (DMS) - jak migrować bazy danych na AWS

Ten artykuł jest skierowany do organizacji, które planują migrację produkcyjnej bazy danych na AWS – czy to w ramach wyjścia z drogich licencji (Oracle, SQL Server), czy przeniesienia z on-premise do chmury. Jeśli szukasz konkretnego scenariusza Oracle → PostgreSQL, zobacz kompletny przewodnik migracji Oracle do PostgreSQL. Jeśli potrzebujesz ogólnego procesu migracji do AWS (nie tylko bazy), zobacz przewodnik migracji do chmury AWS.

Co to jest AWS DMS i kiedy go używać

AWS Database Migration Service przenosi dane między bazami – od jednorazowego skopiowania po ciągłą replikację w czasie rzeczywistym. Kluczowa zaleta: baza źródłowa pozostaje w pełni operacyjna przez cały czas trwania migracji. Aplikacje działają, użytkownicy pracują, a DMS w tle kopiuje dane i śledzi zmiany.

DMS obsługuje dwa typy migracji:

• Homogeniczna – ten sam silnik po obu stronach (Oracle → Oracle na RDS, PostgreSQL → Aurora PostgreSQL, MySQL → RDS MySQL). Schemat przenosi się praktycznie bez zmian, DMS zajmuje się danymi.
• Heterogeniczna – różne silniki (Oracle → PostgreSQL, SQL Server → Aurora MySQL). Tu potrzebna jest wcześniejsza konwersja schematu przez SCT, a dopiero potem DMS migruje dane.

Kiedy DMS jest właściwym narzędziem

• Migrujesz produkcyjną bazę i nie możesz sobie pozwolić na wielogodzinny przestój
• Przenosisz z on-premise (lub innej chmury) do RDS / Aurora
• Wychodzisz z komercyjnych licencji (Oracle, SQL Server) na open-source (PostgreSQL, MySQL)
• Potrzebujesz ciągłej replikacji między bazami (np. do raportowania na osobnej instancji)

Kiedy DMS nie jest potrzebny

• Baza jest mała (< 10 GB) i możesz pozwolić sobie na przestój – natywny pg_dump/mysqldump bywa prostszy
• Migracja jest homogeniczna i możesz użyć natywnych snapshotów (np. snapshot RDS → restore)
• Potrzebujesz wyłącznie konwersji schematu bez przenoszenia danych – to zadanie dla SCT, nie DMS

DMS i SCT – podział ról

To najczęstsze źródło nieporozumień, więc rozłóżmy to jasno. DMS i SCT to dwa osobne narzędzia, które rozwiązują dwa różne problemy:

W migracji homogenicznej (Oracle → Oracle) schemat jest zgodny, więc SCT często jest zbędny – wystarczy DMS. W migracji heterogenicznej (Oracle → PostgreSQL) kolejność jest zawsze taka sama: najpierw SCT konwertuje i wdraża schemat na bazie docelowej, potem DMS wypełnia go danymi. Uruchomienie DMS bez wcześniejszej konwersji schematu na pustej, niezgodnej bazie po prostu się nie powiedzie.

Full Load vs CDC – dwa tryby migracji

DMS oferuje trzy tryby zadań replikacyjnych. Wybór decyduje o długości przestoju.

Full Load (pełne ładowanie)

Jednorazowe skopiowanie wszystkich danych ze źródła do celu. Proste, ale wymaga, aby przez czas ładowania nic się nie zmieniało w bazie źródłowej (lub żebyś zaakceptował utratę zmian z tego okna serwisowego). Odpowiednie dla:

• Baz < 100 GB
• Środowisk dev/staging
• Migracji z zaplanowanym oknem serwisowym (weekend, noc)

Full Load + CDC

Najpierw pełne ładowanie, a następnie DMS przełącza się na ciągłą replikację zmian (Change Data Capture). Wszystko, co zmieniło się w bazie źródłowej w trakcie i po pełnym ładowaniu, jest replikowane na bieżąco. To ten tryb daje minimalny przestój przy przełączeniu produkcji. Wymaga włączenia logowania zmian po stronie źródła (patrz niżej).

Tylko CDC

Replikacja samych zmian, bez początkowego ładowania – stosowana, gdy dane historyczne przeniesiono inną metodą (np. snapshot), a DMS ma tylko dogonić zmiany od określonego punktu.

Co CDC wymaga po stronie źródła

Migracja z DMS krok po kroku

Koszty AWS DMS

DMS jest tani względem wartości, którą dostarcza – główny koszt to czas pracy instancji replikacyjnej, nie sama usługa.

Dla typowej migracji trwającej 3-4 tygodnie (z okresem równoległego CDC) koszt samej usługi DMS to zwykle kilkaset do ~2 tys. PLN. To pomijalna pozycja względem całkowitego kosztu projektu migracyjnego – szczegółowe widełki w przewodniku po kosztach migracji do AWS.

DMS a Database Savings Plans

Warto wiedzieć, że koszty instancji replikacyjnej DMS są objęte przez Database Savings Plans – ten sam model zobowiązania, który obniża rachunek za instancje RDS i Aurora. W zamian za deklarację stałego wydatku (mierzonego w $/h) na 1 lub 3 lata otrzymujesz zniżkę względem stawki on-demand.

Dla jednorazowej migracji trwającej 1-3 miesiące zwykle nie ma to sensu – zobowiązanie na rok przy kilkutygodniowym projekcie się nie zwraca. Ale przy ciągłej replikacji CDC utrzymywanej długoterminowo instancja DMS działa non-stop, a wtedy Database Savings Plan potrafi zdjąć znaczącą część tego kosztu z budżetu.

Najczęstszy taki scenariusz to zasilanie hurtowni danych (data warehouse). DMS bywa wykorzystywany nie tylko do jednorazowej migracji, ale jako stały mechanizm replikacji zmian z bazy transakcyjnej (OLTP) do hurtowni – Amazon Redshift, S3 czy innej platformy analitycznej. Tu instancja replikacyjna działa bezterminowo, bo strumień CDC nigdy się nie kończy. To modelowy przypadek pod Database Savings Plan: stały, przewidywalny wydatek utrzymywany latami, idealny do objęcia zobowiązaniem.

Database Savings Plans opiszemy szerzej w osobnym artykule. Na potrzeby migracji zapamiętaj regułę: projekt jednorazowy → on-demand; długotrwały CDC (np. zasilanie hurtowni danych) → rozważ Savings Plan.

Typowe pułapki migracji z DMS

1. LOB-y (Large Objects) i ich obsługa

Problem: Kolumny BLOB/CLOB/BYTEA wymagają specjalnej konfiguracji. Domyślny tryb DMS (Limited LOB) ucina dane powyżej ustalonego rozmiaru, co prowadzi do cichej utraty danych.

Rozwiązanie: Dla tabel z dużymi LOB-ami używamy trybu Full LOB lub Inline LOB z odpowiednio dobranym LobMaxSize. Zawsze weryfikujemy sumy kontrolne na tabelach z LOB-ami po migracji.

2. Tabele bez klucza głównego

Problem: CDC opiera się na identyfikacji wierszy. Tabele bez klucza głównego lub unikalnego indeksu powodują problemy przy replikacji zmian (UPDATE/DELETE nie mają jak trafić w konkretny wiersz).

Rozwiązanie: Identyfikacja takich tabel w fazie oceny. Dodanie klucza głównego przed migracją albo świadoma decyzja o migracji tych tabel wyłącznie w trybie Full Load.

3. Opóźnienie CDC rośnie w czasie

Problem: Przy dużym wolumenie transakcji na źródle opóźnienie CDC potrafi narastać, co uniemożliwia czyste przełączenie.

Rozwiązanie: Zwiększenie rozmiaru instancji replikacyjnej, podział zadania na kilka równoległych (per grupa tabel), strojenie ParallelLoadThreads. Monitorujemy CDCLatencyTarget od pierwszego dnia, nie w dniu cutoveru.

4. Klucze obce i kolejność ładowania

Problem: Ograniczenia klucza obcego blokują ładowanie danych w niewłaściwej kolejności (dziecko przed rodzicem).

Rozwiązanie: Wyłączenie ograniczeń na czas pełnego ładowania (session_replication_role = replica na PostgreSQL), włączenie ich z powrotem po zakończeniu i walidacja integralności.

5. Typy danych bez odpowiednika

Problem: Przy migracji heterogenicznej niektóre typy źródłowe nie mają bezpośredniego odpowiednika w celu (to zadanie SCT, ale DMS ujawnia problem przy ładowaniu).

Rozwiązanie: Rozwiązywane na etapie konwersji schematu (SCT). DMS z transformacjami może dodatkowo rzutować typy w locie, ale lepiej naprawić to w schemacie niż w zadaniu replikacyjnym.

Jak AWS MAP finansuje migrację z DMS

Migracja bazy danych realizowana z użyciem DMS niemal zawsze wpisuje się w program AWS Migration Acceleration Program (MAP) – zwłaszcza gdy celem jest wyjście z komercyjnych licencji (Oracle, SQL Server) na Aurora lub RDS.

Dla migracji baz Oracle i SQL Server AWS prowadzi dedykowane ścieżki z podwyższonym budżetem – szczegóły opisujemy w przewodniku migracji Oracle do PostgreSQL. Kwalifikacja wymaga aktywnego środowiska źródłowego, celu w postaci natywnej usługi AWS i certyfikowanego partnera MAP, który składa wniosek. Zajmujemy się tym od A do Z.

Najczęściej zadawane pytania

Następne kroki – bezpłatna ocena migracji bazy danych

Każda migracja z DMS zaczyna się od oceny środowiska źródłowego. Analizujemy Twoje bazy (silnik, rozmiar, wolumen transakcji, tabele bez kluczy głównych, obecność LOB-ów, punkty integracji) i wracamy z konkretem:

1. Rekomendacja trybu – Full Load vs CDC, w zależności od wymagań co do przestoju
2. Dobór instancji replikacyjnej i architektury – rozmiar, sieć, Multi-AZ
3. Realistyczny harmonogram i kosztorys – w tym projekcja dofinansowania MAP
4. Plan przełączenia – jak przejść z minimalnym wpływem na biznes

Realizowaliśmy migracje baz danych dla firm z sektora finansowego, ubezpieczeniowego i administracji publicznej w Polsce. Niezależnie od tego czy wychodzisz z drogich licencji, czy przenosisz się z on-premise do chmury – pierwszy krok to zrozumienie, z czym mamy do czynienia.

Planujesz migrację bazy danych na AWS?

Umów bezpłatną 30-minutową rozmowę. Wstępnie ocenimy złożoność migracji, dobierzemy tryb DMS i sprawdzimy, czy Twój projekt kwalifikuje się do dofinansowania AWS MAP (typowo 70-80% kosztów).

Umów rozmowę Wyślij wiadomość