Udostępnij za pośrednictwem

Samouczek: migrowanie online z usługi Amazon RDS for PostgreSQL do usługi Azure Database for PostgreSQL za pomocą usługi migracji w wersji zapoznawczej

  • Artykuł

W tym artykule opisano sposób migrowania bazy danych PostgreSQL z usługi Amazon RDS 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

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

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 Amazon RDS 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

Włączanie usługi CDC jako źródła

  • test_decoding wtyczka dekodowania logicznego przechwytuje zmienione rekordy ze źródła.
  • Aby zezwolić użytkownikowi migracji na dostęp do uprawnień replikacji, wykonaj następujące polecenie:
GRANT rds_replication TO <<username>>;

  • W źródle wystąpienie bazy danych PostgreSQL zmodyfikuj następujące parametry, tworząc nową grupę parametrów:

    • Zbiór rds.logical_replication = 1
    • Ustaw max_replication_slots wartość większą niż jedną. Wartość powinna być większa niż liczba baz danych wybranych do migracji.
    • Ustaw max_wal_senders 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.
    • Parametr wal_sender_timeout kończy nieaktywne połączenia replikacji dłuższe niż określona liczba milisekund. Domyślną wartością dla wystąpienia usługi AWS RDS dla bazy danych PostgreSQL jest 30000 milliseconds (30 seconds). 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 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ąć:

  1. Otwórz przeglądarkę internetową i przejdź do portalu. Wprowadź swoje poświadczenia, aby się zalogować. Widok domyślny to pulpit nawigacyjny usług.

  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 opcji Migracja.

  4. Wybierz przycisk Utwórz, aby przeprowadzić migrację z usługi Amazon RDS 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.

    Zrzut ekranu przedstawiający tworzenie migracji.

    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 migrację instalatora 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. 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.

Zrzut ekranu przedstawiający stronę 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.

Zrzut ekranu przedstawiający pozycję 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 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.

Zrzut ekranu przedstawiający ekran migracji docelowej 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.2lub nazwa FQDN postgreSQL, takie jak flexibleserver.postgres.database.azure.com, jeśli niestandardowy serwer DNS zawiera strefę postgres.database.azure.com DNS lub przekazuje zapytania dla tej strefy do 168.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.

Zrzut ekranu przedstawiający FetchDBmigration.

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.

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.

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.

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.
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. 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ć zapisywanie w źródle i zainicjowanie migracji jednorazowej. Jeśli w źródle występuje duży ruch, zaleca się najpierw zatrzymanie zapisów, aby Latency 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 zera Latency, 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.

    Zrzut ekranu przedstawiający polecenie Confirmcutovermigration.

  • Migracja zostanie przeniesiona do Succeeded stanu, gdy Migrating Data podstan lub migracja jednorazowa (w migracji online) zakończy się pomyślnie. Jeśli występuje problem w podstanie Migrating Data , migracja zostanie przeniesiona Failed do stanu.

    Zrzut ekranu przedstawiający migrację powodzenia.

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.

Powiązana zawartość