Samouczek: migrowanie online z usługi Google Cloud SQL for PostgreSQL do usługi Azure Database for PostgreSQL przy użyciu usługi migracji w wersji zapoznawczej
W tym artykule opisano sposób migrowania bazy danych PostgreSQL z usługi Google Cloud SQL for PostgreSQL do usługi Azure Database for PostgreSQL w trybie online.
Usługa migracji w usłudze Azure Database for PostgreSQL to w pełni zarządzana usługa zintegrowana z witryną Azure Portal i interfejsem wiersza polecenia platformy Azure. Została zaprojektowana tak, aby uprościć migrację do serwera usługi Azure Database for PostgreSQL.
- Wymagania wstępne
- Przeprowadzanie migracji
- Monitorowanie migracji
- Migracja jednorazowa
- Sprawdzanie migracji po zakończeniu
Wymagania wstępne
Do ukończenia migracji potrzebne są następujące wymagania wstępne:
Przed rozpoczęciem migracji z usługą migracji usługi Azure Database for PostgreSQL należy spełnić następujące wymagania wstępne, specjalnie zaprojektowane pod kątem scenariuszy migracji online.
- Weryfikowanie wersji źródłowej
- Instalowanie test_decoding — konfiguracja źródła
- Konfigurowanie konfiguracji docelowej
- Włączanie usługi CDC jako źródła
- Konfigurowanie konfiguracji sieci
- Włączanie rozszerzeń
- Sprawdzanie parametrów serwera
- Sprawdzanie użytkowników i ról
Weryfikowanie wersji źródłowej
Źródłowa wersja serwera PostgreSQL musi być w wersji 9.5 lub nowszej.
Jeśli źródłowa wersja bazy danych PostgreSQL jest mniejsza niż 9.5, przed rozpoczęciem migracji uaktualnij ją do wersji 9.5 lub nowszej.
Uwaga
Usługa migracji w usłudze Azure Database for PostgreSQL obsługuje połączenia przy użyciu adresu IP źródłowego usługi Google Cloud SQL for PostgreSQL. Format myproject:myregion:myinstance
nie jest obsługiwany.
Instalowanie test_decoding — konfiguracja źródła
- test_decoding odbiera plik WAL za pośrednictwem mechanizmu dekodowania logicznego i dekoduje go do reprezentacji tekstowych wykonywanych operacji.
- W usłudze Google Cloud SQL for PostgreSQL wtyczka test_decoding jest wstępnie zainstalowana i gotowa do replikacji logicznej. Dzięki temu można łatwo skonfigurować logiczne miejsca replikacji i przesyłać strumieniowo zmiany WAL, ułatwiając przypadki użycia, takie jak przechwytywanie zmian danych (CDC) lub replikacja do systemów zewnętrznych.
- Aby uzyskać więcej informacji na temat wtyczki dekodowania testowego, zobacz dokumentację bazy danych PostgreSQL
Konfigurowanie konfiguracji docelowej
- Przed migracją należy utworzyć serwer elastyczny usługi Azure Database for PostgreSQL.
- Jednostka SKU aprowizowana dla usługi Azure Database for PostgreSQL — serwer elastyczny powinien być zgodny ze źródłem.
- Aby utworzyć nową usługę Azure Database for PostgreSQL, odwiedź stronę Create an Azure Database for PostgreSQL (Tworzenie bazy danych Azure Database for PostgreSQL)
Włączanie usługi CDC jako źródła
test_decoding
wtyczka dekodowania logicznego przechwytuje zmienione rekordy ze źródła.- Aby upewnić się, że użytkownik migracji ma niezbędne uprawnienia replikacji, wykonaj następujące polecenie SQL:
Alter user <<username>> with REPLICATION;
Przejdź do wystąpienia Google Cloud SQL PostgreSQL w konsoli Google Cloud Console, kliknij nazwę wystąpienia, aby otworzyć stronę szczegółów, kliknij przycisk Edytuj, a następnie w sekcji Flagi zmodyfikuj następujące flagi:
- Ustaw flagę
cloudsql.logical_decoding = on
- Ustaw flagę
max_replication_slots
na wartość większą niż jedną. Wartość powinna być większa niż liczba baz danych wybranych do migracji. - Ustaw flagę
max_wal_senders
na wartość większą niż jedną. Powinna ona być co najmniej taka sama jakmax_replication_slots
, a także liczba nadawców, które były już używane w wystąpieniu. - Flaga
wal_sender_timeout
kończy nieaktywne połączenia replikacji dłużej niż określona liczba milisekund. Ustawienie wartości na 0 (zero) powoduje wyłączenie mechanizmu przekroczenia limitu czasu i jest prawidłowym ustawieniem migracji.
- Ustaw flagę
W docelowym serwerze elastycznym, aby zapobiec wyczerpaniu magazynu w trybie online w celu przechowywania dzienników, upewnij się, że masz wystarczającą ilość miejsca w przestrzeni tabel przy użyciu aprowizowanego dysku zarządzanego. Aby to osiągnąć, wyłącz parametr
azure.enable_temp_tablespaces_on_local_ssd
serwera przez czas trwania migracji i przywróć go do oryginalnego stanu po migracji.
Konfigurowanie konfiguracji sieci
Konfiguracja sieci ma kluczowe znaczenie dla usługi migracji do poprawnego działania. Upewnij się, że źródłowy serwer PostgreSQL może komunikować się z docelowym serwerem usługi Azure Database for PostgreSQL. Następujące konfiguracje sieci są niezbędne do pomyślnej migracji.
Aby uzyskać informacje na temat konfiguracji sieci, zobacz Przewodnik po sieci dla usługi migracji.
Włączanie rozszerzeń
Aby zapewnić pomyślną migrację przy użyciu usługi migracji w usłudze Azure Database for PostgreSQL, może być konieczne zweryfikowanie rozszerzeń w źródłowym wystąpieniu bazy danych PostgreSQL. Rozszerzenia udostępniają funkcje i funkcje, które mogą być wymagane dla aplikacji. Przed zainicjowaniem procesu migracji upewnij się, że rozszerzenia są weryfikowane w źródłowym wystąpieniu bazy danych PostgreSQL.
W docelowym wystąpieniu usługi Azure Database for PostgreSQL — serwer elastyczny włącz obsługiwane rozszerzenia, które są identyfikowane w źródłowym wystąpieniu bazy danych PostgreSQL.
Aby uzyskać więcej informacji, zobacz Rozszerzenia w usłudze Azure Database for PostgreSQL.
Uwaga
Ponowne uruchomienie jest wymagane po wprowadzeniu jakichkolwiek zmian w parametrze shared_preload_libraries
.
Sprawdzanie parametrów serwera
Te parametry nie są automatycznie migrowane do środowiska docelowego i muszą być skonfigurowane ręcznie.
Dopasuj wartości parametrów serwera ze źródłowej bazy danych PostgreSQL do usługi Azure Database for PostgreSQL, korzystając z sekcji "Parametry serwera" w witrynie Azure Portal i ręcznie aktualizując odpowiednio wartości.
Zapisz zmiany parametrów i uruchom ponownie usługę Azure Database for PostgreSQL, aby w razie potrzeby zastosować nową konfigurację.
Sprawdzanie użytkowników i ról
Podczas migracji do usługi Azure Database for PostgreSQL niezbędne jest oddzielne rozwiązanie migracji użytkowników i ról, ponieważ wymagają one interwencji ręcznej:
Ręczna migracja użytkowników i ról: użytkownicy i skojarzone z nimi role muszą zostać ręcznie zmigrowane do usługi Azure Database for PostgreSQL. Aby ułatwić ten proces, możesz użyć
pg_dumpall
narzędzia z flagą--globals-only
w celu wyeksportowania obiektów globalnych, takich jak role i konta użytkowników. Wykonaj następujące polecenie, zastępując<<username>>
ciąg rzeczywistą nazwą użytkownika i<<filename>>
żądaną nazwą pliku wyjściowego:pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql
Ograniczenie ról superużytkownika: usługa Azure Database for PostgreSQL nie obsługuje ról administratora. W związku z tym użytkownicy z uprawnieniami administratora muszą mieć te uprawnienia usunięte przed migracją. Upewnij się, że odpowiednio dostosujesz uprawnienia i role.
Wykonując te kroki, możesz upewnić się, że konta użytkowników i role są prawidłowo migrowane do usługi Azure Database for PostgreSQL bez napotykania problemów związanych z ograniczeniami administratora.
Wyłączanie wysokiej dostępności (niezawodności) i replik do odczytu w obiekcie docelowym
Wyłączenie wysokiej dostępności (niezawodności) i odczytywanie replik w środowisku docelowym jest niezbędne. Te funkcje powinny być włączone dopiero po zakończeniu migracji.
Postępując zgodnie z tymi wytycznymi, można zapewnić bezproblemowy proces migracji bez dodanych zmiennych wprowadzonych przez wysoką dostępność i repliki do odczytu. Po zakończeniu migracji i stabilnej bazie danych możesz włączyć te funkcje, aby zwiększyć dostępność i skalowalność środowiska bazy danych na platformie Azure.
Przeprowadzanie migracji
Migrację można przeprowadzić przy użyciu witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure.
Witryna Azure Portal oferuje proste i intuicyjne środowisko oparte na kreatorze, które przeprowadzi Cię przez migrację. Wykonując kroki opisane w tym samouczku, możesz bezproblemowo przenieść bazę danych do usługi Azure Database for PostgreSQL — serwer elastyczny i korzystać z zaawansowanych funkcji i skalowalności.
Aby przeprowadzić migrację za pomocą witryny Azure Portal, należy najpierw skonfigurować zadanie migracji, nawiązać połączenie ze źródłem i obiektem docelowym, a następnie przeprowadzić migrację.
Konfigurowanie zadania migracji
Usługa migracji zawiera proste środowisko oparte na kreatorze w witrynie Azure Portal. Oto jak rozpocząć:
Otwórz przeglądarkę internetową i przejdź do portalu. Wprowadź swoje poświadczenia, aby się zalogować. Widok domyślny to pulpit nawigacyjny usług.
Przejdź do docelowego serwera elastycznego usługi Azure Database for PostgreSQL.
Na karcie Przegląd serwera elastycznego w menu po lewej stronie przewiń w dół do pozycji Migracja i wybierz ją.
Wybierz przycisk Utwórz, aby przeprowadzić migrację z usługi Google Cloud SQL for PostgreSQL do usługi Azure Database for PostgreSQL — serwer elastyczny. Jeśli używasz usługi migracji po raz pierwszy, zostanie wyświetlona pusta siatka z monitem o rozpoczęcie pierwszej migracji.
Jeśli już utworzono migracje do obiektu docelowego usługi Azure Database for PostgreSQL, siatka zawiera informacje o próbach migracji.
Zaznacz przycisk Utwórz. Następnie przejdziesz przez serię kart opartych na kreatorze, aby utworzyć migrację do tego obiektu docelowego usługi Azure Database for PostgreSQL z wystąpienia źródłowego bazy danych PostgreSQL.
Ustawienia
Pierwsza karta to karta Konfiguracja , na której użytkownik musi podać szczegóły migracji, takie jak typ źródła nazwy migracji w celu zainicjowania migracji.
Nazwa migracji jest unikatowym identyfikatorem każdej migracji do tego docelowego serwera elastycznego. To pole akceptuje tylko znaki alfanumeryczne i nie akceptuje żadnych znaków specjalnych z wyjątkiem łącznika (-). Nazwa nie może zaczynać się od łącznika i powinna być unikatowa dla serwera docelowego. Brak dwóch migracji do tego samego obiektu docelowego serwera elastycznego może mieć taką samą nazwę.
Typ serwera źródłowego — w zależności od źródła postgreSQL można wybrać odpowiedni typ źródła, taki jak usługa PostgreSQL oparta na chmurze, konfiguracja lokalna lub maszyna wirtualna.
Opcja migracji umożliwia przeprowadzenie walidacji przed wyzwoleniem migracji. Możesz wybrać dowolną z następujących opcji:
- Weryfikacja — sprawdza gotowość serwera i bazy danych do migracji do miejsca docelowego.
- Migrowanie — pomija walidacje i uruchamia migracje.
- Weryfikowanie i migrowanie — przeprowadza walidację przed wyzwoleniem migracji. Migracja jest wyzwalana tylko wtedy, gdy nie ma żadnych błędów walidacji.
Wybranie opcji Weryfikuj lub Zweryfikuj i migrację jest zawsze dobrym rozwiązaniem podczas przeprowadzania weryfikacji premii przed uruchomieniem migracji. Aby dowiedzieć się więcej na temat weryfikacji premii, zapoznaj się z tą dokumentacją.
- Tryb migracji umożliwia wybranie trybu migracji. Tryb offline jest opcją domyślną.
Wybierz przycisk Dalej: Połącz się z przyciskiem Źródło .
Wybierz pozycję Serwer środowiska uruchomieniowego
Serwer środowiska uruchomieniowego migracji to wyspecjalizowana funkcja w ramach usługi migracji, przeznaczona do działania jako serwer pośredniczący podczas migracji. Jest to oddzielne wystąpienie usługi Azure Database for PostgreSQL — serwer elastyczny, które nie jest serwerem docelowym, ale służy do ułatwiania migracji baz danych ze środowiska źródłowego, które jest dostępne tylko za pośrednictwem sieci prywatnej.
Aby uzyskać więcej informacji na temat serwera środowiska uruchomieniowego, odwiedź serwer środowiska uruchomieniowego migracji.
Nawiązywanie połączenia ze źródłem
Na karcie Połącz ze źródłem zostanie wyświetlony monit o podanie szczegółów dotyczących źródła wybranego na karcie Konfiguracja, czyli źródła baz danych.
- Nazwa serwera — podaj nazwę hosta lub adres IP źródłowego wystąpienia bazy danych PostgreSQL
- Port — numer portu serwera źródłowego
- Nazwa logowania administratora serwera — nazwa użytkownika źródłowego serwera PostgreSQL
- Hasło — hasło źródłowego serwera PostgreSQL
- Tryb SSL — obsługiwane wartości są preferowane i wymagane. Gdy protokół SSL na źródłowym serwerze PostgreSQL jest wyłączony, użyj protokołu SSLMODE=preferuj. Jeśli protokół SSL na serwerze źródłowym jest włączony, użyj protokołu SSLMODE=require. Wartości SSL można określić w pliku Postgresql.conf.
- Testuj połączenie — wykonuje test łączności między miejscem docelowym a źródłem. Po pomyślnym nawiązaniu połączenia użytkownicy mogą przejść do następnego kroku. W przeciwnym razie musimy zidentyfikować problemy z siecią między elementem docelowym a źródłem i zweryfikować nazwę użytkownika/hasło źródła. Nawiązywanie połączenia testowego trwa kilka minut.
Po pomyślnym połączeniu testowym wybierz pozycję Dalej: wybierz docelowy migracji
Wybieranie miejsca docelowego migracji
Na karcie Wybierz miejsce docelowe migracji są wyświetlane metadane obiektu docelowego serwera elastycznego, takie jak nazwa subskrypcji, grupa zasobów, nazwa serwera, lokalizacja i wersja bazy danych PostgreSQL.
- Nazwa użytkownika administratora — nazwa użytkownika administratora docelowego serwera PostgreSQL
- Hasło — hasło docelowego serwera PostgreSQL
- Niestandardowa nazwa FQDN/adres IP (opcjonalnie): niestandardowe pole FQDN/IP jest opcjonalne i może być używane, gdy obiekt docelowy znajduje się za niestandardowym serwerem DNS lub ma niestandardowe przestrzenie nazw DNS, dzięki czemu jest dostępny tylko za pośrednictwem określonych nazw FQDN lub adresów IP. Na przykład może to obejmować wpisy, takie jak
flexibleserver.example.com
,198.1.0.2
lub nazwa FQDN postgreSQL, takie jakflexibleserver.postgres.database.azure.com
, jeśli niestandardowy serwer DNS zawiera strefępostgres.database.azure.com
DNS lub przekazuje zapytania dla tej strefy do168.63.129.16
, gdzie nazwa FQDN jest rozpoznawana w publicznej lub prywatnej strefie DNS platformy Azure. - Testuj połączenie — wykonuje test łączności między miejscem docelowym a źródłem. Po pomyślnym nawiązaniu połączenia użytkownicy mogą przejść do następnego kroku. W przeciwnym razie musimy zidentyfikować problemy z siecią między elementem docelowym a źródłem i zweryfikować nazwę użytkownika/hasło dla elementu docelowego. Połączenie testowe trwa kilka minut, aby nawiązać połączenie między obiektem docelowym a źródłem.
Po pomyślnym połączeniu testowym wybierz pozycję Dalej: Wybierz bazy danych do migracji
Wybieranie baz danych na potrzeby migracji
Na tej karcie lista baz danych użytkowników znajduje się na serwerze źródłowym wybranym na karcie konfiguracji. Możesz wybrać i zmigrować maksymalnie osiem baz danych w ramach pojedynczej próby migracji. Jeśli istnieje więcej niż osiem baz danych użytkowników, proces migracji jest powtarzany między serwerami źródłowymi i docelowymi dla następnego zestawu baz danych.
Po wybraniu baz danych wybierz pozycję Dalej: Podsumowanie
Podsumowanie
Karta Podsumowanie zawiera podsumowanie wszystkich szczegółów źródłowych i docelowych dotyczących tworzenia walidacji lub migracji. Przejrzyj szczegóły i wybierz przycisk Start.
Monitorowanie migracji
Po wybraniu przycisku uruchamiania zostanie wyświetlone powiadomienie w ciągu kilku sekund z informacją, że weryfikacja lub tworzenie migracji zakończy się pomyślnie. Następnie nastąpi automatyczne przekierowanie do strony Migracja serwera elastycznego, która zawiera nowy wpis dotyczący niedawno utworzonej weryfikacji lub migracji.
Siatka wyświetlającą migracje ma następujące kolumny: Nazwa, Stan, Tryb migracji, Typ migracji, Serwer źródłowy, Typ serwera źródłowego, Bazy danych, Czas trwania i Godzina rozpoczęcia. Wpisy są wyświetlane w kolejności malejącej godziny rozpoczęcia z najnowszym wpisem u góry. Możesz użyć przycisku odświeżania, aby odświeżyć stan weryfikacji lub migracji. Wybierz nazwę migracji w siatce, aby wyświetlić skojarzone szczegóły.
Po utworzeniu walidacji lub migracji następuje przejście do stanu InProgress i substratu PerformingPreRequisiteSteps . Skonfigurowanie infrastruktury migracji i połączeń sieciowych trwa od 2 do 3 minut.
Szczegóły migracji
Na karcie Konfiguracja wybraliśmy opcję migracji jako Migrowanie i Weryfikowanie. W tym scenariuszu walidacje są wykonywane najpierw przed rozpoczęciem migracji. Po zakończeniu podstanu PerformingPreRequisiteSteps przepływ pracy przechodzi do podstanu Walidacja w toku.
- Jeśli walidacja zawiera błędy, migracja zostanie przeniesiona do stanu Niepowodzenie.
- Jeśli walidacja zakończy się bez błędu, rozpoczyna się migracja, a przepływ pracy przechodzi do podstanu Migrowanie danych.
Wyniki walidacji i migracji można zobaczyć na poziomie wystąpienia i bazy danych.
Niektóre możliwe stany migracji:
Stany migracji
Stan | opis |
---|---|
Ruch przychodzący | Trwa konfigurowanie infrastruktury migracji lub trwa rzeczywista migracja danych. |
Anulowane | Migracja zostanie anulowana lub usunięta. |
Nie działa | Migracja nie powiodła się. |
Walidacja nie powiodła się | Walidacja nie powiodła się. |
Powodzenie | Migracja zakończyła się pomyślnie i została ukończona. |
OczekiwanieForUserAction | Dotyczy tylko migracji online. Oczekiwanie na wykonanie akcji jednorazowej przez użytkownika. |
Podstany migracji
Podstan | opis |
---|---|
PerformingPreRequisiteSteps | Trwa konfigurowanie infrastruktury na potrzeby migracji danych. |
Walidacja w toku | Walidacja jest w toku. |
Migrowanie danych | Migracja danych jest w toku. |
UkończenieMigration | Migracja jest na ostatnim etapie ukończenia. |
Zakończono | Migracja została ukończona. |
Nie działa | Migracja nie powiodła się. |
Podstany walidacji
Podstan | opis |
---|---|
Nie działa | Walidacja nie powiodła się. |
Powodzenie | Walidacja zakończyła się pomyślnie. |
Ostrzeżenie | Walidacja jest ostrzegawcza. |
Migracja jednorazowa
W przypadku migracji i weryfikacji i migracji ukończenie migracji online wymaga innego kroku — użytkownik musi wykonać akcję migracji jednorazowej. Po zakończeniu kopiowania/klonowania danych podstawowych migracja zostanie przeniesiona do WaitingForUserAction
stanu i podstanu WaitingForCutoverTrigger
. W tym stanie użytkownik może wyzwolić migrację jednorazową z portalu, wybierając migrację.
Przed zainicjowaniem migracji jednorazowej należy upewnić się, że:
Operacje zapisu w źródle są zatrzymywane —
Latency
wartość to 0 lub blisko 0. InformacjeLatency
można uzyskać na ekranie szczegółów migracji, jak pokazano poniżej:latency
wartość zmniejsza się do 0 lub zbliżonej do 0Wartość
latency
wskazuje, kiedy element docelowy został ostatnio zsynchronizowany ze źródłem. W tym momencie można zatrzymać zapisywanie w źródle i zainicjowanie migracji jednorazowej. Jeśli w źródle występuje duży ruch, zaleca się najpierw zatrzymanie zapisów, abyLatency
zbliżyć się do wartości 0, a następnie zainicjowano migrację jednorazową. Operacja cutover stosuje wszystkie oczekujące zmiany ze źródła do elementu docelowego i kończy migrację. W przypadku wyzwolenia operacji "Cutover" nawet w przypadku braku zeraLatency,
replikacja zostanie zatrzymana do tego momentu w czasie. Wszystkie dane są w źródle do momentu zastosowania punktu jednorazowego do obiektu docelowego. Załóżmy, że opóźnienie było 15 minut w punkcie migracji jednorazowej, więc wszystkie zmienione dane w ciągu ostatnich 15 minut są stosowane do celu. Czas zależy od listy prac zmian występujących w ciągu ostatnich 15 minut. W związku z tym zaleca się, aby opóźnienie przechodziło do zera lub zbliżonego do zera przed wyzwoleniem migracji jednorazowej.Migracja zostanie przeniesiona do
Succeeded
stanu, gdyMigrating Data
podstan lub migracja jednorazowa (w migracji online) zakończy się pomyślnie. Jeśli występuje problem w podstanieMigrating Data
, migracja zostanie przeniesionaFailed
do stanu.
Sprawdzanie migracji po zakończeniu
Po ukończeniu baz danych należy ręcznie zweryfikować dane między źródłem i obiektem docelowym i sprawdzić, czy wszystkie obiekty w docelowej bazie danych zostały pomyślnie utworzone.
Po migracji można wykonać następujące zadania:
- Sprawdź dane na serwerze elastycznym i upewnij się, że jest to dokładna kopia wystąpienia źródłowego.
- Po weryfikacji włącz opcję wysokiej dostępności na serwerze elastycznym zgodnie z potrzebami.
- Zmień jednostkę SKU serwera elastycznego, aby odpowiadała potrzebom aplikacji. Ta zmiana wymaga ponownego uruchomienia serwera bazy danych.
- Jeśli zmienisz jakiekolwiek parametry serwera z ich wartości domyślnych w wystąpieniu źródłowym, skopiuj te wartości parametrów serwera na serwerze elastycznym.
- Skopiuj inne ustawienia serwera, takie jak tagi, alerty i reguły zapory (jeśli dotyczy), z wystąpienia źródłowego do serwera elastycznego.
- Wprowadź zmiany w aplikacji, aby wskazać parametry połączenia serwerowi elastycznemu.
- Uważnie monitoruj wydajność bazy danych, aby sprawdzić, czy wymaga dostrajania wydajności.