Udostępnij za pośrednictwem

Uaktualnianie bazy danych PostgreSQL przy użyciu zrzutu i przywracania

  • Artykuł

DOTYCZY: Azure Database for PostgreSQL — pojedynczy serwer

Ważne

Usługa Azure Database for PostgreSQL — pojedynczy serwer znajduje się na ścieżce wycofania. Zdecydowanie zalecamy uaktualnienie do usługi Azure Database for PostgreSQL — serwer elastyczny. Aby uzyskać więcej informacji na temat migracji do usługi Azure Database for PostgreSQL — serwer elastyczny, zobacz Co się dzieje z usługą Azure Database for PostgreSQL — pojedynczy serwer?.

Uwaga

Pojęcia opisane w tej dokumentacji dotyczą zarówno usługi Azure Database for PostgreSQL — pojedynczy serwer, jak i azure Database for PostgreSQL — serwer elastyczny.

Serwer PostgreSQL wdrożony w usłudze Azure Database for PostgreSQL można uaktualnić, migrując bazy danych na serwer o wyższej wersji głównej przy użyciu następujących metod.

  • Metoda offline korzystająca z pg_dump PostgreSQL i pg_restore, która powoduje przestój podczas migracji danych. Ten dokument dotyczy tej metody uaktualniania/migracji.
  • Metoda online korzystająca z usługi Database Migration Service (DMS). Ta metoda zapewnia ograniczoną migrację przestojów i utrzymuje docelową bazę danych w synchronizacji ze źródłem i można wybrać, kiedy należy przeciąć. Jest jednak kilka wymagań wstępnych i ograniczeń, które należy spełnić w przypadku korzystania z usługi DMS. Aby uzyskać szczegóły, zobacz dokumentację usługi DMS.
  • Metoda uaktualniania wersji głównej w miejscu przy użyciu usługi Azure Database for PostgreSQL — serwer elastyczny. Funkcja uaktualniania wersji głównej w miejscu wykonuje uaktualnienie wersji głównej serwera za pomocą tylko kliknięcia. Upraszcza to proces uaktualniania, minimalizując zakłócenia dla użytkowników i aplikacji, które uzyskują dostęp do serwera. Uaktualnienia w miejscu to prostszy sposób uaktualniania wersji głównej wystąpienia, ponieważ zachowują nazwę serwera i inne ustawienia bieżącego serwera po uaktualnieniu i nie wymagają migracji danych ani zmian w parametry połączenia aplikacji. Uaktualnienia w miejscu są szybsze i wymagają krótszego przestoju niż migracja danych.

Poniższa tabela zawiera zalecenia dotyczące rozmiarów i scenariuszy bazy danych.

Baza danych/scenariusz Zrzut/przywracanie (offline) DMS (online)
Masz małą bazę danych i możesz sobie pozwolić na przestój w celu uaktualnienia X
Małe bazy danych (< 10 GB) X X
Małe średnie bazy danych (10 GB – 100 GB) X X
Duże bazy danych (> 100 GB) X
Może pozwolić sobie na przestój w celu uaktualnienia (niezależnie od rozmiaru bazy danych) X
Czy można spełnić wymagania wstępne usługi DMS, w tym ponowne uruchomienie? X
Czy można uniknąć list DDLs i nielogowanych tabel podczas procesu uaktualniania? X

Ten przewodnik zawiera kilka metodologii migracji offline i przykłady pokazujące, jak można przeprowadzić migrację z serwera źródłowego na serwer docelowy z uruchomioną wyższą wersją bazy danych PostgreSQL.

Uwaga

Zrzut i przywracanie bazy danych PostgreSQL można wykonać na wiele sposobów. Możesz zdecydować się na migrację przy użyciu jednej z metod podanych w tym przewodniku lub wybrać alternatywne sposoby dopasowania do Twoich potrzeb. Aby uzyskać szczegółową składnię zrzutu i przywracania z dodatkowymi parametrami, zobacz artykuły pg_dump i pg_restore.

Wymagania wstępne dotyczące używania zrzutu i przywracania w usłudze Azure Database for PostgreSQL

Aby przejść przez ten przewodnik z instrukcjami, potrzebne są następujące elementy:

  • Źródłowy serwer bazy danych PostgreSQL z niższą wersją aparatu, który chcesz uaktualnić.
  • Docelowy serwer bazy danych PostgreSQL z żądaną główną wersją serwera usługi Azure Database for PostgreSQL — pojedynczy serwer lub usługa Azure Database for PostgreSQL — serwer elastyczny.
  • System klienta PostgreSQL do uruchamiania poleceń zrzutu i przywracania. Zaleca się używanie wyższej wersji bazy danych. Jeśli na przykład uaktualniasz program PostgreSQL w wersji 9.6 do 11, użyj klienta PostgreSQL w wersji 11.
    • Może to być klient systemu Linux lub Windows, który ma zainstalowany program PostgreSQL i ma zainstalowane narzędzia pg_dump i pg_restore wiersza polecenia.
    • Alternatywnie możesz użyć usługi Azure Cloud Shell lub wybierając usługę Azure Cloud Shell na pasku menu w prawym górnym rogu witryny Azure Portal. Przed uruchomieniem polecenia zrzutu i przywracania musisz zalogować się do swojego konta az login .
  • Klient PostgreSQL najlepiej działa w tym samym regionie co serwery źródłowe i docelowe.

Dodatkowe szczegóły i zagadnienia

  • Parametry połączenia można znaleźć w źródłowych i docelowych bazach danych, wybierając pozycję "Parametry połączenia" w portalu.
  • Na serwerze może być uruchomiona więcej niż jedna baza danych. Listę baz danych można znaleźć, łącząc się z serwerem źródłowym i uruchamiając polecenie \l.
  • Utwórz odpowiednie bazy danych na docelowym serwerze bazy danych lub dodaj -C opcję do pg_dump polecenia, które tworzy bazy danych.
  • Nie można uaktualnić azure_maintenance ani baz danych szablonów. Jeśli wprowadzono jakiekolwiek zmiany w bazach danych szablonów, możesz wybrać migrację zmian lub wprowadzić te zmiany w docelowej bazie danych.
  • Zapoznaj się z powyższymi tabelami, aby określić, czy baza danych jest odpowiednia dla tego trybu migracji.
  • Jeśli chcesz użyć usługi Azure Cloud Shell, pamiętaj, że limit czasu sesji po upływie 20 minut. Jeśli rozmiar bazy danych wynosi < 10 GB, może być możliwe ukończenie uaktualniania bez limitu czasu sesji. W przeciwnym razie może być konieczne pozostawienie sesji otwarte za pomocą innych środków, takich jak naciśnięcie dowolnego raz w ciągu 10–15 minut.

Przykładowa baza danych używana w tym przewodniku

W tym przewodniku do zilustrowania przykładów służą następujące serwery źródłowe i docelowe oraz nazwy baz danych.

Opis Wartość
Serwer źródłowy (wersja 9.5) pg-95.postgres.database.azure.com
Źródłowa baza danych ławka5 gb
Rozmiar źródłowej bazy danych 5 GB
Nazwa użytkownika źródłowego pg@pg-95
Serwer docelowy (wersja 11) pg-11.postgres.database.azure.com
Docelowa baza danych ławka5 gb
Nazwa użytkownika docelowego pg@pg-11

Uwaga

Serwer elastyczny obsługuje program PostgreSQL w wersji 11. Ponadto nazwa użytkownika serwera elastycznego nie wymaga @dbservername.

Uaktualnianie baz danych przy użyciu metod migracji w trybie offline

Możesz użyć jednej z metod opisanych w tej sekcji na potrzeby uaktualnień. Podczas wykonywania zadań możesz użyć poniższych wskazówek.

  • Jeśli używasz tego samego hasła dla źródłowej i docelowej bazy danych, możesz ustawić zmienną PGPASSWORD=yourPassword środowiskową. Następnie nie musisz podawać hasła za każdym razem, gdy uruchamiasz polecenia, takie jak psql, pg_dump i pg_restore. Podobnie możesz skonfigurować dodatkowe zmienne, takie jak PGUSER, PGSSLMODE itp., aby wyświetlić zmienne środowiskowe PostgreSQL.

  • Jeśli serwer PostgreSQL wymaga połączeń TLS/SSL (domyślnie na serwerach usługi Azure Database for PostgreSQL), ustaw zmienną środowiskową PGSSLMODE=require , aby narzędzie pg_restore łączyło się z protokołem TLS. Bez protokołu TLS błąd może zostać odczytany FATAL: SSL connection is required. Please specify SSL options and retry.

  • W wierszu polecenia systemu Windows uruchom polecenie SET PGSSLMODE=require przed uruchomieniem pg_restore polecenia. W systemie Linux lub Bash uruchom polecenie export PGSSLMODE=require przed uruchomieniem polecenia pg_restore.

Ważne

Kroki i metody przedstawione w tym dokumencie umożliwiają przedstawienie przykładów poleceń pg_dump/pg_restore i nie reprezentują wszystkich możliwych sposobów przeprowadzania uaktualnień. Zaleca się przetestowanie i zweryfikowanie poleceń w środowisku testowym przed użyciem ich w środowisku produkcyjnym.

Migrowanie ról

Role (użytkownicy) są obiektami globalnymi i muszą zostać zmigrowane oddzielnie do nowego klastra przed przywróceniem baz danych. Aby je zrzucić, możesz użyć pg_dumpall pliku binarnego z opcją -r (--roles-only). Aby zrzucić wszystkie role z hasłami ze źródłowego pojedynczego serwera:

pg_dumpall -r --host=mySourceServer --port=5432 --username=myUser@mySourceServer --database=mySourceDB > roles.sql

Aby zrzucić wszystkie nazwy ról, bez haseł ze źródłowego serwera elastycznego:

pg_dumpall -r --no-role-passwords --host=mySourceServer --port=5432 --username=myUser --database=mySourceDB > roles.sql

Ważne

W usłudze Azure Database for PostgreSQL — użytkownicy serwera elastycznego nie mogą uzyskiwać dostępu do tabeli pg_authid zawierającej informacje o identyfikatorach autoryzacji bazy danych wraz z hasłami użytkownika. W związku z tym pobieranie haseł dla użytkowników nie jest możliwe. Rozważ użycie usługi Azure Key Vault do bezpiecznego przechowywania wpisów tajnych.

Przed przywróceniem zawartości przy użyciu narzędzia psql na serwerze docelowym zmodyfikuj roles.sql NOSUPERUSER odwołania i NOBYPASSRLS usuń je:

psql -f roles.sql --host=myTargetServer --port=5432 --username=myUser --dbname=postgres

Skrypt zrzutu nie powinien być uruchamiany całkowicie bez błędów. W szczególności, ponieważ skrypt wystawi rolę CREATE ROLE dla każdej roli istniejącej w klastrze źródłowym, na pewno zostanie wyświetlony błąd "rola już istnieje" dla superużytkownika bootstrap, takiego jak azure_pg_admin lub azure_superuser. Ten błąd jest nieszkodliwy i można go zignorować. --clean Użycie opcji może spowodować wygenerowanie dodatkowych nieszkodliwych komunikatów o błędach dotyczących nieistniejących obiektów, chociaż można je zminimalizować, dodając element --if-exists.

Metoda 1. Używanie pg_dump i psql

Ta metoda obejmuje dwa kroki. Najpierw należy zrzucić plik SQL z serwera źródłowego przy użyciu polecenia pg_dump. Drugim krokiem jest zaimportowanie pliku na serwer docelowy przy użyciu polecenia psql. Aby uzyskać szczegółowe informacje, zobacz dokumentację Migrowanie przy użyciu eksportu i importowania .

Metoda 2. Używanie pg_dump i pg_restore

W tej metodzie uaktualniania najpierw utworzysz zrzut z serwera źródłowego przy użyciu polecenia pg_dump. Następnie przywrócisz ten plik zrzutu na serwer docelowy przy użyciu polecenia pg_restore. Aby uzyskać szczegółowe informacje, zobacz dokumentację Migrowanie przy użyciu zrzutu i przywracania .

Metoda 3. Używanie przesyłania strumieniowego danych zrzutu do docelowej bazy danych

Jeśli nie masz klienta PostgreSQL lub chcesz użyć usługi Azure Cloud Shell, możesz użyć tej metody. Zrzut bazy danych jest przesyłany strumieniowo bezpośrednio do docelowego serwera bazy danych i nie przechowuje zrzutu w kliencie. W związku z tym można go użyć z klientem z ograniczonym magazynem, a nawet można uruchomić z poziomu usługi Azure Cloud Shell.

  1. Upewnij się, że baza danych istnieje na serwerze docelowym przy użyciu \l polecenia . Jeśli baza danych nie istnieje, utwórz bazę danych.

     psql "host=myTargetServer port=5432 dbname=postgres user=myUser password=###### sslmode=mySSLmode"

    postgres> \l   
postgres> create database myTargetDB;

  2. Uruchom zrzut i przywróć jako pojedynczy wiersz polecenia przy użyciu potoku.

    pg_dump -Fc --host=mySourceServer --port=5432 --username=myUser --dbname=mySourceDB | pg_restore  --no-owner --host=myTargetServer --port=5432 --username=myUser --dbname=myTargetDB

    Przykład:

    pg_dump -Fc --host=pg-95.postgres.database.azure.com --port=5432 --username=pg@pg-95 --dbname=bench5gb | pg_restore --no-owner --host=pg-11.postgres.database.azure.com --port=5432 --username=pg@pg-11 --dbname=bench5gb

  3. Po zakończeniu procesu uaktualniania (migracji) możesz przetestować aplikację na serwerze docelowym.

  4. Powtórz ten proces dla wszystkich baz danych na serwerze.

Na przykład w poniższej tabeli przedstawiono czas migracji przy użyciu metody zrzutu przesyłania strumieniowego. Przykładowe dane są wypełniane przy użyciu narzędzia pgbench. Ponieważ baza danych może mieć różną liczbę obiektów o różnych rozmiarach niż tabele i indeksy wygenerowane przez aplikację pgbench, zdecydowanie zaleca się przetestowanie zrzutu i przywrócenia bazy danych w celu zrozumienia rzeczywistego czasu potrzebnych na uaktualnienie bazy danych.

Rozmiar bazy danych Około czasu
1 GB 1–2 minuty
5 GB 8–10 minut
10 GB 15–20 minut
50 GB 1–1,5 godziny
100 GB 2,5–3 godziny

Metoda 4. Używanie równoległego zrzutu i przywracania

Możesz rozważyć tę metodę, jeśli masz kilka większych tabel w bazie danych i chcesz zrównać proces zrzutu i przywracania dla tej bazy danych. Potrzebujesz również wystarczającej ilości miejsca w systemie klienckim, aby pomieścić zrzuty kopii zapasowych. Ten równoległy proces zrzutu i przywracania skraca czas potrzebny do ukończenia całej migracji. Na przykład baza danych pgbench o pojemności 50 GB, która trwała od 1 do 1,5 godz. migracji, została ukończona przy użyciu metody 1, a 2 zajęło mniej niż 30 minut przy użyciu tej metody.

  1. Dla każdej bazy danych na serwerze źródłowym utwórz odpowiednią bazę danych na serwerze docelowym.

    psql "host=myTargetServer port=5432 dbname=postgres user=myuser password=###### sslmode=mySSLmode"

    postgres> create database myDB;

    Przykład:

    psql "host=pg-11.postgres.database.azure.com port=5432 dbname=postgres user=pg@pg-11 password=###### sslmode=require"
psql (12.3 (Ubuntu 12.3-1.pgdg18.04+1), server 13.3)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

postgres> create database bench5gb;
postgres> \q

  2. Uruchom polecenie pg_dump w formacie katalogu z liczbą zadań = 4 (liczba tabel w bazie danych). W przypadku większej warstwy obliczeniowej i większej liczby tabel można zwiększyć ją do większej liczby. To pg_dump utworzy katalog do przechowywania skompresowanych plików dla każdego zadania.

    pg_dump -Fd -v --host=sourceServer --port=5432 --username=myUser --dbname=mySourceDB -j 4 -f myDumpDirectory

    Przykład:

    pg_dump -Fd -v --host=pg-95.postgres.database.azure.com --port=5432 --username=pg@pg-95 --dbname=bench5gb -j 4 -f dump.dir

  3. Następnie przywróć kopię zapasową na serwerze docelowym.

    $ pg_restore -v --no-owner --host=myTargetServer --port=5432 --username=myUser --dbname=myTargetDB -j 4 myDumpDir

    Przykład:

    $ pg_restore -v --no-owner --host=pg-11.postgres.database.azure.com --port=5432 --username=pg@pg-11 --dbname=bench5gb -j 4 dump.dir

Napiwek

Proces wymieniony w tym dokumencie może służyć również do uaktualniania serwera elastycznego usługi Azure Database for PostgreSQL. Główną różnicą jest parametry połączenia dla obiektu docelowego serwera elastycznego jest bez .@dbName Jeśli na przykład nazwa użytkownika to pg, nazwa użytkownika pojedynczego serwera w ciągu połączenia będzie mieć pg@pg-95wartość , natomiast w przypadku serwera elastycznego można po prostu użyć polecenia pg.

Po uaktualnieniu/migracji

Po zakończeniu uaktualniania wersji głównej zalecamy uruchomienie ANALYZE polecenia w każdej bazie danych w celu odświeżenia pg_statistic tabeli. W przeciwnym razie mogą wystąpić problemy z wydajnością.

postgres=> analyze;
ANALYZE

Następne kroki

  • Gdy funkcja docelowej bazy danych jest zadowolona, możesz usunąć stary serwer bazy danych.
  • W przypadku usługi Azure Database for PostgreSQL — tylko pojedynczy serwer. Jeśli chcesz użyć tego samego punktu końcowego bazy danych co serwer źródłowy, po usunięciu starego źródłowego serwera bazy danych możesz utworzyć replikę do odczytu ze starą nazwą serwera bazy danych. Po ustanowieniu stanu stałej replikacji można zatrzymać replikę, która będzie promować serwer repliki jako niezależny serwer. Aby uzyskać więcej informacji, zobacz Replikacja .

Ważne

Zdecydowanie zaleca się przetestowanie nowej wersji uaktualnionej bazy danych PostgreSQL przed użyciem jej bezpośrednio do środowiska produkcyjnego. Obejmuje to porównanie parametrów serwera między starszym źródłem wersji źródłowej a nowszym elementem docelowym wersji. Upewnij się, że są one takie same i sprawdź wszystkie nowe parametry, które zostały dodane w nowej wersji. Różnice między wersjami można znaleźć tutaj.