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

Portal

Migrację można przeprowadzić za pomocą witryny Azure Portal.

Offline

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ąć:

1. Otwórz przeglądarkę internetową i przejdź do portalu. Aby się zalogować, wprowadź swoje poświadczenia. 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ą.

   

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

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

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

2. Po wybraniu pojedynczego serwera możesz obserwować baner związany z migracją na karcie Przegląd. Wybierz pozycję Migruj teraz , aby rozpocząć pracę.

   

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

   

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

Online (wersja zapoznawcza)

Wymagania wstępne (online)

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

Konfigurowanie parametrów migracji online

W przypadku migracji w trybie online obsługa replikacji powinna być ustawiona na Wartość Logiczna w ustawieniach replikacji źródłowego serwera PostgreSQL. Ponadto parametry max_wal_senders i max_replication_slots wartości serwera powinny być większe niż liczba baz danych, które należy zmigrować. Parametry można ustawić w witrynie Azure Portal w obszarze Ustawienia-Server> Parameters lub skonfigurować w wierszu polecenia przy użyciu następujących poleceń:

• ALTER SYSTEM SET wal_level = logical;
• ALTER SYSTEM SET max_wal_senders = number of databases to migrate + 1;
• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

Upewnij się, że nie ma długotrwałych transakcji. Długotrwałe transakcje nie zezwalają na tworzenie miejsc replikacji. Utworzenie miejsca replikacji powiedzie się, jeśli wszystkie długotrwałe transakcje zostaną zatwierdzone lub wycofane. Po wykonaniu wszystkich wymagań wstępnych migracji online należy ponownie uruchomić źródłowy serwer PostgreSQL.

Uwaga

W przypadku migracji online za pomocą pojedynczego serwera usługi Azure Database for PostgreSQL obsługa replikacji platformy Azure jest ustawiona na wartość logiczną w ustawieniach replikacji strony pojedynczego serwera w witrynie Azure Portal.

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.

• Parametr max_replication_slots serwera powinien być większy niż liczba baz danych, które należy zmigrować. Można go ustawić w witrynie Azure Portal w obszarze Ustawienia-Server> Parameters lub skonfigurować w wierszu polecenia przy użyciu następującego polecenia:

• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

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.

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ąć:

1. Otwórz przeglądarkę internetową i przejdź do portalu. Aby się zalogować, wprowadź swoje poświadczenia. 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ą.

   

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

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

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

2. Po wybraniu pojedynczego serwera możesz obserwować baner związany z migracją na karcie Przegląd. Wybierz pozycję Migruj teraz , aby rozpocząć pracę.

   

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

   

4. 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 migracji przy użyciu witryny Azure Portal

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 .

Migracja jednorazowa

W przypadku migracji i weryfikacji i migracji ukończenie migracji online wymaga innego kroku — wymagana jest akcja migracji jednorazowej od użytkownika. Po zakończeniu kopiowania/klonowania danych podstawowych migracja zostanie przeniesiona do WaitingForUserAction stanu i podłoża 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 (minutes) parametr to 0 lub blisko 0 Informacje Latency (minutes) można uzyskać z ekranu szczegółów migracji, jak pokazano poniżej:

Latency (minutes) parametr wskazuje, kiedy element docelowy ostatnio zsynchronizował się ze źródłem. Na przykład w przypadku powyższej bazy danych Zamówień jest to 0,33333. Oznacza to, że zmiany, które wystąpiły w ciągu ostatnich ~0,3 minut w źródle, nie zostały jeszcze zsynchronizowane z obiektem docelowym dla bazy danych Zamówień. W tym momencie operacje zapisu w źródle można zatrzymać i zainicjować migrację jednorazową. Jeśli w źródle występuje duży ruch, zaleca się najpierw zatrzymanie zapisów, aby Latency (minutes) 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 funkcji "Cutover" nawet z opóźnieniem niezerowym replikacja zostanie zatrzymana do tego momentu w czasie. Wszystkie dane 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 dane zmiany w ciągu ostatnich 15 minut są stosowane do celu. Czas potrzebny zależy od listy prac zmian, które wystąpiły w ciągu ostatnich 15 minut. W związku z tym zaleca się, aby opóźnienie przechodziło do zera lub w pobliżu zera przed wyzwoleniem migracji jednorazowej.

Migracja zostanie przeniesiona Succeeded do stanu, gdy tylko 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.

Możliwe stany migracji obejmują:

• InProgress: Trwa konfigurowanie infrastruktury migracji lub trwa rzeczywista migracja danych.
• Anulowano: migracja została anulowana lub usunięta.
• Niepowodzenie: 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.

Możliwe podstany migracji obejmują:

• PerformingPreRequisiteSteps: Konfiguracja infrastruktury jest w toku na potrzeby migracji danych.
• Walidacja w toku: Trwa walidacja.
• Migrowanie danych: trwa migracja danych.
• ZakończenieMigration: Migracja jest w ostatecznych etapach ukończenia.
• Ukończono: migracja została ukończona pomyślnie.

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.

Interfejs wiersza polecenia

Migrację można przeprowadzić przy użyciu interfejsu wiersza polecenia platformy Azure.

Offline

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.

Rozpocznij

1. Jeśli dopiero zaczynasz korzystać z platformy Microsoft Azure, utwórz konto, aby ocenić oferty.

2. Zainstaluj najnowszy interfejs wiersza polecenia platformy Azure dla systemu operacyjnego na stronie instalacji interfejsu wiersza polecenia platformy Azure.

   Jeśli interfejs wiersza polecenia platformy Azure jest już zainstalowany, sprawdź wersję przy użyciu az version polecenia . Wersja powinna mieć wartość 2.50.0 lub nowszą, aby używać poleceń interfejsu wiersza polecenia migracji. Jeśli nie, zaktualizuj wersję interfejsu wiersza polecenia platformy Azure.

3. az login Uruchom polecenie:

   az login
   

   Zostanie otwarte okno przeglądarki ze stroną logowania platformy Azure. Podaj poświadczenia platformy Azure w celu pomyślnego uwierzytelnienia. Aby uzyskać inne sposoby podpisywania przy użyciu interfejsu wiersza polecenia platformy Azure, zapoznaj się z tym artykułem.

Polecenia interfejsu wiersza polecenia migracji (offline)

Usługa migracji zawiera łatwe w użyciu polecenia interfejsu wiersza polecenia do wykonywania zadań związanych z migracją. Wszystkie polecenia interfejsu wiersza polecenia zaczynają się od az postgres flexible-server migration. Przed zainicjowaniem migracji ważne jest, aby umożliwić dodawanie rozszerzeń do listy dozwolonych.

Aby uzyskać pomoc dotyczącą opcji skojarzonych z poleceniem i tworzenia odpowiedniej składni, możesz użyć parametru help :

az postgres flexible-server migration --help

Powyższe polecenie udostępnia następujące dane wyjściowe:

Dane wyjściowe zawierają listę obsługiwanych poleceń migracji wraz z akcjami. Przyjrzyjmy się szczegółowo tym poleceniom.

Tworzenie migracji przy użyciu interfejsu wiersza polecenia platformy Azure

Polecenie create pomaga w tworzeniu migracji z serwera źródłowego do serwera docelowego:

az postgres flexible-server migration create -- help

Powyższe polecenie daje następujący wynik:

Wyświetla listę oczekiwanych argumentów i ma przykładową składnię umożliwiającą pomyślne utworzenie migracji z serwera źródłowego do serwera docelowego. Oto polecenie interfejsu wiersza polecenia, aby utworzyć nową migrację:

az postgres flexible-server migration create [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--migration-name]
                                            [--migration-mode]
                                            [--properties]

Parametr	Opis
subscription	Identyfikator subskrypcji docelowego serwera elastycznego.
resource-group	Grupa zasobów docelowego serwera elastycznego.
name	Nazwa docelowego serwera elastycznego.
migration-name	Unikatowy identyfikator migracji podjęto próbę nawiązania pracy z serwerem elastycznym. To pole akceptuje tylko znaki alfanumeryczne i nie akceptuje żadnych znaków specjalnych, z wyjątkiem łącznika (-). Nazwa nie może rozpoczynać się od -, a żadne dwie migracje do obiektu docelowego serwera elastycznego nie mogą mieć takiej samej nazwy.
migration-mode	Jest to opcjonalny parametr. Wartość domyślna: Offline. Migracja w trybie offline obejmuje kopiowanie źródłowych baz danych w danym momencie na serwer docelowy.
properties	Ścieżka bezwzględna do pliku JSON zawierającego informacje o źródle pojedynczego serwera.

Na przykład:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "C:\Users\Administrator\Documents\migrationBody.JSON" --migration-mode offline

migration-name Argument używany w poleceniu jest używany w innych poleceniach interfejsu create wiersza polecenia, takich jak update, deletei show. jednoznacznie identyfikuje próbę migracji w odpowiednich akcjach we wszystkich tych poleceniach.

create Na koniec polecenie wymaga przekazania pliku JSON jako części argumentuproperties.

Struktura kodu JSON to:

{
"properties": {
 "sourceDbServerResourceId":"/subscriptions/<subscriptionid>/resourceGroups/<src_ rg_name>/providers/Microsoft.DBforPostgreSQL/servers/<source server name>",
"secretParameters": {
    "adminCredentials":
    {
      "sourceServerPassword": "<password>",
      "targetServerPassword": "<password>"
    },
   "sourceServerUserName": "<username>@<servername>",
   "targetServerUserName": "<username>"
},

"dbsToMigrate":
   [
   "<db1>","<db2>"
   ],

"overwriteDbsInTarget":"true"

}
}

Parametry create , które przechodzą do formatu pliku JSON, są jak pokazano poniżej:

Parametr	Type	Opis
sourceDbServerResourceId	Wymagania	Ten parametr jest identyfikatorem zasobu źródła pojedynczego serwera i jest obowiązkowy.
adminCredentials	Wymagania	Ten parametr zawiera listę haseł dla użytkowników administracyjnych zarówno dla źródła pojedynczego serwera, jak i obiektu docelowego serwera elastycznego. Te hasła pomagają uwierzytelniać się na serwerach źródłowych i docelowych.
sourceServerUserName	Wymagania	Wartość domyślna to użytkownik administracyjny utworzony podczas tworzenia pojedynczego serwera, a podane hasło jest używane do uwierzytelniania względem tego użytkownika. Jeśli nie używasz domyślnego użytkownika, ten parametr jest użytkownikiem lub rolą na serwerze źródłowym do przeprowadzenia migracji. Ten użytkownik powinien mieć niezbędne uprawnienia i własność obiektów bazy danych zaangażowanych w migrację i powinien być członkiem roli azure_pg_admin .
targetServerUserName	Wymagania	Wartość domyślna to użytkownik administracyjny utworzony podczas tworzenia serwera elastycznego, a podane hasło jest używane do uwierzytelniania względem tego użytkownika. Jeśli nie używasz domyślnego użytkownika, ten parametr jest użytkownikiem lub rolą na serwerze docelowym używanym do przeprowadzania migracji. Ten użytkownik powinien być członkiem azure_pg_admin, pg_read_all_settings, pg_read_all_stats,pg_stat_scan_tables ról i powinien mieć rolę Tworzenie, Tworzenie atrybutów bazy danych.
dbsToMigrate	Wymagania	Określ listę baz danych, które mają zostać zmigrowane do serwera elastycznego. Migrowane są tylko bazy danych użytkowników. Systemowe bazy danych lub bazy danych szablonów, takie jak template0 i template1, nie zostaną zmigrowane.
overwriteDbsInTarget	Wymagania	W przypadku ustawienia wartości true, jeśli serwer docelowy ma istniejącą bazę danych o takiej samej nazwie jak ta, którą próbujesz przeprowadzić migrację, usługa migracji automatycznie zastępuje bazę danych.
SetupLogicalReplicationOnSourceDBIfNeeded	Opcjonalnie	Możesz automatycznie włączyć replikację logiczną na serwerze źródłowym, ustawiając tę właściwość na wartość true. Ta zmiana ustawień serwera wymaga ponownego uruchomienia serwera z dwóch do trzech minut przestoju.
SourceDBServerFullyQualifiedDomainName	Opcjonalnie	Użyj go, gdy niestandardowy serwer DNS jest używany do rozpoznawania nazw dla sieci wirtualnej. Podaj nazwę FQDN źródła pojedynczego serwera zgodnie z niestandardową nazwą serwera DNS dla tej właściwości.
TargetDBServerFullyQualifiedDomainName	Opcjonalnie	Użyj go, gdy niestandardowy serwer DNS jest używany do rozpoznawania nazw w sieci wirtualnej. Podaj nazwę FQDN obiektu docelowego serwera elastycznego zgodnie z niestandardowym serwerem DNS. SourceDBServerFullyQualifiedDomainName i TargetDBServerFullyQualifiedDomainName są uwzględniane jako część kodu JSON tylko w rzadkim scenariuszu, że niestandardowy serwer DNS jest używany do rozpoznawania nazw zamiast systemu DNS udostępnianego przez platformę Azure. W przeciwnym razie nie uwzględnij tych parametrów w pliku JSON.

Zwróć uwagę na następujące istotne kwestie dla odpowiedzi polecenia:

• create Gdy polecenie zostanie wyzwolone, migracja zostanie przeniesiona do InProgress stanu i podłożaPerformingPreRequisiteSteps. Przepływ pracy migracji trwa kilka minut, aby wdrożyć infrastrukturę migracji i skonfigurować połączenia między źródłem a obiektem docelowym.
• Po zakończeniu podstanu PerformingPreRequisiteSteps migracja zostanie przeniesiona na podłoże Migrating Data, , w którym odbywa się klonowanie/kopiowanie baz danych.
• Każda zmigrowana baza danych ma własną sekcję ze wszystkimi szczegółami migracji, takimi jak liczba tabel, przyrostowe wstawki, usunięcia i oczekujące bajty.
• Czas zakończenia podstanu Migrating Data zależy od rozmiaru migrowanych baz danych.
• Migracja zostanie przeniesiona do stanu zaraz po pomyślnym zakończeniu Succeeded podstanu Migrating Data . Jeśli występuje problem w podstanie Migrating Data , migracja zostanie przeniesiona Failed do stanu.

Konfigurowanie replikacji

Jeśli jest wybrana wersja zapoznawcza migracji online, replikacja logiczna musi być włączona na źródłowym pojedynczym serwerze. Jeśli nie jest włączona, usługa migracji automatycznie włącza replikację logiczną na źródłowym pojedynczym serwerze, gdy SetupLogicalReplicationOnSourceDBIfNeeded parametr jest przekazywany z wartością true w towarzyszącym pliku JSON. Replikację można również skonfigurować ręcznie w źródle po rozpoczęciu migracji przy użyciu poniższego polecenia. Jedno podejście do włączania replikacji logicznej powoduje ponowne uruchomienie źródłowego pojedynczego serwera.

Na przykład:

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name CLIMigrationExample --setup-replication

To polecenie jest wymagane do przeprowadzenia migracji, gdy serwer elastyczny czeka w WaitingForLogicalReplicationSetupRequestOnSourceDB stanie.

Aby przeprowadzić migrację online w dowolnym z powyższych regionów, użyj:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "C:\Users\Administrator\Documents\migrationBody.JSON" --migration-mode online

Wyświetlanie listy migracji

Polecenie list wyświetla listę wszystkich prób migracji do miejsca docelowego serwera elastycznego:

az postgres flexible-server migration list [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--filter]

Parametr filter ma dwie opcje:

• Active: wyświetla listę bieżących aktywnych prób migracji (w toku) na serwerze docelowym. Nie obejmuje ona migracji, które zakończyły się niepowodzeniem, anulowano lub powiodło się.
• All: wyświetla listę wszystkich prób migracji na serwer docelowy. Obejmuje to zarówno aktywne, jak i wcześniejsze migracje, niezależnie od stanu.

Aby uzyskać więcej informacji na temat tego polecenia, użyj parametru help :

az postgres flexible-server migration list -- help

Monitorowanie migracji

Polecenie show ułatwia monitorowanie bieżących migracji i zapewnia bieżący stan i podstan migracji. Te szczegóły obejmują informacje dotyczące bieżącego stanu i podstanu migracji.

az postgres flexible-server migration show [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--migration-name]

Parametr migration_name jest nazwą przypisaną do migracji podczas create wykonywania polecenia. Oto migawka przykładowej odpowiedzi z polecenia interfejsu wiersza polecenia przedstawiająca szczegóły:

Aby uzyskać więcej informacji na temat tego polecenia, użyj parametru help :

 az postgres flexible-server migration show -- help

W poniższych tabelach opisano stany i podstany migracji.

Stan migracji	opis
InProgress	Infrastruktura migracji jest skonfigurowana lub trwa rzeczywista migracja danych.
Canceled	Migracja zostanie anulowana lub usunięta.
Failed	Migracja nie powiodła się.
Succeeded	Migracja zakończyła się pomyślnie i została ukończona.

Podstan migracji	opis
PerformingPreRequisiteSteps	Infrastruktura jest skonfigurowana i jest wstępnie prepped na potrzeby migracji danych.
MigratingData	Migracja danych jest w toku.
CompletingMigration	Migracja jednorazowa jest w toku.
Completed	migracja jednorazowa zakończyła się pomyślnie, a migracja została ukończona.

Online (wersja zapoznawcza)

Wymagania wstępne (online)

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

Konfigurowanie parametrów migracji online

W przypadku migracji w trybie online obsługa replikacji powinna być ustawiona na Wartość Logiczna w ustawieniach replikacji źródłowego serwera PostgreSQL. Ponadto parametry max_wal_senders i max_replication_slots wartości serwera powinny być większe niż liczba baz danych, które należy zmigrować. Parametry można ustawić w witrynie Azure Portal w obszarze Ustawienia-Server> Parameters lub skonfigurować w wierszu polecenia przy użyciu następujących poleceń:

• ALTER SYSTEM SET wal_level = logical;
• ALTER SYSTEM SET max_wal_senders = number of databases to migrate + 1;
• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

Upewnij się, że nie ma długotrwałych transakcji. Długotrwałe transakcje nie zezwalają na tworzenie miejsc replikacji. Utworzenie miejsca replikacji powiedzie się, jeśli wszystkie długotrwałe transakcje zostaną zatwierdzone lub wycofane. Po wykonaniu wszystkich wymagań wstępnych migracji online należy ponownie uruchomić źródłowy serwer PostgreSQL.

Uwaga

W przypadku migracji online za pomocą pojedynczego serwera usługi Azure Database for PostgreSQL obsługa replikacji platformy Azure jest ustawiona na wartość logiczną w ustawieniach replikacji strony pojedynczego serwera w witrynie Azure Portal.

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.

• Parametr max_replication_slots serwera powinien być większy niż liczba baz danych, które należy zmigrować. Można go ustawić w witrynie Azure Portal w obszarze Ustawienia-Server> Parameters lub skonfigurować w wierszu polecenia przy użyciu następującego polecenia:

• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

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.

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.

Rozpocznij

1. Jeśli dopiero zaczynasz korzystać z platformy Microsoft Azure, utwórz konto, aby ocenić oferty.

2. Zainstaluj najnowszy interfejs wiersza polecenia platformy Azure dla systemu operacyjnego na stronie instalacji interfejsu wiersza polecenia platformy Azure.

   Jeśli interfejs wiersza polecenia platformy Azure jest już zainstalowany, sprawdź wersję przy użyciu az version polecenia . Wersja powinna mieć wartość 2.50.0 lub nowszą, aby używać poleceń interfejsu wiersza polecenia migracji. Jeśli nie, zaktualizuj wersję interfejsu wiersza polecenia platformy Azure.

3. az login Uruchom polecenie:

   az login
   

   Zostanie otwarte okno przeglądarki ze stroną logowania platformy Azure. Podaj poświadczenia platformy Azure w celu pomyślnego uwierzytelnienia. Aby uzyskać inne sposoby podpisywania przy użyciu interfejsu wiersza polecenia platformy Azure, zapoznaj się z tym artykułem.

Polecenia interfejsu wiersza polecenia migracji (online)

Usługa migracji zawiera łatwe w użyciu polecenia interfejsu wiersza polecenia do wykonywania zadań związanych z migracją. Wszystkie polecenia interfejsu wiersza polecenia zaczynają się od az postgres flexible-server migration. Przed zainicjowaniem migracji ważne jest, aby umożliwić dodawanie rozszerzeń do listy dozwolonych.

Aby uzyskać pomoc dotyczącą opcji skojarzonych z poleceniem i tworzenia odpowiedniej składni, możesz użyć parametru help :

az postgres flexible-server migration --help

Powyższe polecenie udostępnia następujące dane wyjściowe:

Dane wyjściowe zawierają listę obsługiwanych poleceń migracji wraz z akcjami. Przyjrzyjmy się szczegółowo tym poleceniom.

Tworzenie migracji przy użyciu interfejsu wiersza polecenia platformy Azure

Polecenie create pomaga w tworzeniu migracji z serwera źródłowego do serwera docelowego:

az postgres flexible-server migration create -- help

Powyższe polecenie daje następujący wynik:

Wyświetla listę oczekiwanych argumentów i ma przykładową składnię umożliwiającą pomyślne utworzenie migracji z serwera źródłowego do serwera docelowego. Oto polecenie interfejsu wiersza polecenia, aby utworzyć nową migrację:

az postgres flexible-server migration create [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--migration-name]
                                            [--migration-mode]
                                            [--properties]

Parametr	Opis
subscription	Identyfikator subskrypcji docelowego serwera elastycznego.
resource-group	Grupa zasobów docelowego serwera elastycznego.
name	Nazwa docelowego serwera elastycznego.
migration-name	Unikatowy identyfikator migracji podjęto próbę nawiązania pracy z serwerem elastycznym. To pole akceptuje tylko znaki alfanumeryczne i nie akceptuje żadnych znaków specjalnych, z wyjątkiem łącznika (-). Nazwa nie może rozpoczynać się od -, a żadne dwie migracje do obiektu docelowego serwera elastycznego nie mogą mieć takiej samej nazwy.
migration-mode	Jest to opcjonalny parametr. Wartość domyślna: Offline. Migracja w trybie offline obejmuje kopiowanie źródłowych baz danych w danym momencie na serwer docelowy.
properties	Ścieżka bezwzględna do pliku JSON zawierającego informacje o źródle pojedynczego serwera.

Na przykład:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "C:\Users\Administrator\Documents\migrationBody.JSON" --migration-mode offline

migration-name Argument używany w poleceniu jest używany w innych poleceniach interfejsu create wiersza polecenia, takich jak update, deletei show. jednoznacznie identyfikuje próbę migracji w odpowiednich akcjach we wszystkich tych poleceniach.

create Na koniec polecenie wymaga przekazania pliku JSON jako części argumentuproperties.

Struktura kodu JSON to:

{
"properties": {
 "sourceDbServerResourceId":"/subscriptions/<subscriptionid>/resourceGroups/<src_ rg_name>/providers/Microsoft.DBforPostgreSQL/servers/<source server name>",
"secretParameters": {
    "adminCredentials":
    {
      "sourceServerPassword": "<password>",
      "targetServerPassword": "<password>"
    },
   "sourceServerUserName": "<username>@<servername>",
   "targetServerUserName": "<username>"
},

"dbsToMigrate":
   [
   "<db1>","<db2>"
   ],

"overwriteDbsInTarget":"true"

}
}

Parametry create , które przechodzą do formatu pliku JSON, są jak pokazano poniżej:

Parametr	Type	Opis
sourceDbServerResourceId	Wymagania	Ten parametr jest identyfikatorem zasobu źródła pojedynczego serwera i jest obowiązkowy.
adminCredentials	Wymagania	Ten parametr zawiera listę haseł dla użytkowników administracyjnych zarówno dla źródła pojedynczego serwera, jak i obiektu docelowego serwera elastycznego. Te hasła pomagają uwierzytelniać się na serwerach źródłowych i docelowych.
sourceServerUserName	Wymagania	Wartość domyślna to użytkownik administracyjny utworzony podczas tworzenia pojedynczego serwera, a podane hasło jest używane do uwierzytelniania względem tego użytkownika. Jeśli nie używasz domyślnego użytkownika, ten parametr jest użytkownikiem lub rolą na serwerze źródłowym do przeprowadzenia migracji. Ten użytkownik powinien mieć niezbędne uprawnienia i własność obiektów bazy danych zaangażowanych w migrację i powinien być członkiem roli azure_pg_admin .
targetServerUserName	Wymagania	Wartość domyślna to użytkownik administracyjny utworzony podczas tworzenia serwera elastycznego, a podane hasło jest używane do uwierzytelniania względem tego użytkownika. Jeśli nie używasz domyślnego użytkownika, ten parametr jest użytkownikiem lub rolą na serwerze docelowym używanym do przeprowadzania migracji. Ten użytkownik powinien być członkiem azure_pg_admin, pg_read_all_settings, pg_read_all_stats,pg_stat_scan_tables ról i powinien mieć rolę Tworzenie, Tworzenie atrybutów bazy danych.
dbsToMigrate	Wymagania	Określ listę baz danych, które mają zostać zmigrowane do serwera elastycznego. Migrowane są tylko bazy danych użytkowników. Systemowe bazy danych lub bazy danych szablonów, takie jak template0 i template1, nie zostaną zmigrowane.
overwriteDbsInTarget	Wymagania	W przypadku ustawienia wartości true, jeśli serwer docelowy ma istniejącą bazę danych o takiej samej nazwie jak ta, którą próbujesz przeprowadzić migrację, usługa migracji automatycznie zastępuje bazę danych.
SetupLogicalReplicationOnSourceDBIfNeeded	Opcjonalnie	Możesz automatycznie włączyć replikację logiczną na serwerze źródłowym, ustawiając tę właściwość na wartość true. Ta zmiana ustawień serwera wymaga ponownego uruchomienia serwera z dwóch do trzech minut przestoju.
SourceDBServerFullyQualifiedDomainName	Opcjonalnie	Użyj go, gdy niestandardowy serwer DNS jest używany do rozpoznawania nazw dla sieci wirtualnej. Podaj nazwę FQDN źródła pojedynczego serwera zgodnie z niestandardową nazwą serwera DNS dla tej właściwości.
TargetDBServerFullyQualifiedDomainName	Opcjonalnie	Użyj go, gdy niestandardowy serwer DNS jest używany do rozpoznawania nazw w sieci wirtualnej. Podaj nazwę FQDN obiektu docelowego serwera elastycznego zgodnie z niestandardowym serwerem DNS. SourceDBServerFullyQualifiedDomainName i TargetDBServerFullyQualifiedDomainName są uwzględniane jako część kodu JSON tylko w rzadkim scenariuszu, że niestandardowy serwer DNS jest używany do rozpoznawania nazw zamiast systemu DNS udostępnianego przez platformę Azure. W przeciwnym razie nie uwzględnij tych parametrów w pliku JSON.

Zwróć uwagę na następujące istotne kwestie dla odpowiedzi polecenia:

• create Gdy polecenie zostanie wyzwolone, migracja zostanie przeniesiona do InProgress stanu i podłożaPerformingPreRequisiteSteps. Przepływ pracy migracji trwa kilka minut, aby wdrożyć infrastrukturę migracji i skonfigurować połączenia między źródłem a obiektem docelowym.
• Po zakończeniu podstanu PerformingPreRequisiteSteps migracja zostanie przeniesiona na podłoże Migrating Data, , w którym odbywa się klonowanie/kopiowanie baz danych.
• Każda zmigrowana baza danych ma własną sekcję ze wszystkimi szczegółami migracji, takimi jak liczba tabel, przyrostowe wstawki, usunięcia i oczekujące bajty.
• Czas zakończenia podstanu Migrating Data zależy od rozmiaru migrowanych baz danych.
• Migracja zostanie przeniesiona do stanu zaraz po pomyślnym zakończeniu Succeeded podstanu Migrating Data . Jeśli występuje problem w podstanie Migrating Data , migracja zostanie przeniesiona Failed do stanu.

Konfigurowanie replikacji

Jeśli jest wybrana wersja zapoznawcza migracji online, replikacja logiczna musi być włączona na źródłowym pojedynczym serwerze. Jeśli nie jest włączona, usługa migracji automatycznie włącza replikację logiczną na źródłowym pojedynczym serwerze, gdy SetupLogicalReplicationOnSourceDBIfNeeded parametr jest przekazywany z wartością true w towarzyszącym pliku JSON. Replikację można również skonfigurować ręcznie w źródle po rozpoczęciu migracji przy użyciu poniższego polecenia. Jedno podejście do włączania replikacji logicznej powoduje ponowne uruchomienie źródłowego pojedynczego serwera.

Na przykład:

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name CLIMigrationExample --setup-replication

To polecenie jest wymagane do przeprowadzenia migracji, gdy serwer elastyczny czeka w WaitingForLogicalReplicationSetupRequestOnSourceDB stanie.

Aby przeprowadzić migrację online w dowolnym z powyższych regionów, użyj:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "C:\Users\Administrator\Documents\migrationBody.JSON" --migration-mode online

Wyświetlanie listy migracji

Polecenie list wyświetla listę wszystkich prób migracji do miejsca docelowego serwera elastycznego:

az postgres flexible-server migration list [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--filter]

Parametr filter ma dwie opcje:

• Active: wyświetla listę bieżących aktywnych prób migracji (w toku) na serwerze docelowym. Nie obejmuje ona migracji, które zakończyły się niepowodzeniem, anulowano lub powiodło się.
• All: wyświetla listę wszystkich prób migracji na serwer docelowy. Obejmuje to zarówno aktywne, jak i wcześniejsze migracje, niezależnie od stanu.

Aby uzyskać więcej informacji na temat tego polecenia, użyj parametru help :

az postgres flexible-server migration list -- help

Monitorowanie migracji

Polecenie show ułatwia monitorowanie bieżących migracji i zapewnia bieżący stan i podstan migracji. Te szczegóły obejmują informacje dotyczące bieżącego stanu i podstanu migracji.

az postgres flexible-server migration show [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--migration-name]

Parametr migration_name jest nazwą przypisaną do migracji podczas create wykonywania polecenia. Oto migawka przykładowej odpowiedzi z polecenia interfejsu wiersza polecenia przedstawiająca szczegóły:

Aby uzyskać więcej informacji na temat tego polecenia, użyj parametru help :

 az postgres flexible-server migration show -- help

W poniższych tabelach opisano stany i podstany migracji.

Stan migracji	opis
InProgress	Infrastruktura migracji jest skonfigurowana lub trwa rzeczywista migracja danych.
Canceled	Migracja zostanie anulowana lub usunięta.
Failed	Migracja nie powiodła się.
Succeeded	Migracja zakończyła się pomyślnie i została ukończona.

Podstan migracji	opis
PerformingPreRequisiteSteps	Infrastruktura jest skonfigurowana i jest wstępnie prepped na potrzeby migracji danych.
MigratingData	Migracja danych jest w toku.
CompletingMigration	Migracja jednorazowa jest w toku.
Completed	migracja jednorazowa zakończyła się pomyślnie, a migracja została ukończona.

Migracja jednorazowa

W obszarze Migracje online po zakończeniu migracji danych podstawowych zadanie migracji zostanie przeniesione do WaitingForCutoverTrigger podstanu. W tym stanie użytkownik może wyzwolić migrację jednorazową za pomocą interfejsu wiersza polecenia przy użyciu poniższego polecenia. Migrację jednorazową można również wyzwolić z portalu, wybierając nazwę migracji w siatce migracji.

Na przykład:

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name CLIMigrationExample --cutover

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

• Operacje zapisu w źródle są zatrzymywane —latency parametr zmniejsza się do 0 lub blisko 0

latency parametr wskazuje, kiedy element docelowy ostatnio zsynchronizował się ze źródłem. Na przykład poniżej przedstawiono 201 i 202 dla dwóch baz danych, jak pokazano na poniższej ilustracji. Oznacza to, że zmiany, które wystąpiły w ciągu ostatnich ~200 sekund w źródle, nie zostały jeszcze zsynchronizowane z obiektem docelowym. W tym momencie operacje zapisu w źródle można zatrzymać i zainicjować migrację jednorazową. W przypadku dużego ruchu w źródle zaleca się zatrzymanie operacji zapisu, 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ę. Jeśli wyzwalasz "Cutover", nawet w przypadku braku zera Latency, replikacja zostanie zatrzymana do tego momentu w czasie. Wszystkie dane 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 dane zmiany w ciągu ostatnich 15 minut mają zastosowanie do celu. Czas potrzebny zależy od listy prac zmian, które wystąpiły w ciągu ostatnich 15 minut. W związku z tym zaleca się, aby opóźnienie przechodziło do zera lub w pobliżu zera przed wyzwoleniem migracji jednorazowej. Informacje latency można uzyskać za pomocą polecenia migration show. Oto migawka migracji przed zainicjowaniem migracji jednorazowej:

Po zainicjowaniu migracji jednorazowej wszystkie transakcje, które wystąpiły podczas kopiowania podstawowego, są kopiowane sekwencyjnie do obiektu docelowego, a migracja zostanie ukończona.

Jeśli migracja jednorazowa nie powiedzie się, migracja zostanie przeniesiona Failed do stanu.

Aby uzyskać więcej informacji na temat tego polecenia, użyj parametru help :

 az postgres flexible-server migration update -- help

Anulowanie migracji przy użyciu interfejsu wiersza polecenia

Możesz anulować wszelkie trwające próby migracji przy użyciu cancel polecenia . To polecenie zatrzymuje określoną próbę migracji i przywraca wszystkie zmiany na serwerze docelowym. Oto polecenie interfejsu wiersza polecenia umożliwiające usunięcie migracji:

az postgres flexible-server migration update cancel [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--migration-name]

Na przykład:

az postgres flexible-server migration update cancel --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1"

Aby uzyskać więcej informacji na temat tego polecenia, użyj parametru help :

 az postgres flexible-server migration update cancel -- help

Polecenie daje następujące dane wyjściowe:

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.

Powiązana zawartość

• Usługa migracji
• Migrowanie z usługi AWS RDS
• Najlepsze praktyki
• Znane problemy i ograniczenia
• Konfiguracja sieci
• Walidacje premigration