Migracja PostgreSQL do Amazon RDS – Kompletny Przewodnik krok po kroku

Każdego dnia tysiące firm stają przed tym samym dylematem: przez lata rozwijali swoje bazy danych PostgreSQL na serwerach on-premise, a teraz czas goni, infrastruktura się starzeje, a koszty utrzymania rosną w zastraszającym tempie. Jeśli dodamy do tego konieczność zapewnienia ciągłości działania podczas migracji i brak zespołu z doświadczeniem w chmurze — mamy przepis na migracyjny paraliż. Tymczasem według raportu McKinsey z 2024 roku, firmy, które prawidłowo przeprowadziły migrację baz danych do chmury, zmniejszyły koszty operacyjne średnio o 40% w ciągu pierwszych dwóch lat.

W tym poradniku dowiesz się, jak przeprowadzić migrację PostgreSQL do Amazon RDS bezpiecznie, efektywnie i bez przestojów. Konkretne komendy, konkretne narzędzia, zero teorii bez praktycznego zastosowania.

Migracja PostgreSQL do Amazon RDS składa się z 6 głównych faz: 1) analiza środowiska źródłowego i dobór docelowej instancji RDS, 2) konfiguracja środowiska docelowego w AWS, 3) wybór metody migracji (AWS DMS lub pg_dump), 4) przeprowadzenie migracji z walidacją danych, 5) optymalizacja wydajności po migracji, 6) przełączenie ruchu produkcyjnego z mechanizmem failback. Całość dla typowej bazy 100 GB zajmuje 4-8 godzin aktywnej pracy.

Dlaczego warto migrować PostgreSQL do Amazon RDS?

Decyzja o migracji to nie tylko kwestia mody na chmurę. Amazon Web Services (AWS) oferuje w przypadku RDS szereg korzyści operacyjnych, które realnie przekładają się na biznes.

Zarządzanie cyklem życia bazy danych — w przypadku PostgreSQL on-premise musisz samodzielnie dbać o aktualizacje silnika, patche bezpieczeństwa, backup'y i ich weryfikację. RDS przejmuje te obowiązki. W praktyce oznacza to oszczędność 15-20 godzin miesięcznie pracy DBA na średniej wielkości bazie.

Automatyczne backup'y z retention do 35 dni — standard w RDS, podczas gdy on-premise wymaga to dodatkowej konfiguracji, monitoringu i testów przywracania.

Read Replicas — tworzenie replik do odczytu jedną komendą. Dla aplikacji z dominującym ruchem SELECT (e-commerce, analytics, reporting) to game changer. Konfiguracja w RDS zajmuje 15 minut zamiast 2 dni na tradycyjnej replikacji streamingowej.

Multi-AZ Deployments — automatyczny failover w przypadku awarii instancji. RTO (Recovery Time Objective) spada z godzin do 1-2 minut. Dla systemów produkcyjnych to nie luksus, a wymóg.

Koszty vs. CapEx — klasyczny trade-off. Serwer on-premise wymaga jednorazowej inwestycji + stałych kosztów prądu, chłodzenia, serwisowania. RDS to OPEX z modelem pay-as-you-go. Dla firm w fazie wzrostu przewidywalność kosztów miesięcznych bywa ważniejsza niż całkowity koszt posiadania.

Faza 1: Analiza środowiska źródłowego (Dzień 1-2)

Przed uruchomieniem jakiejkolwiek migracji musisz zrozumieć, z czym konkretnie masz do czynienia. Pomijanie tego kroku to główna przyczyna nieudanych migracji.

Inwentarz baz danych i schematów

Zacznij od zebrania informacji o wszystkich bazach na serwerze źródłowym. Uruchom na serwerze PostgreSQL:

SELECT datname, pg_size_pretty(pg_database_size(datname)) AS size 
FROM pg_database 
ORDER BY pg_database_size(datname) DESC;

To da ci rozmiar każdej bazy. Następnie zidentyfikuj wszystkie rozszerzenia:

SELECT * FROM pg_extension;

Krytyczne pytanie: które rozszerzenia są aktywnie używane przez aplikację? RDS obsługuje około 50 rozszerzeń out-of-the-box, ale nie wszystkie. Np. PostGIS działa, ale wymaga wybrania odpowiedniej opcji przy tworzeniu instancji. Rozszerzenia jak pg_partman, pg_cron, czy niektóre wersje pgvector wymagają custom parameter group.

Analiza wydajności i obciążenia

Zbierz statystyki obciążenia z ostatnich 30 dni:

SELECT 
  date_trunc('hour', query_start) AS hour,
  COUNT(*) AS query_count,
  AVG(duration) AS avg_duration_ms,
  MAX(duration) AS max_duration_ms
FROM pg_stat_activity
WHERE state = 'active' AND query_start > NOW() - INTERVAL '30 days'
GROUP BY hour
ORDER BY hour;

Na co zwrócić uwagę:

• Szczyty obciążenia (peak hours) — podczas migracji musisz zaplanować okno konserwacji lub użyć mechanizmu CDC
• Długie zapytania (>5 sekund) — sugerują problemy z indeksami lub nieoptymalnymi zapytaniami, które przeniosą się na RDS
• Liczba połączeń — RDS PostgreSQL obsługuje maksymalnie w zależności od klasy: db.t3.micro = ~50, db.r7g.xlarge = ~3000

Weryfikacja wersji PostgreSQL

AWS RDS dla PostgreSQL aktualnie wspiera wersje 11.x do 16.x. Sprawdź swoją wersję:

SELECT version();

Jeśli używasz PostgreSQL 10 lub niższej — migracja wymaga najpierw upgrade'u wersji po stronie źródłowej. To dodatkowy krok, który może trwać tygodnie w przypadku starszych aplikacji z zależnościami od deprecated funkcji.

Faza 2: Dobór instancji RDS i konfiguracja środowiska (Dzień 2-3)

Wybór klasy instancji

AWS oferuje kilka rodzin instancji zoptymalizowanych pod różne przypadki użycia:

Rodzina	Charakterystyka	Dla kogo
db.t3	Budget-friendly, burstable	Środowiska deweloperskie, małe produkcyjne
db.m5	Balanced compute/memory	Większość aplikacji produkcyjnych
db.r7g	Memory-optimized	Bazy z high cache utilization, OLTP
db.x2idn	Memory-optimized	Duże bazy (1TB+ RAM)

Praktyczna rekomendacja: Dla aplikacji webowych z bazą 50-200 GB zacznij od db.r6g.large (2 vCPU, 16 GB RAM) lub db.m6g.xlarge (4 vCPU, 16 GB RAM). Unikaj startowania od t3.micro w produkcji — bursting credits potrafią się wyczerpać w najgorszym momencie.

Konfiguracja storage

RDS PostgreSQL oferuje dwa typy storage:

• General Purpose SSD (gp3) — nowszy, tańszy, przewidywalna wydajność. 3000 IOPS i 125 MB/s throughput w cenie.
• Provisioned IOPS SSD (io2) — dla baz z wymagającymi workload'ami I/O. Gwarantowane IOPS niezależnie od rozmiaru.

Dla większości migracji gp3 wystarczy. Przejdź na io2 tylko jeśli:

• Baza generuje >10 000 IOPS sustained
• Aplikacja ma strict latency requirements (<1 ms)
• Audit compliance wymaga gwarantowanej wydajności

Grupy parametrów (Parameter Groups)

RDS pozwala na konfigurację parametrów PostgreSQL przez Parameter Groups. Utwórz własną grupę na bazie grupy domyślnej i dostosuj kluczowe parametry:

max_connections = 500
work_mem = 262144  # 256 MB na sortowanie
maintenance_work_mem = 524288  # 512 MB dla VACUUM, CREATE INDEX
effective_cache_size = 12GB  # 75% dostępnej RAM
shared_buffers = 4GB  # 25% RAM

Ważne: te wartości to punkt wyjścia. Ostateczna konfiguracja wymaga tuningu na podstawie rzeczywistego obciążenia po migracji.

Konfiguracja sieci i bezpieczeństwa

Instancja RDS musi być w prywatnej subnet w VPC. Nigdy nie wystawiaj RDS bezpośrednio na publiczny internet.

Utwórz strukturę:

• Public Subnet — dla bastion hosta (jump server)
• Private Subnet (min. 2, w różnych AZ) — dla RDS
• Security Group — whitelist only. Typowy setup:
  • Port 5432 (PostgreSQL) tylko z Security Group aplikacji
  • Port 443 dla HTTPS z anywhere (dla AWS Management Console access)

Faza 3: Wybór metody migracji

Masz dwie główne ścieżki. Wybór zależy od rozmiaru bazy, tolerancji na przestój i dostępnego окна migracyjnego.

Opcja A: AWS Database Migration Service (DMS) — dla minimalnego przestoju

AWS DMS to w pełni zarządzana usługa migracji, która obsługuje migrację jednorazową lub ciągłą (CDC — Change Data Capture).

Kiedy używać DMS:

• Baza >100 GB (dump/restore trwa zbyt długo)
• Wymagasz minimalnego przestoju produkcyjnego
• Migracja z ciągłą replikacją na żywo

Koszty DMS: Opłaty za instancję replikacyjną (od ~$0.046/h za small instance) + koszty data transfer. Dla jednorazowej migracji użyj smaller instance i wyłącz po zakończeniu.

Kroki konfiguracji DMS:

1. Utwórz Replication Instance w tym samym VPC co docelowy RDS:

   • Wybierz klasę appropriate dla wolumenu danych
   • Multi-AZ zalecane dla produkcji

2. Skonfiguruj Source Endpoint (on-premise PostgreSQL):

   • Wymaga włączenia logical replication: wal_level = logical
   • Dodaj użytkownika z uprawnieniami: rds_superuser lub dedykowany user z REPLICATION
   • Jeśli on-premise — wymagany public endpoint lub VPN/Direct Connect

3. Skonfiguruj Target Endpoint (RDS PostgreSQL):

   • Master username i password z utworzonej instancji
   • Test połączenia przed kontynuacją

4. Utwórz Database Migration Task:

   • Wybierz Full Load + CDC dla migracji z ciągłą replikacją
   • Dla tabel z foreign keys wybierz "Do nothing" na truncate target
   • Włącz Validation dla weryfikacji danych po migracji

5. Monitoruj postęp:

   • CloudWatch Metrics: CDCChangesDiskCache, CDCThroughput
   • Status w DMS Console: load complete, replication ongoing

Opcja B: pg_dump + pg_restore — dla małych baz i prostych migracji

Dla baz <20 GB z akceptowalnym przestojem (1-4 godziny) klasyczne podejście z pg_dump jest szybsze w konfiguracji.

# Export ze źródła
pg_dump -h source-db-host -U postgres -d sourcedb \
  --format=custom \
  --jobs=4 \
  --verbose \
  -f backup.dump

# Import do RDS
pg_restore -h target-rds-endpoint.rds.amazonaws.com \
  -U postgres \
  -d targetdb \
  --jobs=4 \
  --verbose \
  backup.dump

Opcje --jobs wykorzystują wielowątkowość — zdecydowanie zalecane dla przyspieszenia. Dla dysku SSD na źródle i docelu pozwala to osiągnąć ~50-100 GB/h.

UWAGA: Jeśli używasz LARGE OBJECT (lo_import/lo_export), pg_dump domyślnie je pominie. Użyj flagi -- blobs lub -- large-objects.

Faza 4: Walidacja danych po migracji

Niezależnie od wybranej metody — walidacja jest obowiązkowa. Poleganie na komunikacie "migration completed" to ryzykowna strategia.

Checklist walidacyjny

1. Sprawdzenie liczby tabel i wierszy:

-- Na źródle
SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'public';
SELECT schemaname, tablename, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC;

-- Na celu — porównaj wyniki

2. Weryfikacja integralności referencyjnej:

-- Liczba naruszonych foreign keys
SELECT COUNT(*) FROM information_schema.table_constraints 
WHERE constraint_type = 'FOREIGN KEY';

-- Testuj losowe foreign key relationship
SELECT * FROM orders LIMIT 1;
-- zweryfikuj, że customer_id istnieje w tabeli customers

3. Sumy kontrolne kluczowych tabel:

SELECT 'orders' AS table_name, COUNT(*) AS row_count, 
  SUM(total_amount) AS total_value 
FROM orders WHERE created_at > '2024-01-01';

-- Powtórz na źródle i porównaj

4. Indexy i constraints:

SELECT indexname, indexdef FROM pg_indexes 
WHERE schemaname = 'public' ORDER BY indexname;

5. Funkcje i trigger'y:

SELECT routine_name, routine_type FROM information_schema.routines 
WHERE routine_schema = 'public';

SELECT tgname, tgtype FROM pg_trigger 
WHERE NOT tgisinternal;

Faza 5: Optymalizacja po migracji

Po uruchomieniu bazy na RDS pierwsze 2-3 tygodnie to okres tuningu. Typowe problemy po migracji:

Parametry wymagające korekty

shared_buffers — domyślna wartość w RDS (25% RAM) to dobry start, ale możesz zwiększyć do 40-45% na dedykowanych instancjach bez innych usług.

effective_cache_size — powinien być ustawiony na 75% dostępnej pamięci RAM. Informuje planner o dostępnej pamięci cache systemu operacyjnego.

random_page_cost — w RDS z SSD powinien być ustawiony na 1.1 zamiast domyślnego 4.0. To znacząco wpływa na wybór planu zapytania.

Włączenie Performance Insights

RDS Performance Insights to wbudowane narzędzie do analizy wydajności. Kosztuje ~$0.025/vCPU-hour, ale zwraca się w postaci szybciej wykrytych bottleneck'ów.

-- Aktywacja dla instancji RDS
aws rds modify-db-instance \
  --db-instance-identifier my-db-instance \
  --enable-performance-insights \
  --performance-insights-retention-period 7

Check'y automatyczne

Skonfiguruj CloudWatch Alerts dla:

• CPUUtilization > 80% sustained > 5 minutes
• DatabaseConnections > 80% max_connections
• FreeStorageSpace < 20%
• ReplicaLag > 300 seconds (dla read replicas)

Faza 6: Przełączenie produkcji

To moment prawdy. Masz dwa podejścia:

Greenfield (przełączenie jednorazowe)

1. Zaplanuj okno maintenance (najlepiej nocne, low traffic)
2. Wstrzymaj zapis do aplikacji
3. Wykonaj finalną synchronizację (DMS catch-up lub final dump)
4. Przetestuj connectivity z nowym endpoint'em
5. Zaktualizuj connection strings w aplikacji
6. Zrestartuj aplikację
7. Monitoruj przez 2-4 godziny

Blue-Green Deployment (zero-downtime)

Dla krytycznych systemów:

1. Utwórz środowisko green (nowy RDS) z pełną replikacją
2. Skonfiguruj Read Replica jako intermediate step
3. Przetestuj aplikację na green environment
4. Użyj Route 53 dla traffic shifting
5. Stopniowo przekierowuj ruch: 1% → 10% → 50% → 100%
6. Po stabilizacji — wyłącz stare środowisko

Czas przełączenia: Green-green dla 100 GB bazy z DMS to ~30-60 minut na final sync + 15 minut na testy. Przestój aplikacji: 5-15 minut na DNS propagation i restart.

Typowe pułapki i jak ich unikać

Pułapka #1: Firewall blocks DMS connectivity
RDS w private subnet wymaga, żeby DMS Replication Instance był w tym samym VPC lub w peered VPC. On-premise source wymaga publicznego endpointu lub VPN.

Pułapka #2: Character set mismatch
PostgreSQL domyślnie używa UTF8, ale stare bazy czasem mają LATIN2. Upewnij się, że docelowa instancja RDS ma ten sam encoding.

Pułapka #3: Password z special characters
Jeśli hasło użytkownika DMS zawiera znaki specjalne używane w JSON (np. " lub \), endpoint connection string może się nie parse'ować. Escape'uj je poprawnie.

Pułapka #4: Sequences out of sync
Po pg_dump restore sequences (serial, bigserial) mogą mieć wartości niższe niż max wartość w tabeli. Użyj:

SELECT setval(pg_get_serial_sequence('orders', 'id'), 
              COALESCE(MAX(id), 0) + 1) FROM orders;

Pułapka #5: DMS z foreign keys
Przy migracji z DMS i tabelami z foreign keys musisz wybrać opcję "Truncate target" zamiast "Delete rows" lub użyć "Do nothing" i ręcznie załadować w kolejności bez foreign key dependencies.

Podsumowanie: Czy migracja się opłaca?

Po 15 latach budowania infrastruktury on-premise i ostatnich 5 latach realizacji migracji do AWS mogę powiedzieć jednoznacznie: tak, ale tylko jeśli zrobisz to prawidłowo.

Migracja PostgreSQL do Amazon RDS zmniejsza koszty operacyjne, eliminuje single point of failure, daje dostęp do nowych funkcji bez upgrade'ów hardware'u i pozwala zespołowi skupić się na rozwoju produktu zamiast utrzymywaniu infrastruktury. Ale źle przeprowadzona migracja — bez walidacji, bez testów, bez planu rollback — kosztuje więcej niż pozostanie na starym systemie.

Kluczowe wnioski:

1. Analizuj przed migracją — 2 dni analizy oszczędzą 2 tygodnie naprawiania
2. DMS dla baz >50 GB lub zero-downtime wymagań — inwestycja się zwraca
3. Walidacja to nie opcja — to obowiązek
4. Monitoring od pierwszego dnia — Performance Insights, CloudWatch, preferowany Opensearch dla advanced analiz
5. Nie zostawiaj starego systemu — wyłącz po 2-4 tygodniach stabilnej pracy

Chcesz, żebym przeprowadził cię przez jeden z tych etapów bardziej szczegółowo? W Ciro Cloud pomagamy firmom migracyjne obciążenia bazodanowe bez przestojów — od audytu po wdrożenie i optymalizację kosztów.