Najlepsze rozwiązania dotyczące bezproblemowej migracji do serwera elastycznego Azure Database for PostgreSQL

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 przed migracją

W pierwszym kroku migracji uruchom walidację przed migracją przed przeprowadzeniem migracji. Możesz użyć opcji Weryfikuj i Weryfikuj i zmigruj 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. Uruchamiaj dalej weryfikację przed migracją, aż zakończy się stanem Powodzenie. Aby dowiedzieć się więcej, zobacz Weryfikacje przed migracją.

Docelowa konfiguracja serwera elastycznego

Podczas początkowego kopiowania danych bazowych w systemie docelowym wykonywanych jest wiele instrukcji INSERT, co generuje dzienniki wyprzedzającego zapisu (WAL). Dopóki te pliki WAL nie zostaną zarchiwizowane, dzienniki będą zajmować przestrzeń dyskową w lokalizacji docelowej oraz przestrzeń dyskową wymaganą 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, aby na serwerze elastycznym przydzielić wystarczającą ilość przestrzeni dyskowej, czyli o 25% więcej (1,25 raza tyle), niż jest obecnie używane według danych wyjściowych poprzedniego polecenia. Możesz również użyć funkcji Storage Autogrow.

Szybki start Tworzenie Elastycznego Serwera w usłudze Azure Database for PostgreSQL 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 czas trwania wynoszący siedem dni (168 godzin) od momentu rozpoczęcia i wygasa po siedmiu dniach z powodu przekroczenia limitu czasu. 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, utrzymuj ruch na niskim poziomie przez cały czas trwania 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 typu SKU serwera docelowego oraz liczby dostępnych operacji wejścia/wyjścia na sekundę (IOPS) 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 podejściem jest przeprowadzenie migracji testowej na własnym obciążeniu.

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

• Migracja z użyciem PITR: najlepszym sposobem na dokładne oszacowanie czasu potrzebnego na migrację produkcyjnego serwera bazy danych jest wykonanie odtworzenia do punktu w czasie (PITR) produkcyjnego serwera i przeprowadzenie migracji w trybie offline na tym nowo odtworzonym 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ć na ten sam dzień lub być może na termin za tydzień. 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 taka sama we wszystkich tabelach objętych migracją.

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

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

    Uwaga

    Porównawczy rozmiar baz danych nie jest właściwą metryki do weryfikacji. Instancja źródłowa może zawierać nadmiarowe dane lub martwe krotki, co może zwiększyć jej rozmiar. To normalne, że występują różnice w rozmiarze między instancjami źródłowymi a serwerami docelowymi. Problem w poprzednich trzech krokach weryfikacji wskazuje na problem z migracją.

• Migracja ustawień serwera: wszelkie parametry niestandardowe, 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 zadanie jest koordynowane z zespołem aplikacyjnym w celu zmiany wszystkich odwołań do ciągów połączenia wskazujących na instancję źródłową. Na serwerze elastycznym parametru użytkownika można użyć w formacie user=username w ciągu 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 o jednostce SKU Standard_D4ds_v4 (4 rdzenie, 16 GB pamięci).

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.

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

Zalecamy wydajny SKU dla serwera docelowego, ponieważ usługa migracji PostgreSQL działa w kontenerze 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 rozkład danych w źródle jest silnie skośny i większość danych znajduje się w jednej tabeli, zasoby obliczeniowe przydzielone do migracji muszą zostać w pełni wykorzystane, co tworzy 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 większych niż 20 GB. 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 smallintlub integerbig 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 kolumny unikatowego indeksu nie wpłynie na działanie aplikacji, należy przystąpić do wprowadzania zmian.

• Jeśli tabela nie ma prostego klucza podstawowego lub unikatowego indeksu typu smallintlub integerbig int ma 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 tabeli.

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

• Jeśli tabela nie ma klucza podstawowego smallintinteger lub big int unikatowego indeksu ani żadnej kolumny spełniającej kryteria typu danych, możesz dodać taką kolumnę przy użyciu funkcji ALTER i usunąć ją po migracji. Uruchomienie polecenia ALTER wymaga blokady na 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 rozmiar tabeli, aby sprawdzić, czy jest ona większa niż 20 GB.
• Jeśli rozmiar jest większy niż 20 GB i istnieje smallintinteger klucz podstawowy lub big int unikatowy indeks, 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 smallint, integer lub big int.
• Rozmiar tabeli jest większy niż 20 GB.
• Użyta jednostka SKU ma nieużywane rdzenie, które można wykorzystać do równoległej migracji tabeli.

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 rozrost może prowadzić do zwiększenia wymagań dotyczących pamięci masowej i spadku wydajności zapytań. Opróżnianie to kluczowe zadanie konserwacji, które pomaga odzyskać to zmarnowane miejsce i gwarantuje, że baza danych działa wydajnie. Odkurzanie pomaga rozwiązywać problemy, takie jak martwe wiersze i nadmierny rozrost tabeli, co zapewnia efektywne wykorzystanie przestrzeni dyskowej. Pomaga to również zapewnić szybszą migrację, ponieważ czas migracji jest funkcją rozmiaru bazy danych.

PostgreSQL udostępnia polecenie VACUUM, które pozwala odzyskać miejsce zajmowane przez martwe wiersze. Opcja ANALYZE zbiera również statystyki w celu dalszej optymalizacji planowania zapytań. W przypadku tabel z dużą intensywnością operacji zapisu proces VACUUM może działać bardziej agresywnie przez użycie VACUUM FULL, ale jego uruchomienie zajmuje więcej czasu.

• Standardowa próżnia

  VACUUM your_table;
  

• Odkurzaj 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 sprawnie odzyskuje miejsce, natomiast 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 z czasem mogą przyczyniać się do nadmiernego rozrostu bazy danych. 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 wykorzystuje pgcopydb follow i obowiązują w niej niektóre ograniczenia dekodowania logicznego. Zalecamy również posiadanie klucza podstawowego we wszystkich tabelach bazy danych, która jest poddawana migracji online. Jeśli brakuje klucza podstawowego, ten brak powoduje, że podczas migracji odzwierciedlane są tylko operacje insert, z wyłączeniem aktualizacji i usunięć. Przed kontynuowaniem migracji online dodaj tymczasowy klucz podstawowy do odpowiednich tabel.

Alternatywą jest użycie polecenia ALTER TABLE, w którym działanie ma wartość 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ę.

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