Share via

Upgrade databáze PostgreSQL pomocí výpisu a obnovení

  • Článek

PLATÍ PRO: Azure Database for PostgreSQL – Jednoúčelový server

Důležité

Jednoúčelový server Azure Database for PostgreSQL je na cestě vyřazení. Důrazně doporučujeme upgradovat na flexibilní server Azure Database for PostgreSQL. Další informace o migraci na flexibilní server Azure Database for PostgreSQL najdete v tématu Co se děje s jednoúčelovým serverem Azure Database for PostgreSQL?

Poznámka:

Koncepty popsané v této dokumentaci se vztahují jak na jednoúčelový server Azure Database for PostgreSQL, tak na flexibilní server Azure Database for PostgreSQL.

Server PostgreSQL nasazený ve službě Azure Database for PostgreSQL můžete upgradovat migrací databází na server s vyšší hlavní verzí pomocí následujících metod.

  • Offline metoda využívající pg_dump PostgreSQL a pg_restore, která způsobuje výpadek pro migraci dat. Tento dokument se zabývá touto metodou upgradu nebo migrace.
  • Online metoda pomocí služby Database Migration Service (DMS). Tato metoda poskytuje omezenou migraci výpadků a udržuje cílovou databázi synchronizovanou se zdrojem a můžete zvolit, kdy provést přímé přerušení. Při použití DMS je však třeba vzít v úvahu několik předpokladů a omezení. Podrobnosti najdete v dokumentaci k DMS.
  • Metoda místního upgradu hlavní verze s využitím flexibilního serveru Azure Database for PostgreSQL Funkce místního upgradu hlavní verze provádí upgrade hlavní verze serveru jediným kliknutím. To zjednodušuje proces upgradu, který minimalizuje přerušení přístupu uživatelů a aplikací k serveru. Místní upgrady představují jednodušší způsob upgradu hlavní verze instance, protože po upgradu zachovají název serveru a další nastavení aktuálního serveru a nevyžadují migraci dat ani změny v aplikacích připojovací řetězec. Místní upgrady jsou rychlejší a způsobují kratší výpadky než migrace dat.

Následující tabulka obsahuje několik doporučení založených na velikostech a scénářích databáze.

Databáze nebo scénář Výpis/obnovení (offline) DMS (Online)
Máte malou databázi a můžete si dovolit výpadek upgradu. X
Malé databáze (< 10 GB) X X
Malé střední databáze (10 GB – 100 GB) X X
Velké databáze (> 100 GB) X
Může si dovolit výpadek upgradu (bez ohledu na velikost databáze). X
Může vyřešit požadavky DMS, včetně restartování? X
Můžete se vyhnout seznamům DDLS a nepřilogovaným tabulkám během procesu upgradu? X

Tato příručka obsahuje několik metodik offline migrace a příklady, které ukazují, jak můžete migrovat ze zdrojového serveru na cílový server, na kterém běží vyšší verze PostgreSQL.

Poznámka:

Výpis a obnovení PostgreSQL je možné provádět mnoha způsoby. Můžete se rozhodnout migrovat pomocí některé z metod uvedených v této příručce nebo zvolit jiné způsoby, jak potřebujete. Podrobnou syntaxi výpisu a obnovení s dalšími parametry najdete v článcích pg_dump a pg_restore.

Požadavky pro použití výpisu a obnovení ve službě Azure Database for PostgreSQL

K procházení tohoto návodu potřebujete:

  • Zdrojový databázový server PostgreSQL s nižší verzí modulu, který chcete upgradovat.
  • Cílový databázový server PostgreSQL s požadovanou hlavní verzí serveru Azure Database for PostgreSQL – Jednoúčelový server nebo Flexibilní server Azure Database for PostgreSQL.
  • Klientský systém PostgreSQL pro spuštění příkazů výpisu a obnovení. Doporučujeme použít vyšší verzi databáze. Pokud například upgradujete z PostgreSQL verze 9.6 na verzi 11, použijte klienta PostgreSQL verze 11.
  • Váš klient PostgreSQL nejlépe běží ve stejné oblasti jako zdrojový a cílový server.

Další podrobnosti a důležité informace

  • Připojovací řetězec ke zdrojové a cílové databázi najdete tak, že na portálu vyberete "Připojení ion Strings".
  • Na serveru může běžet více než jedna databáze. Seznam databází najdete tak, že se připojíte ke zdrojovému serveru a spustíte \l.
  • Vytvořte odpovídající databáze na cílovém databázovém serveru nebo přidejte -C možnost do pg_dump příkazu, který vytvoří databáze.
  • Databáze šablon nesmí být upgradovány azure_maintenance ani šablony. Pokud jste provedli nějaké změny v databázích šablon, můžete se rozhodnout tyto změny migrovat nebo provést tyto změny v cílové databázi.
  • Projděte si výše uvedené tabulky a určete, jestli je databáze vhodná pro tento režim migrace.
  • Pokud chcete použít Azure Cloud Shell, mějte na paměti, že platnost relace vyprší po 20 minutách. Pokud je < velikost databáze 10 GB, můžete upgrade dokončit bez časového limitu relace. Jinak může být nutné zachovat relaci otevřenou jinými prostředky, například stisknout libovolnou klávesu jednou za 10 až 15 minut.

Ukázková databáze použitá v této příručce

V této příručce se k ilustraci s příklady používají následující zdrojové a cílové servery a názvy databází.

Popis Hodnota
Zdrojový server (v9.5) pg-95.postgres.database.azure.com
Zdrojová databáze bench5gb
Velikost zdrojové databáze 5 GB
Zdrojové uživatelské jméno pg@pg-95
Cílový server (v11) pg-11.postgres.database.azure.com
Cílová databáze bench5gb
Cílové uživatelské jméno pg@pg-11

Poznámka:

Flexibilní server podporuje PostgreSQL verze 11 a vyšší. Také uživatelské jméno flexibilního serveru nevyžaduje @dbservername.

Upgrade databází pomocí offline metod migrace

Pro upgrady můžete použít jednu z metod popsaných v této části. Při provádění úkolů můžete použít následující tipy.

  • Pokud používáte stejné heslo pro zdrojovou a cílovou databázi, můžete nastavit proměnnou PGPASSWORD=yourPassword prostředí. Pak nemusíte zadávat heslo pokaždé, když spustíte příkazy, jako je psql, pg_dump a pg_restore. Podobně můžete nastavit další proměnné jako PGUSERPGSSLMODE atd. viz proměnné prostředí PostgreSQL.

  • Pokud váš server PostgreSQL vyžaduje připojení TLS/SSL (ve výchozím nastavení na serverech Azure Database for PostgreSQL), nastavte proměnnou PGSSLMODE=require prostředí tak, aby se nástroj pg_restore připojovat k protokolu TLS. Bez protokolu TLS se chyba může číst. FATAL: SSL connection is required. Please specify SSL options and retry.

  • Na příkazovém řádku Windows spusťte příkaz SET PGSSLMODE=require před spuštěním příkazu pg_restore. V Linuxu nebo Bash spusťte příkaz export PGSSLMODE=require před spuštěním příkazu pg_restore.

Důležité

Kroky a metody uvedené v tomto dokumentu představují příklady příkazů pg_dump/pg_restore a nepředstavují všechny možné způsoby provádění upgradů. Doporučuje se otestovat a ověřit příkazy v testovacím prostředí, než je použijete v produkčním prostředí.

Migrace rolí

Role (Uživatelé) jsou globální objekty a před obnovením databází je potřeba do nového clusteru migrovat samostatně. Binární soubor s parametrem -r (--roles-only) můžete použít pg_dumpall k výpisu. Výpis všech rolí pomocí hesel ze zdrojového jednoúčelového serveru:

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

Pokud chcete vyčíst všechny názvy rolí bez hesel ze zdrojového flexibilního serveru: 

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

Důležité

Uživatelé flexibilního serveru Azure Database for PostgreSQL nemají povolený přístup k tabulce pg_authid, která obsahuje informace o identifikátorech autorizace databáze společně s hesly uživatelů. Načítání hesel pro uživatele proto není možné. Zvažte použití služby Azure Key Vault k bezpečnému ukládání tajných kódů.

roles.sql Upravte a odeberte odkazy na NOSUPERUSER obsah a NOBYPASSRLS před obnovením obsahu pomocí psql na cílovém serveru:

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

Skript výpisu paměti by neměl být zcela spuštěn bez chyb. Zejména proto, že skript vydá roli CREATE ROLE pro každou roli existující ve zdrojovém clusteru, je jisté, že u superuživatele bootstrap, jako je azure_pg_admin nebo azure_superuser, zobrazí chyba "role už existuje". Tato chyba je neškodná a lze ji ignorovat. --clean Použití této možnosti pravděpodobně způsobí další neškodné chybové zprávy o neexistujících objektech, i když je můžete minimalizovat přidáním --if-exists.

Metoda 1: Použití pg_dump a psql

Tato metoda zahrnuje dva kroky. Nejprve je výpis souboru SQL ze zdrojového serveru pomocí pg_dump. Druhým krokem je import souboru do cílového serveru pomocí psql. Podrobnosti najdete v dokumentaci k migraci s využitím exportu a importu .

Metoda 2: Použití pg_dump a pg_restore

V této metodě upgradu nejprve vytvoříte výpis ze zdrojového serveru pomocí pg_dump. Potom tento soubor s výpisem paměti obnovíte na cílový server pomocí pg_restore. Podrobnosti najdete v dokumentaci k migraci s využitím výpisu a obnovení .

Metoda 3: Použití streamování dat výpisu paměti do cílové databáze

Pokud nemáte klienta PostgreSQL nebo chcete použít Azure Cloud Shell, můžete použít tuto metodu. Výpis paměti databáze se streamuje přímo na cílový databázový server a neukládá výpis paměti v klientovi. To lze proto použít s klientem s omezeným úložištěm a dokonce je možné ho spustit z Azure Cloud Shellu.

  1. Pomocí příkazu se ujistěte, že databáze na cílovém serveru \l existuje. Pokud databáze neexistuje, vytvořte databázi.

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

    postgres> \l   
postgres> create database myTargetDB;

  2. Spusťte výpis a obnovení jako jeden příkazový řádek pomocí kanálu.

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

    Příklad:

    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 dokončení procesu upgradu (migrace) můžete otestovat aplikaci s cílovým serverem.

  4. Tento postup opakujte pro všechny databáze na serveru.

Následující tabulka například ukazuje dobu, jakou trvalo migraci pomocí metody výpisu stavu streamování. Ukázková data se naplní pomocí nástroje pgbench. Vzhledem k tomu, že vaše databáze může mít různý počet objektů s různými velikostmi než tabulky a indexy vygenerované pgbenchem, důrazně doporučujeme otestovat výpis paměti a obnovení databáze, abyste porozuměli skutečnému času, který trvá upgrade databáze.

Velikost databáze Asi doba trvání
1 GB 1–2 minuty
5 GB 8–10 minut
10 GB 15–20 minut
50 GB 1–1,5 hodiny
100 GB 2,5–3 hodiny

Metoda 4: Použití paralelního výpisu a obnovení

Tuto metodu můžete zvážit, pokud máte v databázi několik větších tabulek a chcete paralelizovat proces výpisu a obnovení pro tuto databázi. Potřebujete také dostatek úložiště v klientském systému, aby vyhovovalo výpisům stavu zálohování. Tento paralelní proces výpisu a obnovení zkracuje dobu, po které se dokončí celá migrace. Například 50GB databáze pgbench, která migrovala 1–1,5 hodin, byla dokončena pomocí metody 1 a 2 trvala méně než 30 minut pomocí této metody.

  1. Pro každou databázi na zdrojovém serveru vytvořte odpovídající databázi na cílovém serveru.

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

    postgres> create database myDB;

    Příklad:

    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. Spusťte příkaz pg_dump ve formátu adresáře s počtem úloh = 4 (počet tabulek v databázi). Pokud máte větší výpočetní úroveň a více tabulek, můžete ji zvýšit na vyšší číslo. Tato pg_dump vytvoří adresář pro ukládání komprimovaných souborů pro každou úlohu.

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

    Příklad:

    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. Pak obnovte zálohu na cílovém serveru.

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

    Příklad:

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

Tip

Proces uvedený v tomto dokumentu se dá použít také k upgradu flexibilního serveru Azure Database for PostgreSQL. Hlavním rozdílem je připojovací řetězec pro cíl flexibilního serveru je bez @dbName. Pokud je pgnapříklad uživatelské jméno , uživatelské jméno jednoho serveru v připojovacím řetězci bude pg@pg-95, zatímco u flexibilního serveru, můžete jednoduše použít pg.

Po upgradu nebo migraci

Po dokončení upgradu hlavní verze doporučujeme spustit ANALYZE příkaz v každé databázi a aktualizovat pg_statistic tabulku. V opačném případě může dojít k problémům s výkonem.

postgres=> analyze;
ANALYZE

Další kroky

  • Jakmile budete s funkcí cílové databáze spokojeni, můžete starý databázový server odstranit.
  • Pouze pro jednoúčelový server Azure Database for PostgreSQL. Pokud chcete použít stejný koncový bod databáze jako zdrojový server, můžete po odstranění starého zdrojového databázového serveru vytvořit repliku pro čtení se starým názvem databázového serveru. Po navázání stavu stabilní replikace můžete zastavit repliku, která zvýší úroveň serveru repliky na nezávislý server. Další podrobnosti najdete v tématu Replikace .

Důležité

Důrazně doporučujeme otestovat novou upgradovanou verzi PostgreSQL, než ji použijete přímo pro produkční prostředí. To zahrnuje porovnání parametrů serveru mezi starším zdrojem zdrojové verze a novějším cílem verze. Ujistěte se, že jsou stejné, a zkontrolujte všechny nové parametry přidané v nové verzi. Rozdíly mezi verzemi najdete tady.