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. Na stronie konfiguracji migracji można użyć opcji Weryfikowanie i weryfikowanie i migrowanie . 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 . Wybierz pozycję Weryfikacje premigration, aby dowiedzieć się więcej.
Docelowa konfiguracja serwera elastycznego
Podczas początkowej podstawowej kopii danych wiele instrukcji insert jest wykonywanych na obiekcie docelowym, co generuje listy WALS (Write Ahead Logs). 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 wykonaj to polecenie dla wszystkich baz danych, które mają zostać zmigrowane:
SELECT pg_size_pretty( pg_database_size('dbname') );
Zaleca się 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 powyższego polecenia. Autogrow magazynu można również użyć.
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 serwera elastycznego usługi Azure Database for PostgreSQL przy użyciu portalu to doskonałe miejsce do rozpoczęcia. Opcje zasobów obliczeniowych i magazynu w usłudze Azure Database for PostgreSQL — serwer elastyczny zawierają również szczegółowe informacje o każdej konfiguracji serwera.
Oś czasu migracji
Każda migracja ma maksymalny okres istnienia siedmiu dni (168 godzin) po rozpoczęciu i upłynął limit czasu po siedmiu dniach. Migrację i migrację jednorazową aplikacji można ukończyć po zakończeniu weryfikacji danych i zakończeniu wszystkich testów, aby uniknąć przekraczania limitu czasu migracji. W obszarze Migracje 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 innych niż prod (deweloperskie, UAT, testowe, przejściowe) są migrowane przy użyciu migracji w trybie offline. Ponieważ te serwery mają mniej danych niż serwery produkcyjne, migracja kończy się szybko. 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. Biorąc pod uwagę wiele czynników, 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 byłoby wykonanie przywracania do punktu w czasie serwera produkcyjnego i uruchomienie migracji offline na tym nowo przywróconym serwerze.
Migracja buforu — po wykonaniu powyższego 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, możesz rozważyć 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.
Weryfikacja 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. Klienci mogą używać narzędzi open source/innych firm lub ręcznie przeprowadzić walidację. 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, indeksy)
Porównywanie maksymalnych lub minimalnych identyfikatorów kolumn związanych z aplikacją klucza
Uwaga
Rozmiar baz danych musi być odpowiednią metryą do weryfikacji. Wystąpienie źródłowe może mieć krotki z wzdętymi/martwymi krotkami, co może spowodować podbicie rozmiaru wystąpienia źródłowego. Zupełnie normalne jest, że istnieją różnice rozmiaru między wystąpieniami źródłowymi i serwerami docelowymi. Jeśli w pierwszych trzech krokach weryfikacji występuje problem, oznacza to problem z migracją.
Migracja ustawień serwera — wszystkie niestandardowe parametry serwera, reguły zapory (jeśli dotyczy), tagi i alerty muszą zostać ręcznie skopiowane 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
Podczas gdy migracja często jest uruchamiana bez problemu, dobrym rozwiązaniem jest zaplanowanie awaryjnych sytuacji, 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 baz danych o różnych rozmiarach przy użyciu usługi migracji. Migracja została przeprowadzona przy użyciu serwera elastycznego z jednostkami SKU — Standard_D4ds_v4 (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 |
Uwaga
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. Serwer elastyczny usługi Azure Database for PostgreSQL obsługuje skalowanie obliczeń i operacji we/wy na sekundę w pobliżu zera, 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
Zaawansowana jednostka SKU jest zalecana dla miejsca docelowego, 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 w przypadku, gdy dystrybucja danych między tabelami musi być bardziej zrównoważona i/lub bardziej zaawansowana jednostka SKU nie ma znaczącego wpływu na szybkość migracji.
Jeśli dystrybucja danych w źródle jest wysoce niesymetryczna, większość danych znajdujących się w jednej tabeli, przydzielone zasoby obliczeniowe na potrzeby migracji muszą być w pełni wykorzystywane i tworzy wąskie gardło. Dlatego dzielimy duże tabele na mniejsze fragmenty, które są następnie migrowane równolegle. Ta funkcja dotyczy tabel z ponad 100000000 (10 m) krotki. 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 znaczącym int.
Uwaga
W przypadku metod 2 lub 3 użytkownik musi dokładnie ocenić implikacje dodania unikatowej kolumny indeksu do schematu źródłowego. Dopiero po potwierdzeniu, że dodanie unikatowej kolumny indeksu nie wpłynie na aplikację, jeśli użytkownik przejdzie do przodu ze zmianami.
Jeśli tabela nie ma prostego klucza podstawowego ani unikatowego indeksu typu int lub znaczący int, ale ma kolumnę spełniającą kryteria typu danych, kolumna może zostać przekonwertowana na unikatowy indeks przy użyciu poniższego polecenia. To polecenie nie wymaga blokady w tabeli.
create unique index concurrently partkey_idx on <table name> (column name);Jeśli tabela nie ma prostego klucza podstawowego int/big int ani unikatowego indeksu lub dowolnej 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 w tabeli.
alter table <table name> add column <column name> big serial unique;
Jeśli którykolwiek z powyższych warunków jest spełniony, tabela jest migrowana równolegle w wielu partycjach, co powinno zapewnić wyraźny 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 100000000 (10 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 1000000000 (10 m), dzięki czemu różnica między minimalną i maksymalną wartością klucza podstawowego wynosi ponad 100000000 (10 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, zapewniając wydajne wykorzystanie magazynu. Co ważniejsze, pomaga to zapewnić szybszą migrację, ponieważ czas migracji jest funkcją rozmiaru bazy danych.
Usługa PostgreSQL udostępnia polecenie VACUUM w celu odzyskania magazynu zajmowanego przez martwe wiersze. Opcja ANALYZE zbiera również statystyki, dodatkowo optymalizując planowanie 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 wykonanie.
- Standardowa próżnia
VACUUM your_table;
- Opróżnij za pomocą funkcji Analizuj
VACUUM ANALYZE your_table;
- Agresywna próżnia dla tabel z dużym zapisem
VACUUM FULL your_table;
W tym przykładzie zastąp your_table rzeczywistą nazwą tabeli. Polecenie VACUUM bez pełnego odzyskuje przestrzeń wydajnie, a jednocześnie 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ą w miarę upływu czasu współtworzyć obiekt 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 uczniowie muszą wiedzieć przed kontynuowaniem pracy z samouczkiem lub modułem. Te warunki mogą obejmować określone wersje oprogramowania, wymagania sprzętowe lub dodatkowe 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. Ponadto zaleca się posiadanie klucza podstawowego we wszystkich tabelach bazy danych poddanej migracji online. Jeśli klucz podstawowy jest nieobecny, niedobór może spowodować, że podczas migracji zostaną odzwierciedlone tylko operacje wstawiania, z wyłączeniem aktualizacji lub usuwania. Dodaj tymczasowy klucz podstawowy do odpowiednich tabel przed kontynuowaniem migracji online.
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 obiekcie 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 postgres_fdw otoki danych obcych, 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ę.
- Tymczasowo usuń (odłączanie) zewnętrznej otoki danych w wystąpieniu źródłowym.
- Przeprowadź migrację danych reszty przy użyciu usługi Migration Service.
- Przywróć role otoki danych obcych, użytkownika i łącza 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 do serwera elastycznego aplikacja powinna być sprawdzana 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 takim przypadku można udzielić migration user uprawnień do zamknięcia wszystkich aktywnych połączeń z bazą danych lub ręcznie zamknąć połączenia przed ponowieniem próby migracji.