Samouczek: migrowanie z usługi Azure Database for PostgreSQL — pojedynczy serwer do usługi Azure Database for PostgreSQL — serwer elastyczny przy użyciu usługi migracji
DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny
Za pomocą witryny Azure Portal można migrować wystąpienie usługi Azure Database for PostgreSQL — pojedynczy serwer do usługi Azure Database for PostgreSQL — serwer elastyczny. W tym samouczku przeprowadzimy migrację przykładowej bazy danych z pojedynczego serwera usługi Azure Database for PostgreSQL do serwera elastycznego PostgreSQL przy użyciu witryny Azure Portal.
- Konfigurowanie serwera elastycznego usługi Azure Database for PostgreSQL
- Konfigurowanie zadania migracji
- Monitorowanie migracji
- Anulowanie migracji
- Po migracji
Migrację można przeprowadzić za pomocą witryny Azure Portal.
Wymagania wstępne (offline)
Przed rozpoczęciem migracji z usługą migracji w usłudze Azure Database for PostgreSQL należy spełnić następujące wymagania wstępne, które mają zastosowanie do scenariuszy migracji w trybie offline.
Weryfikowanie wersji źródłowej
Źródłowa wersja bazy danych PostgreSQL powinna mieć wartość >= 9.5
. Jeśli źródłowa wersja bazy danych PostgreSQL jest mniejsza niż 9.5
, uaktualnij źródłową wersję bazy danych PostgreSQL do 9.5
lub nowszej przed migracją.
Konfiguracja docelowa
Przed migracją należy skonfigurować usługę Azure Database for PostgreSQL na platformie Azure.
Jednostka SKU wybrana dla usługi Azure Database for PostgreSQL powinna odpowiadać specyfikacjom źródłowej bazy danych w celu zapewnienia zgodności i odpowiedniej wydajności.
Aby uzyskać szczegółowe instrukcje dotyczące tworzenia nowej usługi Azure Database for PostgreSQL, zapoznaj się z następującym linkiem: Szybki start: tworzenie serwera.
Konfiguracja sieci
Właściwa konfiguracja sieci jest niezbędna do zapewnienia pomyślnej łączności między źródłem i miejscem docelowym podczas migracji. Oto przewodnik ułatwiający nawiązanie połączenia sieciowego w różnych scenariuszach:
Wymagania dotyczące sieci na potrzeby migracji:
Tunelowanie sieci VPN/VPN protokołu ExpressRoute/IPsec: podczas łączenia lokalnego źródła/platformy AWS z platformą Azure może być konieczne skonfigurowanie tunelowania expressRoute, IPsec VPN lub VPN w celu ułatwienia bezpiecznego transferu danych.
Komunikacja równorzędna sieci wirtualnych: ustanów komunikację równorzędną sieci wirtualnych między dwiema odrębnymi sieciami wirtualnymi, aby umożliwić bezpośrednią łączność sieciową, a warunkiem wstępnym migracji między maszyną wirtualną platformy Azure a usługą Azure Database for PostgreSQL.
scenariusze Połączenie ivity:
Poniższa tabela może pomóc w skonfigurowaniu sieci między źródłem a obiektem docelowym.
Lokalizacja źródłowa | Target | Połączenie ivity Wskazówki |
---|---|---|
Publiczne | Publiczne | Nie jest wymagana żadna inna akcja, jeśli źródło znajduje się na liście dozwolonych w regułach zapory obiektu docelowego. |
Prywatne | Publiczne | Ta konfiguracja nie jest obsługiwana; użyj pg_dump/pg_restore do transferu danych. |
Publiczne | Prywatny | Nie jest wymagana żadna inna akcja, jeśli źródło znajduje się na liście dozwolonych w regułach zapory obiektu docelowego. |
Prywatne | Prywatne | Ustanów usługę ExpressRoute, sieć VPN IPsec, tunelowanie sieci VPN lub komunikację równorzędną sieci wirtualnych między źródłem a obiektem docelowym. |
Prywatne | Prywatny punkt końcowy | Ta konfiguracja nie jest obsługiwana; skontaktuj się z pomocą techniczną firmy Microsoft. |
Dodatkowe zagadnienia dotyczące sieci:
- pg_hba.conf Configuration: aby ułatwić łączność między źródłowymi i docelowymi wystąpieniami bazy danych PostgreSQL, należy zweryfikować i potencjalnie zmodyfikować plik pg_hba.conf. Ten plik zawiera uwierzytelnianie klienta i musi być skonfigurowany tak, aby umożliwić docelowej usłudze PostgreSQL nawiązywanie połączenia ze źródłem. Zmiany w pliku pg_hba.conf zwykle wymagają ponownego uruchomienia źródłowego wystąpienia postgreSQL.
Uwaga
Plik pg_hba.conf znajduje się w katalogu danych instalacji bazy danych PostgreSQL. Ten plik należy sprawdzić i skonfigurować, jeśli źródłowa baza danych jest lokalnym serwerem PostgreSQL lub serwerem PostgreSQL hostowanym na maszynie wirtualnej platformy Azure. W przypadku wystąpień postgreSQL w usługach AWS RDS lub podobnych usługach zarządzanych plik pg_hba.conf nie jest bezpośrednio dostępny lub ma zastosowanie. Zamiast tego dostęp jest kontrolowany za pośrednictwem zapewnianych przez usługę konfiguracji zabezpieczeń i dostępu do sieci.
Aby uzyskać więcej informacji na temat konfiguracji sieci, zobacz Przewodnik po sieci dla usługi migracji w usłudze Azure Database for PostgreSQL — serwer elastyczny.
Rozszerzenia
Rozszerzenia to dodatkowe funkcje, które można dodać do bazy danych PostgreSQL, aby zwiększyć jej funkcjonalność. Rozszerzenia są obsługiwane w usłudze Azure Database for PostgreSQL, ale muszą być włączone ręcznie. Aby włączyć rozszerzenia, wykonaj następujące kroki:
Użyj polecenia select w źródle, aby wyświetlić listę wszystkich używanych rozszerzeń —
select extname,extversion from pg_extension;
Wyszukaj parametr serwera azure.extensions na stronie Parametr serwera w usłudze Azure Database for PostgreSQL. Włącz rozszerzenia znalezione w źródle w usłudze PostgreSQL.
Zapisz zmiany parametrów i uruchom ponownie usługę Azure Database for PostgreSQL, aby w razie potrzeby zastosować nową konfigurację.
Sprawdź, czy lista zawiera dowolne z następujących rozszerzeń:
- PG_CRON
- PG_HINT_PLAN
- PG_PARTMAN_BGW
- PG_PREWARM
- PG_STAT_STATEMENTS
- PG_AUDIT
- PGLOGICAL
- WAL2JSON
Jeśli tak, wyszukaj stronę parametrów serwera dla parametru shared_preload_libraries. Ten parametr wskazuje zestaw bibliotek rozszerzeń, które są wstępnie ładowane podczas ponownego uruchamiania serwera.
Parametry 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ę.
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.
Konfigurowanie serwera elastycznego usługi Azure Database for PostgreSQL
Utwórz docelowy serwer elastyczny. Aby uzyskać instrukcje z przewodnikiem, zapoznaj się z przewodnikiem Szybki start Tworzenie elastycznego serwera usługi Azure Database for PostgreSQL przy użyciu portalu.
Rozszerzenia listy dozwolonych, których biblioteki muszą być ładowane na początku serwera. Ważne jest, aby rozszerzenie było na liście dozwolonych przed zainicjowaniem migracji.
Sprawdź, czy rozkład danych między tabelami bazy danych jest niesymetryczny, a większość danych znajduje się w jednej (lub kilku) tabelach. W przypadku niesymetryczności szybkość migracji może być wolniejsza niż oczekiwano. W takim przypadku szybkość migracji można zwiększyć, migrując dużą tabelę równolegle.
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. Aby się zalogować, wprowadź swoje poświadczenia. 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 rozpocząć migrację z pojedynczego serwera na 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 serwera elastycznego, siatka zawiera informacje o migracjach, które próbowano wykonać z pojedynczego serwera.
Wybierz przycisk Migruj z pojedynczego serwera . Przechodzisz przez serię kart opartych na kreatorze, aby utworzyć migrację do tego obiektu docelowego serwera elastycznego z dowolnego źródłowego pojedynczego serwera.
Alternatywnie możesz zainicjować proces migracji z pojedynczego serwera usługi Azure Database for PostgreSQL.
Otwórz przeglądarkę internetową i przejdź do portalu. Aby się zalogować, musisz wprowadzić swoje poświadczenia. Widok domyślny to pulpit nawigacyjny usług.
Po wybraniu pojedynczego serwera możesz obserwować baner związany z migracją na karcie Przegląd. Wybierz pozycję Migruj teraz , aby rozpocząć pracę.
Zostanie wyświetlona strona z dwiema opcjami. Jeśli serwer elastyczny został już utworzony i chcesz go użyć jako miejsca docelowego, wybierz pozycję Wybierz istniejącą, a następnie wybierz odpowiednie szczegóły subskrypcji, grupy zasobów i nazwy serwera. Po wybraniu opcji wybierz pozycję Przejdź do kreatora migracji i przejdź do instrukcji w sekcji Konfiguracja tej strony.
Jeśli wybierzesz opcję Utwórz nowy serwer elastyczny, wybierz pozycję Utwórz nowy i wybierz pozycję Przejdź do Kreatora tworzenia. Ta akcja powoduje przejście przez proces tworzenia serwera elastycznego i wdrożenie serwera elastycznego.
Po wdrożeniu serwera elastycznego wykonaj kroki od 3 do 5 w obszarze Konfigurowanie zadania migracji.
Karta Konfiguracja
Pierwszą kartą jest Konfiguracja. W przypadku, gdy pominięto to, wymagane rozszerzenia listy dozwolonych, jak pokazano w sekcji Ważne jest, aby zezwolić na listę tych rozszerzeń przed zainicjowaniem 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 wskazuje źródło. W tym przypadku jest to pojedynczy serwer usługi Azure Database for PostgreSQL
Opcja migracji umożliwia przeprowadzenie walidacji przed wyzwoleniem migracji. Możesz wybrać dowolną z poniższych 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.
Zawsze dobrym rozwiązaniem jest wybranie opcji Weryfikuj lub Zweryfikuj i migruj, aby przeprowadzić weryfikacje premii przed uruchomieniem migracji.
Jeśli jest wybrana wersja zapoznawcza migracji online, replikacja logiczna musi być włączona na źródłowym pojedynczym serwerze. Jeśli usługa migracji nie jest włączona, automatycznie włącza replikację logiczną na źródłowym pojedynczym serwerze. Replikację można również skonfigurować ręcznie na karcie Replikacja w okienku Po stronie pojedynczego serwera, ustawiając poziom obsługi replikacji platformy Azure na Wartość Logiczna. Jedno podejście powoduje ponowne uruchomienie pojedynczego serwera źródłowego.
Wybierz przycisk Dalej : Połączenie do źródła.
Karta Źródło
Karta Źródło wyświetla monit o podanie szczegółów związanych z pojedynczym serwerem, który jest źródłem baz danych.
Po wybraniu opcji Subskrypcja i Grupa zasobów lista rozwijana nazw serwerów zawiera pozycje Pojedyncze serwery w tej grupie zasobów w różnych regionach. Wybierz źródło, z którego chcesz przeprowadzić migrację baz danych. Bazy danych można migrować z pojedynczego serwera do docelowego serwera elastycznego w tym samym regionie. Migracje między regionami są włączone tylko dla serwerów Indie, Chiny i Zjednoczone Emiraty ZjednoczoneGo Emiratów.
Po wybraniu źródła pojedynczego serwera pola Lokalizacja, Wersja bazy danych PostgreSQL i Nazwa logowania administratora serwera zostaną wypełnione automatycznie. Nazwa logowania administratora serwera to nazwa użytkownika administratora używana do tworzenia pojedynczego serwera. W polu Hasło wprowadź hasło dla tego użytkownika administratora. Usługa migracji migruje pojedyncze bazy danych serwera jako administrator.
Po wypełnieniu wszystkich pól wybierz link Połączenie do źródła. Sprawdza, czy wprowadzone szczegóły serwera źródłowego są poprawne i czy serwer źródłowy jest osiągalny.
Wybierz przycisk Dalej: Wybierz docelowy obiekt migracji, aby kontynuować.
Karta celu
Na karcie Target (Cel ) są wyświetlane metadane obiektu docelowego serwera elastycznego, takie jak nazwa subskrypcji, grupa zasobów, nazwa serwera, lokalizacja i wersja bazy danych PostgreSQL.
W polu Nazwa logowania administratora serwera na karcie zostanie wyświetlona nazwa użytkownika administratora używana podczas tworzenia obiektu docelowego serwera elastycznego. Wprowadź odpowiednie hasło dla użytkownika administracyjnego. Po wypełnieniu hasła wybierz link Połączenie do celu. Sprawdza, czy wprowadzone szczegóły serwera docelowego są poprawne, a serwer docelowy jest osiągalny.
Wybierz przycisk Dalej, aby wybrać bazy danych do migracji.
Wybieranie pozycji Bazy danych na karcie migracji
Na tej karcie znajduje się lista baz danych użytkowników w obrębie pojedynczego serwera. 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. Domyślnie wybrane bazy danych o tej samej nazwie w obiekcie docelowym są zastępowane.
Wybierz przycisk Dalej, aby przejrzeć szczegóły.
Podsumowanie
Karta Podsumowanie zawiera podsumowanie wszystkich szczegółów dotyczących tworzenia weryfikacji lub migracji. Przejrzyj szczegóły i wybierz przycisk Start.
Monitorowanie portalu migracji
Po wybraniu przycisku uruchamiania zostanie wyświetlone powiadomienie w ciągu kilku sekund, aby stwierdzić, że weryfikacja lub tworzenie migracji zakończy się pomyślnie. Nastąpi automatyczne przekierowanie do strony Migracja serwera elastycznego. Ma to nowy wpis dla ostatnio utworzonej weryfikacji lub migracji.
Siatka wyświetlającą migracje ma następujące kolumny: Nazwa, Stan, Typ migracji, Tryb migracji, Serwer źródłowy, Typ serwera źródłowego, Bazy danych, Godzina rozpoczęcia i Czas trwania. Wpisy są wyświetlane w kolejności malejącej godziny rozpoczęcia od najnowszego wpisu u góry.
Możesz użyć przycisku odświeżania, aby odświeżyć stan weryfikacji lub migracji. Możesz również wybrać nazwę migracji w siatce, aby wyświetlić skojarzone szczegóły.
Po utworzeniu walidacji lub migracji następuje przejście do stanu InProgress i podstanu PerformingPreRequisiteSteps . Skonfigurowanie infrastruktury migracji i połączeń sieciowych trwa od 2 do 3 minut.
Przyjrzyjmy się, jak monitorować migracje dla każdej opcji migracji.
Sprawdź poprawność
Po zakończeniu podstanu PerformingPreRequisiteSteps walidacja zostanie przeniesiona do podstanu Walidacja w toku , gdzie kontrole są wykonywane na serwerze źródłowym i docelowym w celu oceny gotowości do migracji.
Walidacja zostanie przeniesiona do stanu Powodzenie, jeśli wszystkie walidacje są w stanie Powodzenie lub Ostrzeżenie.
Siatka sprawdzania poprawności ma
- Szczegóły weryfikacji dotyczące wystąpień i szczegółów weryfikacji dla sekcji baz danych reprezentujące reguły weryfikacji używane do sprawdzania gotowości migracji.
- Stan weryfikacji — reprezentuje wynik dla każdej reguły i może mieć dowolną z trzech wartości
- Powodzenie — jeśli nie znaleziono żadnych błędów.
- Niepowodzenie — jeśli występują błędy walidacji.
- Ostrzeżenie — jeśli istnieją ostrzeżenia dotyczące walidacji.
- Czas trwania — czas potrzebny na operację walidacji.
- Godzina rozpoczęcia i zakończenia — godzina rozpoczęcia i zakończenia operacji walidacji w formacie UTC.
Stan walidacji jest zmieniany na Stan niepowodzenie, jeśli w weryfikacji występują błędy. Wybierz nazwę weryfikacji lub walidację nazwy bazy danych, która zakończyła się niepowodzeniem, a okienko fan-out zawiera szczegóły i akcję naprawczą, którą należy podjąć, aby uniknąć tego błędu.
Migrate
Po zakończeniu migracji substratu PerformingPreRequisiteSteps migracja zostanie przeniesiona na podłoże migrowania danych podczas klonowania/kopiowania baz danych. Czas ukończenia migracji zależy od rozmiaru i kształtu migrujących baz danych. Migracja jest szybka, jeśli dane są w większości równomiernie dystrybuowane we wszystkich tabelach. Niesymetryczne rozmiary tabeli zajmują stosunkowo dłuższy czas.
Po wybraniu dowolnej bazy danych podczas migracji zostanie wyświetlone okienko fan-out. Zawiera ona całą liczbę tabel — skopiowaną, w kolejce, kopiując i błędy oprócz stanu migracji bazy danych.
Migracja zostanie przeniesiona do stanu Powodzenie po pomyślnym zakończeniu migracji danych . Jeśli występuje problem ze stanem Migrowanie danych , migracja zostanie przeniesiona do stanu Niepowodzenie .
Po przejściu migracji do stanu Powodzenie schemat i migracja danych z pojedynczego serwera do obiektu docelowego serwera elastycznego zostanie ukończona. Aby potwierdzić to samo, możesz użyć przycisku odświeżenia na stronie.
Weryfikowanie i migrowanie
W tej opcji 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 zostanie ukończona bez żadnego błędu, migracja zostanie uruchomiona, a przepływ pracy przejdzie do podstanu Migrowanie danych.
Po zakończeniu operacji można zobaczyć wyniki weryfikacji i migracji .
Anulowanie migracji przy użyciu portalu
Możesz anulować wszelkie trwające walidacje lub migracje. Aby anulować przepływ pracy, musi być w stanie InProgress . Nie można anulować walidacji ani migracji w stanie Powodzenie lub Niepowodzenie .
Anulowanie walidacji powoduje zatrzymanie wszelkich dalszych działań walidacji, a walidacja zostanie przeniesiona do stanu Anulowano . Anulowanie migracji powoduje zatrzymanie dalszego działania migracji na serwerze docelowym i przejście do stanu Anulowano . Akcja anulowania spowoduje wycofanie wszystkich zmian wprowadzonych przez usługę migracji na serwerze docelowym.
Po migracji
Po ukończeniu baz danych należy ręcznie zweryfikować dane między źródłem a 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.