Udostępnij za pośrednictwem

Samouczek: migrowanie w trybie online z maszyny wirtualnej platformy Azure lub lokalnego serwera PostgreSQL do usługi Azure Database for PostgreSQL za pomocą usługi migracji w wersji zapoznawczej

  • Artykuł

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

Ten artykuł zawiera instrukcje dotyczące migrowania wystąpienia bazy danych PostgreSQL ze środowiska lokalnego lub maszyn wirtualnych platformy Azure do serwera elastycznego usługi Azure Database for PostgreSQL przy użyciu witryny Azure Portal i interfejsu wiersza polecenia platformy Azure.

Usługa migracji w usłudze Azure Database for PostgreSQL to w pełni zarządzana usługa zintegrowana z witryną Azure Portal i interfejsem wiersza polecenia platformy Azure. Została zaprojektowana tak, aby uprościć migrację do serwera elastycznego usługi Azure Database for PostgreSQL.

  • Konfigurowanie serwera elastycznego usługi Azure Database for PostgreSQL
  • Konfigurowanie zadania migracji
  • Monitorowanie migracji
  • Sprawdzanie migracji po zakończeniu

Wymagania wstępne

Do rozpoczęcia migracji potrzebne są następujące wymagania wstępne:

Przed rozpoczęciem migracji z usługą migracji usługi Azure Database for PostgreSQL należy spełnić następujące wymagania wstępne, specjalnie zaprojektowane pod kątem scenariuszy migracji online.

Weryfikowanie wersji źródłowej

Źródłowa wersja serwera PostgreSQL musi być w wersji 9.5 lub nowszej.

Jeśli źródłowa wersja bazy danych PostgreSQL jest mniejsza niż 9.5, przed rozpoczęciem migracji uaktualnij ją do wersji 9.5 lub nowszej.

Instalowanie test_decoding — konfiguracja źródła

  • test_decoding odbiera plik WAL za pośrednictwem mechanizmu dekodowania logicznego i dekoduje go do reprezentacji tekstowych wykonywanych operacji.

  • Aby uzyskać więcej informacji na temat wtyczki dekodowania testowego, zobacz dokumentację bazy danych PostgreSQL

Konfigurowanie konfiguracji docelowej

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

  • test_decoding wtyczka dekodowania logicznego przechwytuje zmienione rekordy ze źródła.
  • W źródłowym wystąpieniu bazy danych PostgreSQL ustaw następujące parametry i wartości w pliku konfiguracji postgresql.conf:
    • Set wal_level = logical
    • Set max_replication_slots do wartości większej niż 1 wartość powinna być większa niż liczba baz danych wybranych do migracji.
    • Set max_wal_senders wartość większa niż 1 powinna być ustawiona na co najmniej taką samą, jak max_replication_slots, oraz liczbę nadawców używanych już przez wystąpienie.
    • Parametr wal_sender_timeout kończy połączenia replikacji, które są nieaktywne dłużej niż określona liczba milisekund. Wartość domyślna dla lokalnej bazy danych PostgreSQL to 60000 milisekund (60 sekund). Ustawienie wartości na 0 (zero) powoduje wyłączenie mechanizmu przekroczenia limitu czasu i jest prawidłowym ustawieniem migracji.

Aby zapobiec wyczerpaniu miejsca na migracji online, upewnij się, że masz wystarczającą ilość miejsca w przestrzeni tabel przy użyciu aprowizowanego dysku zarządzanego. Aby to osiągnąć, wyłącz parametr azure.enable_temp_tablespaces_on_local_ssd serwera na serwerze elastycznym przez czas trwania migracji i przywróć go do oryginalnego stanu po migracji.

Konfigurowanie konfiguracji sieci

Konfiguracja sieci ma kluczowe znaczenie dla usługi migracji do poprawnego działania. Upewnij się, że źródłowy serwer PostgreSQL może komunikować się z docelowym serwerem usługi Azure Database for PostgreSQL. Następujące konfiguracje sieci są niezbędne do pomyślnej migracji.

Aby uzyskać informacje na temat konfiguracji sieci, zobacz Przewodnik po sieci dla usługi migracji.

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

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łączanie rozszerzeń

Aby zapewnić pomyślną migrację przy użyciu usługi migracji w usłudze Azure Database for PostgreSQL, może być konieczne zweryfikowanie rozszerzeń w źródłowym wystąpieniu bazy danych PostgreSQL. Rozszerzenia udostępniają funkcje i funkcje, które mogą być wymagane dla aplikacji. Przed zainicjowaniem procesu migracji upewnij się, że rozszerzenia są weryfikowane w źródłowym wystąpieniu bazy danych PostgreSQL.

W docelowym wystąpieniu usługi Azure Database for PostgreSQL — serwer elastyczny włącz obsługiwane rozszerzenia, które są identyfikowane w źródłowym wystąpieniu bazy danych PostgreSQL.

Aby uzyskać więcej informacji, zobacz Rozszerzenia w usłudze Azure Database for PostgreSQL.

Uwaga

Ponowne uruchomienie jest wymagane po wprowadzeniu jakichkolwiek zmian w parametrze shared_preload_libraries .

Sprawdzanie parametrów serwera

  • Należy ręcznie skonfigurować wartości parametrów serwera w usłudze Azure Database for PostgreSQL — serwer elastyczny na podstawie wartości parametrów serwera skonfigurowanych w źródle.

Sprawdzanie użytkowników i ról

  • Użytkownicy i różne role muszą być migrowane ręcznie do serwera elastycznego usługi Azure Database for PostgreSQL. W przypadku migrowania użytkowników i ról można użyć polecenia pg_dumpall --globals-only -U <<username> -f <<filename>>.sql.
  • Azure Database for PostgreSQL — serwer elastyczny nie obsługuje żadnego administratora; użytkownicy mający role superużytkownika muszą zostać usunięci przed migracją.

Przeprowadzanie migracji

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

Ten artykuł zawiera instrukcje dotyczące migrowania bazy danych PostgreSQL z maszyny wirtualnej platformy Azure lub lokalnego serwera PostgreSQL do usługi Azure Database for PostgreSQL. Witryna Azure Portal umożliwia wykonywanie różnych zadań, w tym migracji bazy danych. Wykonując kroki opisane w tym samouczku, możesz bezproblemowo przenieść bazę danych na platformę Azure i skorzystać z jej zaawansowanych funkcji i skalowalności.

Konfigurowanie zadania migracji

Usługa migracji zawiera proste środowisko oparte na kreatorze w witrynie Azure Portal. Oto jak rozpocząć:

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

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

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

    Zrzut ekranu przedstawiający stronę Wyboru migracji w witrynie Azure Portal.

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

    Zrzut ekranu przedstawiający tworzenie migracji.

    Jeśli już utworzono migracje do obiektu docelowego serwera elastycznego, siatka zawiera informacje o próbach migracji.

  5. Zaznacz przycisk Utwórz. Następnie przejdziesz przez serię kart opartych na kreatorze, aby utworzyć migrację do tego obiektu docelowego serwera elastycznego z serwera źródłowego PostgreSQL.

Ustawienia

Pierwsza karta to karta konfiguracji, na której użytkownik inicjuje migracje, podając szczegóły migracji, takie jak nazwa migracji i typ źródła.

Zrzut ekranu przedstawiający migrację instalatora.

  • Nazwa migracji jest unikatowym identyfikatorem każdej migracji do tego docelowego serwera elastycznego. To pole akceptuje tylko znaki alfanumeryczne i nie akceptuje żadnych znaków specjalnych z wyjątkiem łącznika (-). Nazwa nie może zaczynać się od łącznika i powinna być unikatowa dla serwera docelowego. Brak dwóch migracji do tego samego obiektu docelowego serwera elastycznego może mieć taką samą nazwę.

  • Typ serwera źródłowego — w zależności od źródła bazy danych PostgreSQL możesz wybrać maszynę wirtualną platformy Azure lub lokalnie.

  • Opcja migracji umożliwia przeprowadzenie walidacji przed wyzwoleniem migracji. Możesz wybrać dowolną z następujących opcji:

    • Weryfikacja — sprawdza gotowość serwera i bazy danych do migracji do miejsca docelowego.
    • Migrowanie — pomija walidacje i uruchamia migracje.
    • Weryfikowanie i migrowanie — przeprowadza walidację przed wyzwoleniem migracji. Migracja jest wyzwalana tylko wtedy, gdy nie ma żadnych błędów walidacji.

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

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

Wybierz przycisk Dalej: Połącz ze źródłem.

Serwer środowiska uruchomieniowego

Serwer środowiska uruchomieniowego migracji to wyspecjalizowana funkcja w ramach usługi migracji w usłudze Azure Database for PostgreSQL, która jest przeznaczona do działania jako serwer pośredniczący podczas migracji. Jest to oddzielne wystąpienie usługi Azure Database for PostgreSQL — serwer elastyczny, które nie jest serwerem docelowym, ale służy do ułatwiania migracji baz danych ze środowiska źródłowego, które jest dostępne tylko za pośrednictwem sieci prywatnej.

Zrzut ekranu przedstawiający stronę serwera środowiska uruchomieniowego migracji.

Aby uzyskać więcej informacji na temat serwera środowiska uruchomieniowego, odwiedź serwer środowiska uruchomieniowego migracji.

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

Na karcie Połącz ze źródłem zostanie wyświetlony monit o podanie szczegółów dotyczących źródła wybranego na karcie Konfiguracja będącego źródłem baz danych.

Zrzut ekranu przedstawiający pozycję Connectsourcemigration.

  • Nazwa serwera — podaj nazwę hosta lub adres IP źródłowego wystąpienia bazy danych PostgreSQL
  • Port — numer portu serwera źródłowego
  • Nazwa logowania administratora serwera — nazwa użytkownika źródłowego serwera PostgreSQL
  • Hasło — hasło źródłowego serwera PostgreSQL
  • Tryb SSL — obsługiwane wartości są preferowane i wymagane. Gdy źródłowy serwer PostgreSQL jest wyłączony, użyj parametru SSLMODE=prefer. Jeśli protokół SSL na serwerze źródłowym jest włączony, użyj parametru SSLMODE=require. Wartości SSL można określić w pliku postgresql.conf.
  • Testuj połączenie — wykonuje test łączności między miejscem docelowym i źródłem. Po pomyślnym nawiązaniu połączenia użytkownicy mogą przejść do następnego kroku. W przeciwnym razie należy zidentyfikować problemy z siecią między elementem docelowym a źródłem i zweryfikować nazwę użytkownika/hasło dla źródła. Połączenie testowe trwa kilka minut, aby nawiązać połączenie między obiektem docelowym a źródłem

Po pomyślnym połączeniu testowym wybierz pozycję Dalej: wybierz docelowy migracji

Wybieranie miejsca docelowego migracji

Na karcie Wybierz miejsce docelowe migracji są wyświetlane metadane obiektu docelowego serwera elastycznego, takie jak nazwa subskrypcji, grupa zasobów, nazwa serwera, lokalizacja i wersja bazy danych PostgreSQL.

Zrzut ekranu przedstawiający pozycję Connecttargetmigration.

  • Nazwa użytkownika administratora — nazwa użytkownika administratora docelowego serwera PostgreSQL
  • Hasło — hasło docelowego serwera PostgreSQL
  • Niestandardowa nazwa FQDN/adres IP (opcjonalnie): niestandardowe pole FQDN/IP jest opcjonalne i może być używane, gdy obiekt docelowy znajduje się za niestandardowym serwerem DNS lub ma niestandardowe przestrzenie nazw DNS, dzięki czemu jest dostępny tylko za pośrednictwem określonych nazw FQDN lub adresów IP. Na przykład może to obejmować wpisy, takie jak flexibleserver.example.com, 198.1.0.2lub nazwa FQDN postgreSQL, takie jak flexibleserver.postgres.database.azure.com, jeśli niestandardowy serwer DNS zawiera strefę postgres.database.azure.com DNS lub przekazuje zapytania dla tej strefy do 168.63.129.16, gdzie nazwa FQDN jest rozpoznawana w publicznej lub prywatnej strefie DNS platformy Azure.
  • Testuj połączenie — wykonuje test łączności między miejscem docelowym i źródłem. Po pomyślnym nawiązaniu połączenia użytkownicy mogą przejść do następnego kroku. W przeciwnym razie musimy zidentyfikować problemy z siecią między obiektem docelowym a źródłem i zweryfikować nazwę użytkownika/hasło dla elementu docelowego. Połączenie testowe trwa kilka minut, aby nawiązać połączenie między obiektem docelowym a źródłem.

Po pomyślnym połączeniu testowym wybierz pozycję Dalej: Wybierz bazy danych do migracji

Wybieranie baz danych na potrzeby migracji

Na tej karcie lista baz danych użytkowników znajduje się na serwerze źródłowym wybranym na karcie konfiguracji. Możesz wybrać i zmigrować maksymalnie osiem baz danych w ramach pojedynczej próby migracji. Jeśli istnieje więcej niż osiem baz danych użytkowników, proces migracji jest powtarzany między serwerami źródłowymi i docelowymi dla następnego zestawu baz danych.

Zrzut ekranu przedstawiający FetchDBmigration.

Po wybraniu baz danych wybierz pozycję Dalej: Podsumowanie

Podsumowanie

Karta Podsumowanie zawiera podsumowanie wszystkich szczegółów źródłowych i docelowych dotyczących tworzenia walidacji lub migracji. Przejrzyj szczegóły i wybierz przycisk Start.

Zrzut ekranu przedstawiający migrację podsumowania.

Monitorowanie migracji

Po wybraniu przycisku uruchamiania zostanie wyświetlone powiadomienie w ciągu kilku sekund z informacją o pomyślnym zakończeniu weryfikacji lub utworzenia migracji. Nastąpi automatyczne przekierowanie do bloku Migracja serwera elastycznego, który zawiera nowy wpis dotyczący niedawno utworzonej weryfikacji lub migracji.

Zrzut ekranu przedstawiający monitorowanie migracji w witrynie Azure Portal.

Siatka wyświetlającą migracje zawiera następujące kolumny: Nazwa, Stan, Tryb migracji, Typ migracji, Serwer źródłowy, Typ serwera źródłowego, Bazy danych, **Czas trwania i Godzina rozpoczęcia. Wpisy są wyświetlane w kolejności malejącej godziny rozpoczęcia z najnowszym wpisem u góry. Możesz użyć przycisku odświeżania, aby odświeżyć stan weryfikacji lub migracji. Wybierz nazwę migracji w siatce, aby wyświetlić skojarzone szczegóły.

Po utworzeniu walidacji lub migracji następuje przejście do stanu InProgress i podstanu PerformingPreRequisiteSteps . Skonfigurowanie infrastruktury migracji i połączeń sieciowych trwa od 2 do 3 minut.

Szczegóły migracji

Na karcie Konfiguracja wybraliśmy opcję migracji jako Migrowanie i Weryfikowanie. W tym scenariuszu walidacje są wykonywane najpierw przed rozpoczęciem migracji. Po zakończeniu podstanu PerformingPreRequisiteSteps przepływ pracy przechodzi do podstanu Walidacja w toku.

  • Jeśli walidacja zawiera błędy, migracja zostanie przeniesiona do stanu Niepowodzenie.
  • Jeśli walidacja zakończy się bez błędu, rozpoczyna się migracja, a przepływ pracy przechodzi do podstanu Migrowanie danych.

Wyniki weryfikacji są wyświetlane na karcie Walidacja , a migracja jest monitorowana na karcie Migracja .

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

Niektóre możliwe stany migracji:

Stany migracji

Stan opis
Ruch przychodzący Trwa konfigurowanie infrastruktury migracji lub trwa rzeczywista migracja danych.
Anulowane Migracja zostanie anulowana lub usunięta.
Nie działa Migracja nie powiodła się.
Walidacja nie powiodła się Walidacja nie powiodła się.
Powodzenie Migracja zakończyła się pomyślnie i została ukończona.
OczekiwanieForUserAction Dotyczy tylko migracji online. Oczekiwanie na wykonanie akcji jednorazowej przez użytkownika.

Podstany migracji

Podstan opis
PerformingPreRequisiteSteps Trwa konfigurowanie infrastruktury na potrzeby migracji danych.
Walidacja w toku Walidacja jest w toku.
Migrowanie danych Migracja danych jest w toku.
UkończenieMigration Migracja jest na ostatnim etapie ukończenia.
Zakończono Migracja została ukończona.
Nie działa Migracja nie powiodła się.

Podstany walidacji

Podstan opis
Nie działa Walidacja nie powiodła się.
Powodzenie Walidacja zakończyła się pomyślnie.
Ostrzeżenie Walidacja jest ostrzegawcza.

Migracja jednorazowa

W przypadku migracji i weryfikacji i migracji ukończenie migracji online wymaga innego kroku — użytkownik musi wykonać akcję migracji jednorazowej. Po zakończeniu kopiowania/klonowania danych podstawowych migracja zostanie przeniesiona do WaitingForUserAction stanu i 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 wartość to 0 lub blisko 0. Informacje Latency można uzyskać na ekranie szczegółów migracji, jak pokazano poniżej:
  • latency wartość zmniejsza się do 0 lub zbliżonej do 0
  • Wartość latency wskazuje, kiedy element docelowy został ostatnio zsynchronizowany ze źródłem. Zapisywanie w źródle można zatrzymać w tym momencie i można zainicjować migrację jednorazową. Jeśli w źródle występuje duży ruch, zaleca się najpierw zatrzymanie zapisów, aby Latency zbliżyć się do wartości 0, a następnie zainicjowano migrację jednorazową.

Operacja cutover stosuje wszystkie oczekujące zmiany ze źródła do elementu docelowego i kończy migrację. W przypadku wyzwolenia operacji "Cutover" nawet w przypadku braku zera Latency, replikacja zostanie zatrzymana do tego momentu w czasie. Wszystkie dane w źródle do momentu zastosowania punktu jednorazowego do obiektu docelowego. Jeśli wystąpi opóźnienie wynoszące 15 minut w punkcie migracji jednorazowej, wszystkie zmienione dane w ciągu ostatnich 15 minut zostaną zastosowane do celu. Czas zależy od listy prac zmian występujących w ciągu ostatnich 15 minut. W związku z tym zaleca się, aby opóźnienie przechodziło do zera lub zbliżonego do zera przed wyzwoleniem migracji jednorazowej.

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

Anulowanie migracji

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 . Nie usuwa ani nie przywraca żadnych zmian na serwerze docelowym. Pamiętaj, aby usunąć bazy danych na serwerze docelowym, który jest zaangażowany w anulowaną migrację.

Sprawdzanie migracji po zakończeniu

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ść