Migrowanie bazy danych PostgreSQL przy użyciu zrzutu i przywracania

  • Artykuł

DOTYCZY: Azure Database for PostgreSQL — pojedynczy serwer usługi Azure Database for PostgreSQL — serwer elastyczny

Możesz użyć narzędzia pg_dump, aby wyodrębnić bazę danych PostgreSQL do pliku zrzutu. Metoda przywracania bazy danych zależy od formatu wybranego zrzutu. Jeśli zrzut jest pobierany ze zwykłym formatem (jest to domyślny -Fpformat , więc nie trzeba określać określonej opcji), jedyną opcją przywrócenia jest użycie narzędzia psql, ponieważ generuje plik w postaci zwykłego tekstu. W przypadku pozostałych trzech metod zrzutu: niestandardowe, katalogowe i tar należy użyć pg_restore .

Ważne

Instrukcje i polecenia podane w tym artykule są przeznaczone do wykonywania w terminalach powłoki bash. Obejmuje to środowiska, takie jak Podsystem Windows dla systemu Linux (WSL), Azure Cloud Shell i inne interfejsy zgodne z powłoką bash. Upewnij się, że używasz terminalu powłoki bash, aby wykonać kroki i wykonać polecenia opisane w tym przewodniku. Użycie innego typu środowiska terminalu lub powłoki może spowodować różnice w zachowaniu poleceń i nie mogą spowodować zamierzonych wyników.

W tym artykule skoncentrujemy się na zwykłych (domyślnych) formatach katalogów. Format katalogu jest przydatny, ponieważ umożliwia użycie wielu rdzeni do przetwarzania, co może znacznie zwiększyć wydajność, zwłaszcza w przypadku dużych baz danych.

Witryna Azure Portal usprawnia ten proces za pośrednictwem bloku Połączenie, oferując wstępnie skonfigurowane polecenia dostosowane do serwera z wartościami zastąpionymi danymi użytkownika. Należy pamiętać, że blok Połączenie jest dostępny tylko dla usługi Azure Database for PostgreSQL — serwer elastyczny, a nie dla pojedynczego serwera. Oto jak można użyć tej funkcji:

  1. Uzyskaj dostęp do witryny Azure Portal: najpierw przejdź do witryny Azure Portal i wybierz blok Połączenie.

    Screenshot showing the placement of Connect blade in Azure portal.

  2. Wybierz bazę danych: w bloku Połączenie znajduje się lista rozwijana baz danych. Wybierz bazę danych, z której chcesz wykonać zrzut.

    Screenshot showing the dropdown where specific database can be chosen.

  3. Wybierz odpowiednią metodę: w zależności od rozmiaru bazy danych można wybrać między dwiema metodami:

    • pg_dump & psql - przy użyciu pojedynczego pliku tekstowego: Idealne dla mniejszych baz danych, ta opcja korzysta z pojedynczego pliku tekstowego dla procesu zrzutu i przywracania.
    • pg_dump & pg_restore — przy użyciu wielu rdzeni: w przypadku większych baz danych ta metoda jest wydajniejsza, ponieważ używa wielu rdzeni do obsługi procesu zrzutu i przywracania.

    Screenshot showing two possible dump methods.

  4. Polecenia kopiowania i wklejania: portal udostępnia gotowe do użycia pg_dump polecenia i lub psqlpg_restore . Te polecenia są już zastępowane wartościami zgodnie z wybranym serwerem i bazą danych. Skopiuj i wklej te polecenia.

Wymagania wstępne

Jeśli używasz pojedynczego serwera lub nie masz dostępu do portalu serwera elastycznego, przeczytaj tę stronę dokumentacji. Zawiera on informacje podobne do przedstawionych w bloku Połączenie dla serwera elastycznego w portalu.

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

  • Serwer usługi Azure Database for PostgreSQL, w tym reguły zapory umożliwiające dostęp.
  • pg_dump, psql, pg_restore i pg_dumpall na wypadek, gdy chcesz przeprowadzić migrację z rolami i uprawnieniami, zainstalowane narzędzia wiersza polecenia.
  • Zdecyduj o lokalizacji zrzutu: wybierz miejsce, z którego chcesz wykonać zrzut. Można to zrobić z różnych lokalizacji, takich jak oddzielna maszyna wirtualna, cloud shell (gdzie narzędzia wiersza polecenia są już zainstalowane, ale może nie być w odpowiedniej wersji, więc zawsze sprawdzaj wersję przy użyciu, na przykład psql --version), lub własnego laptopa. Zawsze należy pamiętać o odległości i opóźnieniu między serwerem PostgreSQL a lokalizacją, z której uruchamiasz zrzut lub przywracanie.

Ważne

Niezbędne jest użycie pg_dumpnarzędzi , psqlpg_restore i pg_dumpall , które są albo w tej samej wersji głównej, czy nowszej wersji głównej niż serwer bazy danych, z którego eksportujesz dane lub do którego importujesz dane. Nie można tego zrobić, może spowodować niepowodzenie migracji danych. Jeśli serwer docelowy ma wyższą wersję główną niż serwer źródłowy, użyj narzędzi, które są tej samej wersji głównej lub nowszej niż serwer docelowy.

Uwaga

Należy pamiętać, że pg_dump można eksportować tylko jedną bazę danych naraz. To ograniczenie ma zastosowanie niezależnie od wybranej metody, niezależnie od tego, czy używa pojedynczego pliku, czy wielu rdzeni.

Dumping użytkowników i ról z pg_dumpall -r

pg_dump Służy do wyodrębniania bazy danych PostgreSQL do pliku zrzutu. Jednak ważne jest, aby zrozumieć, że pg_dump nie powoduje zrzutu ról ani definicji użytkowników, ponieważ są one uważane za obiekty globalne w środowisku PostgreSQL. Aby przeprowadzić kompleksową migrację, w tym użytkowników i ról, należy użyć polecenia pg_dumpall -r. To polecenie umożliwia przechwycenie wszystkich informacji o rolach i użytkownikach ze środowiska PostgreSQL. Jeśli przeprowadzasz migrację w bazach danych na tym samym serwerze, możesz pominąć ten krok i przejść do sekcji Tworzenie nowej bazy danych .

pg_dumpall -r -h <server name> -U <user name> > roles.sql

Jeśli na przykład masz serwer o nazwie i użytkownik o nazwie mydemoservermyuser uruchom następujące polecenie:

pg_dumpall -r -h mydemoserver.postgres.database.azure.com -U myuser > roles.sql

Jeśli używasz pojedynczego serwera, nazwa użytkownika zawiera składnik nazwy serwera. W związku z tym myuserzamiast polecenia należy użyć polecenia myuser@mydemoserver.

Dumping role z serwera elastycznego

W środowisku serwera elastycznego zwiększone środki zabezpieczeń oznaczają, że użytkownicy nie mają dostępu do tabeli pg_authid, gdzie są przechowywane hasła ról. To ograniczenie wpływa na sposób wykonywania zrzutu ról, ponieważ standardowe pg_dumpall -r polecenie próbuje uzyskać dostęp do tej tabeli dla haseł i kończy się niepowodzeniem z powodu braku uprawnień.

W przypadku dumpingu ról z serwera elastycznego kluczowe jest uwzględnienie --no-role-passwords opcji w poleceniu pg_dumpall . Ta opcja uniemożliwia pg_dumpall próbę uzyskania dostępu pg_authid do tabeli, której nie można odczytać z powodu ograniczeń zabezpieczeń.

Aby pomyślnie zrzucić role z serwera elastycznego, użyj następującego polecenia:

pg_dumpall -r --no-role-passwords -h <server name> -U <user name> > roles.sql

Jeśli na przykład masz serwer o nazwie , użytkownik o nazwie mydemoservermyuser, uruchom następujące polecenie:

pg_dumpall -r --no-role-passwords -h mydemoserver.postgres.database.azure.com -U myuser > roles.sql

Czyszczenie zrzutu ról

Podczas migracji pliku roles.sql wyjściowego mogą zawierać pewne role i atrybuty, które nie mają zastosowania lub są dopuszczalne w nowym środowisku. Oto, co należy wziąć pod uwagę:

  • Usuwanie atrybutów, które można ustawić tylko przez superużytkowników: w przypadku migracji do środowiska, w którym nie masz uprawnień administratora, usuń atrybuty, takie jak NOSUPERUSER i NOBYPASSRLS z zrzutu ról.

  • Wykluczanie użytkowników specyficznych dla usługi: wyklucz użytkowników usługi pojedynczego serwera, takich jak azure_superuser lub azure_pg_admin. Są one specyficzne dla usługi i zostaną utworzone automatycznie w nowym środowisku.

Użyj następującego sed polecenia, aby wyczyścić zrzut ról:

sed -i '/azure_superuser/d; /azure_pg_admin/d; /azuresu/d; /^CREATE ROLE replication/d; /^ALTER ROLE replication/d; /^ALTER ROLE/ {s/NOSUPERUSER//; s/NOBYPASSRLS//;}' roles.sql

To polecenie usuwa wiersze zawierające azure_superuser, , azure_pg_adminazuresu, wiersze rozpoczynające się od CREATE ROLE replication i ALTER ROLE replication, i usuwa NOSUPERUSER atrybuty i NOBYPASSRLS z ALTER ROLE instrukcji .

Tworzenie pliku zrzutu zawierającego dane do załadowania

Aby wyeksportować istniejącą bazę danych PostgreSQL lokalnie lub na maszynie wirtualnej do pliku skryptu sql, uruchom następujące polecenie w istniejącym środowisku:

pg_dump <database name> -h <server name> -U <user name> > <database name>_dump.sql

Jeśli na przykład masz serwer o nazwie , użytkownik o mydemoservernazwie i bazie danych o nazwie myusertestdb, uruchom następujące polecenie:

pg_dump testdb -h mydemoserver.postgres.database.azure.com -U myuser > testdb_dump.sql

Jeśli używasz pojedynczego serwera, nazwa użytkownika zawiera składnik nazwy serwera. W związku z tym myuserzamiast polecenia należy użyć polecenia myuser@mydemoserver.

Przywracanie danych do docelowej bazy danych

Przywracanie ról i użytkowników

Przed przywróceniem obiektów bazy danych upewnij się, że role zostały prawidłowo po cenach dumpingowych i oczyszczone. Jeśli migrujesz w bazach danych na tym samym serwerze, zarówno dumping role, jak i ich przywracanie może nie być konieczne. Jednak w przypadku migracji między różnymi serwerami lub środowiskami ten krok ma kluczowe znaczenie.

Aby przywrócić role i użytkowników do docelowej bazy danych, użyj następującego polecenia:

psql -f roles.sql -h <server_name> -U <user_name>

Zastąp <server_name> ciąg nazwą serwera docelowego i <user_name> nazwą użytkownika. To polecenie używa psql narzędzia do wykonywania poleceń SQL zawartych w roles.sql pliku, skutecznie przywracając role i użytkowników do docelowej bazy danych.

Jeśli na przykład masz serwer o nazwie , użytkownik o nazwie mydemoservermyuser, uruchom następujące polecenie:

psql -f roles.sql -h mydemoserver.postgres.database.azure.com -U myuser

Jeśli używasz pojedynczego serwera, nazwa użytkownika zawiera składnik nazwy serwera. W związku z tym myuserzamiast polecenia należy użyć polecenia myuser@mydemoserver.

Uwaga

Jeśli masz już użytkowników o tych samych nazwach na pojedynczym serwerze lub serwerze lokalnym, z którego przeprowadzasz migrację, oraz na serwerze docelowym, pamiętaj, że ten proces przywracania może zmienić hasła dla tych ról. W związku z tym wszelkie kolejne polecenia, które należy wykonać, mogą wymagać zaktualizowanych haseł. Nie ma to zastosowania, jeśli serwer źródłowy jest serwerem elastycznym, ponieważ serwer elastyczny nie zezwala na dumping haseł dla użytkowników z powodu zwiększonych środków bezpieczeństwa.

Tworzenie nowej bazy danych

Przed przywróceniem bazy danych może być konieczne utworzenie nowej, pustej bazy danych. Aby to zrobić, użytkownik, którego używasz, musi mieć CREATEDB uprawnienie. Poniżej przedstawiono dwie często używane metody:

  1. Za pomocą createdb narzędzia Program createdb umożliwia tworzenie bazy danych bezpośrednio z poziomu wiersza polecenia powłoki bash bez konieczności logowania się do bazy danych PostgreSQL lub opuszczania środowiska systemu operacyjnego. Przykład:

    createdb <new database name> -h <server name> -U <user name>

    Jeśli na przykład masz serwer o nazwie , użytkownik o nazwie mydemoservermyuser i nowa baza danych, którą chcesz utworzyć, to testdb_copy, uruchom następujące polecenie:

    createdb testdb_copy -h mydemoserver.postgres.database.azure.com -U myuser

    Jeśli używasz pojedynczego serwera, nazwa użytkownika zawiera składnik nazwy serwera. W związku z tym myuserzamiast polecenia należy użyć polecenia myuser@mydemoserver.

  2. Za pomocą polecenia SQL Aby utworzyć bazę danych przy użyciu polecenia SQL, musisz nawiązać połączenie z serwerem PostgreSQL za pośrednictwem interfejsu wiersza polecenia lub narzędzia do zarządzania bazami danych. Po nawiązaniu połączenia możesz użyć następującego polecenia SQL, aby utworzyć nową bazę danych:

CREATE DATABASE <new database name>;

Zastąp <new database name> ciąg nazwą, którą chcesz nadać nowej bazie danych. Aby na przykład utworzyć bazę danych o nazwie testdb_copy, polecenie to:

CREATE DATABASE testdb_copy;

Przywracanie zrzutu

Po utworzeniu docelowej bazy danych można przywrócić dane do tej bazy danych z pliku zrzutu. Podczas przywracania zarejestruj wszelkie błędy w errors.log pliku i sprawdź jego zawartość pod kątem błędów po zakończeniu przywracania.

psql -f <database name>_dump.sql <new database name> -h <server name> -U <user name> 2> errors.log

Jeśli na przykład masz serwer o nazwie , użytkownik o nazwie mydemoserveri nową bazę danych o nazwie myusertestdb_copy, uruchom następujące polecenie:

psql -f testdb_dump.sql testdb_copy -h mydemoserver.postgres.database.azure.com -U myuser 2> errors.log

Sprawdzanie po przywróceniu

Po zakończeniu procesu przywracania należy przejrzeć errors.log plik pod kątem błędów, które mogły wystąpić. Ten krok ma kluczowe znaczenie dla zapewnienia integralności i kompletności przywróconych danych. Rozwiąż wszelkie problemy znalezione w pliku dziennika, aby zachować niezawodność bazy danych.

Optymalizowanie procesu migracji

Podczas pracy z dużymi bazami danych proces zrzutu i przywracania może być długi i może wymagać optymalizacji w celu zapewnienia wydajności i niezawodności. Ważne jest, aby pamiętać o różnych czynnikach, które mogą mieć wpływ na wydajność tych operacji i podjąć kroki w celu ich optymalizacji.

Aby uzyskać szczegółowe wskazówki dotyczące optymalizowania procesu zrzutu i przywracania, zapoznaj się z artykułem Najlepsze rozwiązania dotyczące pg_dump i pg_restore . Ten zasób zawiera kompleksowe informacje i strategie, które mogą być korzystne dla obsługi dużych baz danych.

Następne kroki