Udostępnij za pośrednictwem

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 dla scenariuszy migracji online.

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ę Tworzenie serwera elastycznego usługi 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, wybierz nazwę wystąpienia, aby otworzyć stronę szczegółów, wybierz 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 jak max_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.

  • W docelowym Serwerze Elastycznym, aby zapobiec zużyciu przestrzeni dyskowej podczas migracji online, upewnij się, że masz wystarczającą ilość miejsca w przestrzeni tabel, korzystając z zarezerwowanego 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 zapewniają funkcjonalność i cechy, które mogą być wymagane dla Twojej aplikacji. Przed zainicjowaniem procesu migracji upewnij się, że zweryfikowano rozszerzenia w źródłowym wystąpieniu PostgreSQL.

W docelowej instancji elastycznego serwera Azure Database for PostgreSQL włącz obsługiwane rozszerzenia, które są wymienione w źródłowej instancji 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

  • Ograniczenia ról superużytkownika: usługa Azure Database for PostgreSQL nie obsługuje ról superużytkownika. 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 i replikacji odczytu 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ć płynny proces migracji, bez dodatkowych zmiennych związanych z HA (wysoką dostępnością) i replikami 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.

Portal Azure oferuje prosty i intuicyjny interfejs oparty na kreatorze, który poprowadzi Cię przez proces migracji. Wykonując kroki opisane w tym samouczku, możesz bezproblemowo przenieść bazę danych do serwera elastycznego usługi Azure Database for PostgreSQL i skorzystać 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ąć:

  1. Otwórz przeglądarkę internetową i przejdź do portalu. Wprowadź swoje poświadczenia, aby się zalogować. Widok domyślny to panel kontrolny serwisu.

  2. Przejdź do docelowego serwera elastycznego usługi Azure Database for PostgreSQL.

  3. Na karcie Przegląd serwera elastycznego w menu po lewej stronie przewiń w dół do pozycji Migracja i wybierz ją.

    Zrzut ekranu przedstawiający wybór migracji w witrynie Azure Portal z wyróżnioną opcją migracji dla bazy danych PostgreSQL.

  4. Wybierz przycisk Utwórz , aby przeprowadzić migrację z usługi Google Cloud SQL for PostgreSQL do serwera elastycznego usługi Azure Database for PostgreSQL. Jeśli używasz usługi migracji po raz pierwszy, zostanie wyświetlona pusta siatka z monitem o rozpoczęcie pierwszej migracji.

    Zrzut ekranu przedstawiający tworzenie migracji z portalu.

    Jeśli już utworzono migracje do obiektu docelowego usługi Azure Database for PostgreSQL, siatka zawiera informacje o próbach migracji.

  5. 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.

Zrzut ekranu przedstawiający kartę konfiguracji migracji w witrynie Azure portal.

  • 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. Dwie migracje do tego samego serwera elastycznego nie mogą mieć tej samej nazwy.

  • 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.
    • Walidacja i migrowanie — przeprowadza walidację przed inicjacją migracji. Migracja jest wyzwalana tylko wtedy, gdy nie ma żadnych błędów walidacji.

Wybranie opcji Weryfikuj lub Zweryfikuj i migruj jest zawsze dobrym rozwiązaniem podczas przeprowadzania weryfikacji premigracyjnych przed uruchomieniem migracji. Aby dowiedzieć się więcej na temat walidacji przed migracją, zapoznaj się z tą dokumentacją.

  • Tryb migracji umożliwia wybranie trybu migracji. Offline jest opcją domyślną.

Wybierz przycisk Dalej: Połącz się z przyciskiem Źródło .

Wybierz 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 serwera elastycznego usługi Azure Database for PostgreSQL, 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ź „Migration Runtime Server” .

Zrzut ekranu strony serwera środowiska uruchomieniowego migracji.

Nawiązywanie połączenia ze źródłem

Na karcie Połącz ze źródłem pojawi się monit o podanie szczegółów dotyczących źródła wybranego na karcie Konfiguracja, które jest źródłem baz danych.

Zrzut ekranu Connectsourcemigration.

  • 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 to 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.

Zrzut ekranu ekranu migracji celu połączenia.

  • 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 nazwę FQDN PostgreSQL, takie jak flexibleserver.postgres.database.azure.com, jeśli niestandardowy serwer DNS zawiera strefę DNS postgres.database.azure.com lub przekazuje zapytania dla tej strefy do 168.63.129.16, gdzie nazwa FQDN jest rozpoznawana w publicznej lub prywatnej strefie DNS 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. Testowanie połączenia trwa kilka minut, aby nawiązać połączenie między urządzeniem 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.

Zrzut ekranu przedstawiający pozycję FetchDBmigration z portalu.

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.

Zrzut ekranu przedstawiający migrację podsumowania z portalu.

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.

Zrzut ekranu przedstawiający monitorowanie migracji z portalu.

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 w trakcie walidacji.

  • 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.

Zrzut ekranu przedstawiający migrację szczegółów.

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.
OczekiwanieNaAkcjęUżytkownika Dotyczy tylko migracji online. Oczekiwanie na działanie użytkownika w celu przeprowadzenia przełączenia.

Podstany migracji

Podjednostka opis
Wykonywanie kroków wstępnych Trwa konfigurowanie infrastruktury na potrzeby migracji danych.
Walidacja w toku Walidacja jest w toku.
Migrowanie danych Migracja danych jest w toku.
UkończenieMigracji 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 znajduje się w stanie ostrzeżenia.

Migracja jednorazowa

Jeśli istnieją zarówno Migracja jak i Weryfikacja i Migracja, ukończenie migracji online wymaga kolejnego kroku — użytkownik musi wykonać akcję Cutover. Po zakończeniu kopiowania/klonowania danych podstawowych, migracja przechodzi do stanu WaitingForUserAction i podstanu WaitingForCutoverTrigger. W tym stanie użytkownik może zainicjować przełączenie na nowy system z portalu, wybierając migrację.

Przed zainicjowaniem migracji jednorazowej należy upewnić się, że:

  • Zapis do źródła jest zatrzymany — wartość Latency wynosi 0 lub jest bliska 0. Informacje Latency można uzyskać na ekranie szczegółów migracji, jak pokazano poniżej:

    Zrzut ekranu przedstawiający migrację migracji jednorazowej.

  • latency wartość zmniejsza się do 0 lub zbliżonej do 0

  • Wartość latency wskazuje, kiedy element docelowy został ostatnio zsynchronizowany ze źródłem. W tym momencie można zatrzymać pisanie do źródła i zainicjować przełączenie. Jeśli w źródle występuje duży ruch, zaleca się najpierw zatrzymanie zapisów, aby Latency zbliżyło się do wartości 0, a następnie zainicjować przełączenie. Operacja Cutover zastosuje wszystkie niezrealizowane zmiany ze źródła do celu i zakończy migrację. Jeśli wyzwolisz operację "Cutover" nawet jeśli Latency, nie jest zerowe, replikacja zostanie zatrzymana do tego momentu w czasie. Wszystkie dane są w źródle, dopóki punkt przełączenia nie zostanie zastosowany do celu. Załóżmy, że opóźnienie wynosiło 15 minut w momencie przełączenia, więc wszystkie zmienione dane z ostatnich 15 minut są zastosowane w celu. Czas zależy od zaległości zmian, które miały miejsce w ciągu ostatnich 15 minut. W związku z tym zaleca się, aby opóźnienie spadało do zera lub blisko zera przed wyzwoleniem przełączenia.

    Zrzut ekranu Confirmcutovermigration.

  • Migracja przechodzi do stanu Succeeded po pomyślnym zakończeniu podstanu Migrating Data lub migracji jednorazowej (w migracji online). Jeśli występuje problem w podstanie Migrating Data, migracja przechodzi do stanu Failed.

    Zrzut ekranu migracji Success.

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 skierować ciągi połączeń na elastyczny serwer.
  • Uważnie monitoruj wydajność bazy danych, aby sprawdzić, czy wymaga dostrajania wydajności.

Powiązana zawartość