Najlepsze rozwiązania dotyczące bezproblemowej migracji do usługi Azure Database for PostgreSQL

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

W tym artykule wyjaśniono typowe pułapki napotkane i najlepsze rozwiązania, aby zapewnić bezproblemową i pomyślną migrację do usługi Azure Database for PostgreSQL.

Weryfikacja premii

W pierwszym kroku migracji uruchom weryfikację premii przed przeprowadzeniem migracji. Możesz użyć opcji Weryfikowanie i weryfikowanie i migrowanie na stronie Konfiguracja migracji. Weryfikacja premigration przeprowadza dokładne kontrole względem wstępnie zdefiniowanego zestawu reguł. Celem jest zidentyfikowanie potencjalnych problemów i zapewnienie praktycznych szczegółowych informacji dotyczących działań zaradczych. Nie uruchamiaj weryfikacji premigration, dopóki nie zostanie uruchomiony stan Powodzenie . Aby dowiedzieć się więcej, zobacz Weryfikacje premigration.

Docelowa konfiguracja serwera elastycznego

Podczas początkowej podstawowej kopii danych wiele instrukcji insert jest wykonywanych w obiekcie docelowym, co generuje dzienniki z wyprzedzeniem zapisu (WALS). Dopóki te listy WAL nie zostaną zarchiwizowane, dzienniki zużywają magazyn w miejscu docelowym i magazyn wymagany przez bazę danych.

Aby obliczyć liczbę, zaloguj się do wystąpienia źródłowego i uruchom to polecenie dla wszystkich baz danych, które mają zostać zmigrowane:

SELECT pg_size_pretty( pg_database_size('dbname') );

Zalecamy przydzielenie wystarczającego magazynu na serwerze elastycznym, co odpowiada 1,25 razy lub 25% więcej miejsca do magazynowania niż to, co jest używane na dane wyjściowe poprzedniego polecenia. Możesz również użyć automatycznego zwiększania magazynu.

Ważne

Nie można zmniejszyć rozmiaru magazynu w konfiguracji ręcznej ani automatycznego zwiększania magazynu. Każdy krok w spektrum konfiguracji magazynu podwaja rozmiar, więc szacowanie wymaganego magazynu wcześniej jest rozsądne.

Przewodnik Szybki start dotyczący tworzenia wystąpienia usługi Azure Database for PostgreSQL — serwer elastyczny przy użyciu portalu to doskonałe miejsce do rozpoczęcia. Aby uzyskać więcej informacji na temat każdej konfiguracji serwera, zobacz Opcje obliczeń i magazynu w usłudze Azure Database for PostgreSQL — serwer elastyczny.

Oś czasu migracji

Każda migracja ma maksymalny okres istnienia siedmiu dni (168 godzin) po rozpoczęciu i jest przekroczony limit czasu po siedmiu dniach. Migrację i migrację jednorazową aplikacji można ukończyć po zakończeniu walidacji danych, a wszystkie testy zostaną ukończone, aby uniknąć migracji z limitu czasu. W przypadku migracji online po zakończeniu początkowej kopii podstawowej okno migracji jednorazowej trwa trzy dni (72 godziny) przed upływem limitu czasu. W przypadku migracji w trybie offline aplikacje powinny przestać zapisywać dane w bazie danych, aby zapobiec utracie danych. Podobnie w przypadku migracji online ruch jest niski w trakcie migracji.

Większość serwerów nieprodukcyjnych (deweloperskich, UAT, testowych i przejściowych) jest migrowana przy użyciu migracji w trybie offline. Ponieważ te serwery mają mniej danych niż serwery produkcyjne, migracja jest szybka. W przypadku migracji serwera produkcyjnego musisz znać czas potrzebny na ukończenie migracji w celu wcześniejszego zaplanowana migracji.

Czas potrzebny na ukończenie migracji zależy od kilku czynników. Obejmuje ona liczbę baz danych, rozmiar, liczbę tabel w każdej bazie danych, liczbę indeksów i rozkład danych między tabelami. Zależy to również od jednostki SKU serwera docelowego i liczby operacji we/wy na sekundę dostępnej dla wystąpienia źródłowego i serwera docelowego. Przy tak wielu czynnikach, które mogą mieć wpływ na czas migracji, trudno jest oszacować całkowity czas ukończenia migracji. Najlepszym rozwiązaniem jest przeprowadzenie migracji testowej z obciążeniem.

Następujące fazy są brane pod uwagę podczas obliczania całkowitego przestoju w celu przeprowadzenia migracji serwera produkcyjnego:

• Migracja punktu do punktu w czasie: najlepszym sposobem uzyskania dobrego oszacowania czasu migracji produkcyjnego serwera bazy danych jest wykonanie przywracania do punktu w czasie (PITR) serwera produkcyjnego i uruchomienie migracji offline na tym nowo przywróconym serwerze.

• Migracja buforu: po zakończeniu poprzedniego kroku można zaplanować rzeczywistą migrację produkcyjną w okresie, w którym ruch aplikacji jest niski. Tę migrację można zaplanować w tym samym dniu lub prawdopodobnie w tygodniu. W tym czasie rozmiar serwera źródłowego mógł zostać zwiększony. Zaktualizuj szacowany czas migracji dla serwera produkcyjnego na podstawie tego wzrostu. Jeśli wzrost jest znaczący, rozważ przeprowadzenie kolejnego testu przy użyciu serwera PITR. Jednak w przypadku większości serwerów zwiększenie rozmiaru nie powinno być wystarczająco znaczące.

• Walidacja danych: po zakończeniu migracji dla serwera produkcyjnego należy sprawdzić, czy dane na serwerze elastycznym są dokładną kopią wystąpienia źródłowego. Możesz użyć narzędzi typu open source lub innych firm albo przeprowadzić walidację ręcznie. Przygotuj kroki weryfikacji, które chcesz wykonać przed rzeczywistą migracją. Walidacja może obejmować:

  • Liczba wierszy jest zgodna ze wszystkimi tabelami zaangażowanymi w migrację.

  • Pasujące liczby dla wszystkich obiektów bazy danych (tabele, sekwencje, rozszerzenia, procedury i indeksy).

  • Porównywanie maksymalnych lub minimalnych identyfikatorów kolumn związanych z aplikacją kluczy.

    Uwaga

    Porównawczy rozmiar baz danych nie jest właściwą metryki do weryfikacji. Wystąpienie źródłowe może mieć wzdęcie lub martwe krotki, co może spowodować podbicie rozmiaru wystąpienia źródłowego. Zwykle różnice rozmiaru wystąpień źródłowych i serwerów docelowych są zwykle różne. Problem w poprzednich trzech krokach weryfikacji wskazuje na problem z migracją.

• Migracja ustawień serwera: wszystkie niestandardowe parametry serwera, reguły zapory (jeśli dotyczy), tagi i alerty muszą być ręcznie kopiowane z wystąpienia źródłowego do obiektu docelowego.

• Zmiana parametry połączenia: aplikacja powinna zmienić swoje parametry połączenia na serwer elastyczny po pomyślnej weryfikacji. To działanie jest koordynowane z zespołem aplikacji w celu zmiany wszystkich odwołań parametry połączenia wskazujących wystąpienie źródłowe. Na serwerze elastycznym parametr użytkownika może być używany w formacie user=username w parametry połączenia.

Na przykład: psql -h myflexserver.postgres.database.azure.com -u user1 -d db1.

Chociaż migracja często jest uruchamiana bez żadnych problemów, dobrym rozwiązaniem jest zaplanowanie awarii, jeśli do debugowania jest wymagany więcej czasu lub jeśli należy ponownie uruchomić migrację.

Testy porównawcze szybkości migracji

W poniższej tabeli przedstawiono czas potrzebny na przeprowadzenie migracji dla baz danych o różnych rozmiarach przy użyciu usługi migracji. Migracja została przeprowadzona przy użyciu serwera elastycznego z Standard_D4ds_v4 SKU (4 rdzenie, 16 GB pamięci, dysk 128 GB i 500 operacji we/wy na sekundę).

Rozmiar bazy danych	Przybliżony czas (HH:MM)
1 GB	00:01
5 GB	00:03
10 GB	00:08
50 GB	00:35
100 GB	01:00
500 GB	04:00
1000 GB	07:00

Powyższe liczby dają przybliżenie czasu potrzebnego do ukończenia migracji. Zdecydowanie zalecamy przeprowadzenie migracji testowej z obciążeniem, aby uzyskać dokładną wartość migracji serwera.

Ważne

Wybierz wyższą jednostkę SKU dla serwera elastycznego, aby wykonywać szybsze migracje. Azure Database for PostgreSQL — serwer elastyczny obsługuje niemal zerowe skalowanie zasobów obliczeniowych i operacji we/wy na sekundę, dzięki czemu jednostka SKU może zostać zaktualizowana z minimalnym przestojem. Zawsze można zmienić jednostkę SKU tak, aby odpowiadała potrzebom aplikacji po migracji.

Zwiększanie szybkości migracji: równoległa migracja tabel

Zalecamy zaawansowaną jednostkę SKU dla celu, ponieważ usługa migracji PostgreSQL kończy się kontenerem na serwerze elastycznym. Zaawansowana jednostka SKU umożliwia równoległe migrowanie większej liczby tabel. Jednostkę SKU można skalować z powrotem do preferowanej konfiguracji po migracji. Ta sekcja zawiera kroki poprawy szybkości migracji, jeśli dystrybucja danych między tabelami musi być bardziej zrównoważona lub bardziej zaawansowana jednostka SKU nie wpływa znacząco na szybkość migracji.

Jeśli dystrybucja danych w źródle jest wysoce niesymetryczna, z większością danych znajdujących się w jednej tabeli, przydzielone zasoby obliczeniowe na potrzeby migracji muszą być w pełni wykorzystywane, co powoduje wąskie gardło. Dlatego należy podzielić duże tabele na mniejsze fragmenty, które są następnie migrowane równolegle. Ta funkcja dotyczy tabel z ponad 1000 000 krotkami (1 m). Podzielenie tabeli na mniejsze fragmenty jest możliwe, jeśli zostanie spełniony jeden z następujących warunków:

• Tabela musi mieć kolumnę z prostym (nie złożonym) kluczem podstawowym lub unikatowym indeksem typu int lub significant int.

  Uwaga

  W przypadku pierwszego lub drugiego podejścia należy dokładnie ocenić implikacje dodawania unikatowej kolumny indeksu do schematu źródłowego. Dopiero po potwierdzeniu, że dodanie unikatowej kolumny indeksu nie wpłynie na aplikację, jeśli zostaną wprowadzone zmiany.

• Jeśli tabela nie ma prostego klucza podstawowego lub unikatowego indeksu typu int lub significant int zawiera kolumnę spełniającą kryteria typu danych, kolumna może zostać przekonwertowana na unikatowy indeks przy użyciu następującego polecenia. To polecenie nie wymaga blokady w tabeli.

      create unique index concurrently partkey_idx on <table name> (column name);
  

• Jeśli tabela nie ma klucza podstawowego ani unikatowego indeksu ani żadnej kolumny spełniającej simple int/big int kryteria typu danych, możesz dodać taką kolumnę przy użyciu funkcji ALTER i usunąć ją po migracji. ALTER Uruchomienie polecenia wymaga blokady w tabeli.

      alter table <table name> add column <column name> big serial unique;
  

Jeśli którykolwiek z powyższych warunków zostanie spełniony, tabela zostanie zmigrowana równolegle w wielu partycjach, co powinno zapewnić wzrost szybkości migracji.

Jak to działa

• Usługa migracji wyszukuje maksymalną i minimalną wartość całkowitą klucza podstawowego/unikatowego indeksu tabeli, która musi zostać podzielona i zmigrowana równolegle.
• Jeśli różnica między wartością minimalną a maksymalną wynosi ponad 1000 000 (1 m), tabela jest podzielona na wiele części, a każda część jest migrowana równolegle.

Podsumowując, usługa migracji PostgreSQL migruje tabelę w wątkach równoległych i skraca czas migracji, jeśli:

• Tabela zawiera kolumnę z prostym kluczem podstawowym lub unikatowym indeksem typu int lub znaczącym int.
• Tabela zawiera co najmniej 1000 000 wierszy (1 m), aby różnica między minimalną i maksymalną wartością klucza podstawowego przekraczała 1000 000 (1 m).
• Użyta jednostka SKU ma bezczynne rdzenie, których można użyć do migrowania tabeli równolegle.

Wzdęcie próżniowe w bazie danych PostgreSQL

Wraz z upływem czasu, gdy dane są dodawane, aktualizowane i usuwane, usługa PostgreSQL może gromadzić martwe wiersze i marnować miejsce do magazynowania. Ten przeloć może prowadzić do zwiększenia wymagań dotyczących magazynu i zmniejszenia wydajności zapytań. Opróżnianie to kluczowe zadanie konserwacji, które pomaga odzyskać to zmarnowane miejsce i gwarantuje, że baza danych działa wydajnie. Opróżnianie rozwiązuje problemy, takie jak martwe wiersze i wzdęcie tabeli w celu zapewnienia wydajnego korzystania z magazynu. Pomaga to również zapewnić szybszą migrację, ponieważ czas migracji jest funkcją rozmiaru bazy danych.

Usługa PostgreSQL udostępnia polecenie w celu odzyskania VACUUM magazynu zajmowanego przez martwe wiersze. Opcja ANALYZE zbiera również statystyki w celu dalszej optymalizacji planowania zapytań. W przypadku tabel z dużym obciążeniem zapisu VACUUM proces może być bardziej agresywny przy użyciu metody VACUUM FULL, ale wymaga więcej czasu na uruchomienie.

• Standardowa próżnia

  VACUUM your_table;
  

• Opróżnij z analizą

  VACUUM ANALYZE your_table;
  

• Agresywna próżnia dla dużych tabel zapisu

  VACUUM FULL your_table;
  

W tym przykładzie zastąp your_table rzeczywistą nazwą tabeli. Polecenie VACUUM bez FULL wydajnego odzyskiwania miejsca, podczas gdy VACUUM ANALYZE optymalizuje planowanie zapytań. Opcja VACUUM FULL powinna być używana rozsądnie ze względu na jej większy wpływ na wydajność.

Niektóre bazy danych przechowują duże obiekty, takie jak obrazy lub dokumenty, które mogą przyczynić się do wydmuchania bazy danych w czasie. Polecenie VACUUMLO jest przeznaczone dla dużych obiektów w usłudze PostgreSQL.

• Opróżnij duże obiekty

  VACUUMLO;
  

Regularne dołączanie tych strategii opróżniania zapewnia dobrze utrzymywaną bazę danych PostgreSQL.

Szczególna uwaga

Istnieją specjalne warunki, które zwykle odnoszą się do unikatowych okoliczności, konfiguracji lub wymagań wstępnych, o których należy pamiętać przed kontynuowaniem pracy z samouczkiem lub modułem. Te warunki mogą obejmować określone wersje oprogramowania, wymagania sprzętowe lub inne narzędzia niezbędne do pomyślnego ukończenia zawartości szkoleniowej.

Migracja w trybie online

Migracja online korzysta z bazy danych pgcopydb, a niektóre ograniczenia dekodowania logicznego mają zastosowanie. Zalecamy również posiadanie klucza podstawowego we wszystkich tabelach bazy danych, która jest poddawana migracji online. Jeśli klucz podstawowy jest nieobecny, niedobór powoduje, że podczas migracji zostaną odzwierciedlone tylko insert operacje, z wyłączeniem aktualizacji lub usunięcia. Przed kontynuowaniem migracji online dodaj tymczasowy klucz podstawowy do odpowiednich tabel.

Uwaga

W przypadku migracji online tabel bez klucza podstawowego tylko insert operacje są odtwarzane na obiekcie docelowym. Może to spowodować niespójność w bazie danych, jeśli rekordy zaktualizowane lub usunięte w źródle nie odzwierciedlają wartości docelowej.

Alternatywą jest użycie ALTER TABLE polecenia , w którym akcja to REPLICA IDENTIY z opcją FULL . Opcja FULL rejestruje stare wartości wszystkich kolumn w wierszu, tak aby nawet w przypadku braku klucza podstawowego wszystkie operacje CRUD zostały odzwierciedlone na miejscu docelowym podczas migracji online. Jeśli żadna z tych opcji nie działa, wykonaj migrację w trybie offline jako alternatywę.

Baza danych z rozszerzeniem postgres_fdw

Moduł postgres_fdw udostępnia obce postgres_fdw otoki danych, które mogą służyć do uzyskiwania dostępu do danych przechowywanych na zewnętrznych serwerach PostgreSQL. Jeśli baza danych używa tego rozszerzenia, należy wykonać następujące kroki, aby zapewnić pomyślną migrację.

1. Tymczasowo usuń (odłącz) obciętą otokę danych w wystąpieniu źródłowym.
2. Przeprowadź migrację danych reszty przy użyciu usługi migracji.
3. Przywróć obce role otoki danych, użytkownika i linki do obiektu docelowego po migracji.

Baza danych z rozszerzeniem postGIS

Rozszerzenie postGIS ma istotne zmiany/problemy z kompaktowaniem między różnymi wersjami. W przypadku migracji na serwer elastyczny aplikacja powinna zostać sprawdzona względem nowszej wersji postGIS, aby upewnić się, że aplikacja nie ma wpływu na aplikację lub czy należy wprowadzić niezbędne zmiany. Informacje o wiadomościach i wydaniach postGIS są dobrym punktem wyjścia do zrozumienia zmian powodujących niezgodność w różnych wersjach.

Oczyszczanie połączenia z bazą danych

Czasami ten błąd może wystąpić podczas uruchamiania migracji:

CL003:Target database cleanup failed in the pre-migration step. Reason: Unable to kill active connections on the target database created by other users. Please add the pg_signal_backend role to the migration user using the command 'GRANT pg_signal_backend to <migrationuser>' and try a new migration.

W tym scenariuszu migration user można przyznać uprawnienie do zamknięcia wszystkich aktywnych połączeń z bazą danych lub ręcznie zamknąć połączenia przed ponowieniem próby migracji.

Powiązana zawartość

• Usługa migracji
• Znane problemy i ograniczenia