Osvědčené postupy pro bezproblémovou migraci do služby Azure Database for PostgreSQL

PLATÍ PRO: Flexibilní server Azure Database for PostgreSQL

Tento článek vysvětluje běžné nástrahy, ke kterým došlo, a osvědčené postupy pro zajištění bezproblémové a úspěšné migrace do služby Azure Database for PostgreSQL.

Ověření předběžné migrace

Jako první krok migrace spusťte ověření předběžné migrace před provedením migrace. Na stránce Nastavení migrace můžete použít možnosti Ověřit a ověřit a migrovat. Ověření předběžné migrace provádí důkladné kontroly předdefinované sady pravidel. Cílem je identifikovat potenciální problémy a poskytnout užitečné přehledy pro nápravné akce. Pokračujte v provozu ověření předběžné migrace, dokud nebude výsledkem úspěšného stavu. Další informace najdete v tématu Ověření předběžné migrace.

Konfigurace cílového flexibilního serveru

Během počáteční základní kopie dat se v cíli spustí více příkazů insert, které vygenerují protokoly s předstihem pro zápis (WALs). Dokud nebudou tyto waly archivovány, protokoly spotřebovávají úložiště v cíli a v úložišti požadovaném databází.

Pokud chcete vypočítat číslo, přihlaste se ke zdrojové instanci a spusťte tento příkaz pro migraci všech databází:

SELECT pg_size_pretty( pg_database_size('dbname') );

Doporučujeme přidělit dostatek úložiště na flexibilním serveru, což odpovídá 1,25krát nebo 25 % více úložiště, než jaké se používá pro výstup předchozího příkazu. Můžete také použít Automatické zvětšování úložiště.

Důležité

Velikost úložiště nejde zmenšit v ruční konfiguraci ani automatickém zvětšování úložiště. Každý krok ve spektru konfigurace úložiště se zdvojnásobí, takže odhad požadovaného úložiště předem je obezřetný.

Rychlý start k vytvoření instance flexibilního serveru Azure Database for PostgreSQL je skvělým místem, kde začít. Další informace o konfiguraci jednotlivých serverů najdete v tématu Možnosti výpočetních prostředků a úložiště na flexibilním serveru Azure Database for PostgreSQL.

Důležité

Po vytvoření flexibilního serveru nezapomeňte před inicializaci migrace změnit parametr serveru password_encryption na flexibilním serveru z SCRAM-SHA-256 na MD5. To je nezbytné pro stávající přihlašovací údaje na jednoúčelovém serveru, aby fungovaly na flexibilním serveru.

Časová osa migrace

Každá migrace má po spuštění maximálně sedm dnů (168 hodin) a vyprší časový limit po sedmi dnech. Po ověření dat můžete dokončit přímou migraci a aplikaci a dokončit všechny kontroly, abyste se vyhnuli vypršení časového limitu migrace. Po dokončení počáteční základní kopie v online migracích trvá přímé okno tři dny (72 hodin) před vypršením časového limitu. V offline migracích by aplikace měly přestat zapisovat do databáze, aby se zabránilo ztrátě dat. Podobně u online migrace mějte v průběhu migrace nízký provoz.

Většina neprodukčních serverů (vývoj, UAT, testování a příprava) se migruje pomocí offline migrací. Vzhledem k tomu, že tyto servery mají méně dat než produkční servery, je migrace rychlá. V případě migrace produkčního serveru potřebujete vědět, jak dlouho by trvalo dokončení migrace, než bude migrace naplánována předem.

Doba potřebná k dokončení migrace závisí na několika faktorech. Zahrnuje počet databází, velikost, počet tabulek v každé databázi, počet indexů a distribuci dat napříč tabulkami. Závisí také na skladové posílce cílového serveru a na IOPS dostupném na zdrojové instanci a cílovém serveru. S tolika faktory, které můžou ovlivnit dobu migrace, je obtížné odhadnout celkovou dobu dokončení migrace. Nejlepším přístupem je provést testovací migraci s vaší úlohou.

Při výpočtu celkového výpadku při migraci produkčního serveru se považují následující fáze:

• Migrace obnovení k určitému bodu v čase: Nejlepším způsobem, jak získat dobrý odhad času potřebných k migraci produkčního databázového serveru, je provést obnovení k určitému bodu v čase (PITR) produkčního serveru a spustit offline migraci na tomto nově obnoveného serveru.

• Migrace vyrovnávací paměti: Po dokončení předchozího kroku můžete naplánovat skutečnou migraci do produkčního prostředí během časového období, kdy je provoz aplikace nízký. Tuto migraci je možné naplánovat na stejný den nebo pravděpodobně týden. V tuto chvíli se může zvětšit velikost zdrojového serveru. Na základě tohoto zvýšení aktualizujte odhadovanou dobu migrace pro produkční server. Pokud je zvýšení významné, zvažte další testování pomocí serveru PITR. U většiny serverů by ale zvětšení velikosti nemělo být dostatečně významné.

• Ověření dat: Po dokončení migrace pro produkční server je potřeba ověřit, jestli jsou data na flexibilním serveru přesnou kopií zdrojové instance. Můžete použít opensourcové nástroje nebo nástroje třetích stran nebo provést ověření ručně. Připravte kroky ověření, které chcete provést před samotnou migrací. Ověření může zahrnovat:

  • Shoda počtu řádků pro všechny tabulky zahrnuté v migraci.

  • Odpovídající počty pro všechny databázové objekty (tabulky, sekvence, rozšíření, procedury a indexy).

  • Porovnání maximálních nebo minimálních ID klíčových sloupců souvisejících s aplikací

    Poznámka:

    Srovnávací velikost databází není správnou metrikou pro ověření. Zdrojová instance může mít bloudy nebo mrtvé řazené kolekce členů, což může navýšit velikost zdrojové instance. Je normální mít rozdíly mezi zdrojovými instancemi a cílovými servery. Problém v předchozích třech krocích ověření značí problém s migrací.

• Migrace nastavení serveru: Všechny vlastní parametry serveru, pravidla brány firewall (pokud jsou k dispozici), značky a výstrahy musí být ručně zkopírovány ze zdrojové instance do cíle.

• Změna připojovací řetězec: Aplikace by po úspěšném ověření měla změnit své připojovací řetězec na flexibilní server. Tato aktivita je koordinovaná s aplikačním týmem, aby změnila všechny odkazy připojovací řetězec odkazující na zdrojovou instanci. Na flexibilním serveru lze parametr uživatele použít ve formátu user=username v připojovací řetězec.

Příklad: psql -h myflexserver.postgres.database.azure.com -u user1 -d db1

I když migrace často běží bez jakýchkoli problémů, je vhodné naplánovat, jestli je pro ladění potřeba více času nebo jestli je potřeba migraci restartovat.

Srovnávací testy rychlosti migrace

Následující tabulka ukazuje dobu potřebnou k provedení migrací pro databáze různých velikostí pomocí služby migration Service. Migrace byla provedena pomocí flexibilního serveru se skladovou jednotkou Standard_D4ds_v4 (4 jádra, 16 GB paměti).

Velikost databáze	Přibližná doba trvání (HH:MM)
1 GB	00:01
5 GB	00:03
10 GB	00:08
50 GB	00:35
100 GB	01:00
500 GB	04:00
1 000 GB	07:00

Předchozí čísla poskytují aproximaci doby potřebné k dokončení migrace. Důrazně doporučujeme spustit testovací migraci s vaší úlohou, abyste získali přesnou hodnotu pro migraci serveru.

Důležité

I když skladová položka burstable není omezení, doporučuje se zvolit vyšší skladovou položku pro flexibilní server, aby bylo možné provádět rychlejší migrace. Flexibilní server Azure Database for PostgreSQL podporuje téměř nulové výpadky výpočetních prostředků a škálování IOPS, takže skladovou položku je možné aktualizovat s minimálními výpadky. Skladovou položku můžete kdykoli změnit tak, aby odpovídala potřebám aplikace po migraci.

Zvýšení rychlosti migrace: Paralelní migrace tabulek

Doporučujeme pro cíl výkonnou skladovou položku, protože služba migrace PostgreSQL na flexibilním serveru vyčerpá kontejner. Výkonná skladová položka umožňuje paralelní migraci více tabulek. Skladovou položku můžete po migraci škálovat zpět na upřednostňovanou konfiguraci. Tato část obsahuje kroky ke zlepšení rychlosti migrace v případě, že distribuce dat mezi tabulkami musí být vyváženější nebo výkonnější skladová položka výrazně neovlivní rychlost migrace.

Pokud je distribuce dat ve zdroji vysoce nerovnoměrná, přičemž většina dat, která jsou v jedné tabulce, musí být přidělený výpočetní výkon pro migraci plně využit, což vytvoří kritický bod. Proto rozdělte velké tabulky na menší bloky dat, které se pak migrují paralelně. Tato funkce platí pro tabulky větší než 20 GB. Rozdělení tabulky na menší bloky dat je možné, pokud je splněna jedna z následujících podmínek:

• Tabulka musí mít sloupec s jednoduchým (ne složeným) primárním klíčem nebo jedinečným indexem typu smallint, integer nebo big int.

  Poznámka:

  V případě prvního nebo druhého přístupu musíte pečlivě vyhodnotit důsledky přidání jedinečného indexového sloupce do zdrojového schématu. Až po potvrzení, že přidání jedinečného indexového sloupce nebude mít vliv na aplikaci, měli byste pokračovat se změnami.

• Pokud tabulka nemá jednoduchý primární klíč nebo jedinečný index typu smallintnebo integer big int má sloupec, který splňuje kritéria datového typu, můžete sloupec převést na jedinečný index pomocí následujícího příkazu. Tento příkaz nevyžaduje zámek tabulky.

      create unique index concurrently partkey_idx on <table name> (column name);
  

• Pokud tabulka neobsahuje smallintprimární integer klíč nebo big int jedinečný index nebo jakýkoli sloupec splňující kritéria datového typu, můžete takový sloupec přidat pomocí funkce ALTER a po migraci ho odstranit. ALTER Spuštění příkazu vyžaduje uzamčení tabulky.

      alter table <table name> add column <column name> big serial unique;
  

Pokud jsou splněny některé z předchozích podmínek, tabulka se migruje paralelně v několika oddílech, což by mělo zvýšit rychlost migrace.

Jak to funguje

• Služba migrace vyhledá velikost tabulky a zkontroluje, jestli je větší než 20 GB.
• Pokud je velikost větší než 20 GB a existuje smallintinteger primární klíč nebo big int jedinečný index, tabulka se rozdělí na několik částí a každá část se migruje paralelně.

Stručně řečeno, služba migrace PostgreSQL migruje tabulku v paralelních vláknech a zkracuje dobu migrace, pokud:

• Tabulka obsahuje sloupec s jednoduchým primárním klíčem nebo jedinečným indexem typu smallint, integer nebo big int.
• Velikost tabulky je větší než 20 GB.
• Použitá skladová položka obsahuje nečinná jádra, která lze použít k paralelní migraci tabulky.

Vakuová blouska v databázi PostgreSQL

V průběhu času se při přidání, aktualizaci a odstranění dat může PostgreSQL hromadit neaktivní řádky a plýtvání úložným prostorem. To může vést ke zvýšení požadavků na úložiště a snížení výkonu dotazů. Úklid je zásadní úlohou údržby, která pomáhá uvolnit tento nevyužitý prostor a zajistit efektivní fungování databáze. Vakuové řešení řeší problémy, jako jsou prázdné řádky a haldy tabulky, aby se zajistilo efektivní využití úložiště. Pomáhá také zajistit rychlejší migraci, protože doba migrace je funkcí velikosti databáze.

PostgreSQL poskytuje VACUUM příkaz k uvolnění úložiště obsazeného mrtvými řádky. Tato ANALYZE možnost také shromažďuje statistiky pro další optimalizaci plánování dotazů. U tabulek s velkou aktivitou zápisu VACUUM může být proces agresivnější pomocí VACUUM FULL, ale vyžaduje více času ke spuštění.

• Standardní vakuum

  VACUUM your_table;
  

• Vakuum s analýzou

  VACUUM ANALYZE your_table;
  

• Agresivní vakuum pro těžké zápisové tabulky

  VACUUM FULL your_table;
  

V tomto příkladu nahraďte your_table skutečným názvem tabulky. Příkaz VACUUM bez FULL efektivního uvolnění místa, zatímco VACUUM ANALYZE optimalizuje plánování dotazů. Možnost VACUUM FULL by se měla používat uvážlivě kvůli většímu dopadu na výkon.

Některé databáze ukládají velké objekty, jako jsou obrázky nebo dokumenty, které můžou v průběhu času přispívat k bloudné databázi. Příkaz VACUUMLO je určený pro velké objekty v PostgreSQL.

• Vakuové velké objekty

  VACUUMLO;
  

Pravidelné začlenění těchto strategií úklidu zajišťuje dobře udržovanou databázi PostgreSQL.

Zvláštní pozornost

Existují zvláštní podmínky, které obvykle odkazují na jedinečné okolnosti, konfigurace nebo požadavky, o kterých potřebujete vědět, než budete pokračovat v kurzu nebo modulu. Tyto podmínky můžou zahrnovat konkrétní verze softwaru, hardwarové požadavky nebo jiné nástroje, které jsou nezbytné k úspěšnému dokončení výukového obsahu.

Online migrace

Online migrace využívá nástroj pgcopydb a platí některá z logických omezení dekódování. Doporučujeme také mít primární klíč ve všech tabulkách databáze, u které probíhá online migrace. Pokud chybí primární klíč, výsledkem nedostatku jsou pouze insert operace během migrace, s výjimkou aktualizací nebo odstranění. Než budete pokračovat v online migraci, přidejte do příslušných tabulek dočasný primární klíč.

Poznámka:

V případě online migrace tabulek bez primárního klíče se v cíli přehrají jenom insert operace. To může v databázi potenciálně zavádět nekonzistence, pokud se záznamy, které se aktualizují nebo odstraní ve zdroji, neodráží na cíl.

Alternativou je použít ALTER TABLE příkaz, ve kterém je akce REPLIKA IDENTIY s FULL možností. Tato FULL možnost zaznamenává staré hodnoty všech sloupců v řádku tak, aby i v případě absence primárního klíče se všechny operace CRUD projevily v cíli během online migrace. Pokud žádná z těchto možností nefunguje, proveďte offline migraci jako alternativu.

Databáze s rozšířením postgres_fdw

Modul postgres_fdw poskytuje cizí postgres_fdw obálky dat, které lze použít pro přístup k datům uloženým na externích serverech PostgreSQL. Pokud vaše databáze používá toto rozšíření, je potřeba provést následující kroky, aby se zajistila úspěšná migrace.

1. Dočasně odeberte (zrušit propojení) obálky cizích dat ve zdrojové instanci.
2. Proveďte migraci dat zbytku pomocí služby migrace.
3. Po migraci obnovte role obálky cizích dat, uživatele a odkazy na cíl.

Databáze s rozšířením postGIS

Rozšíření postGIS obsahuje zásadní změny nebo kompaktní problémy mezi různými verzemi. Pokud migrujete na flexibilní server, měla by být aplikace zkontrolována na novější verzi postGIS, aby se zajistilo, že aplikace není ovlivněná nebo že je nutné provést potřebné změny. Příspěvky a poznámky k verzi jsou dobrým výchozím bodem pro pochopení zásadních změn v různých verzích.

Vyčištění připojení k databázi

Někdy se může při spuštění migrace zobrazit tato chyba:

CL003:Target database cleanup failed in the pre-migration step. Reason: Unable to kill active connections on the target database created by other users. Please add the pg_signal_backend role to the migration user using the command 'GRANT pg_signal_backend to <migrationuser>' and try a new migration.

V tomto scénáři můžete udělit migration user oprávnění zavřít všechna aktivní připojení k databázi nebo připojení zavřít ručně před opakováním migrace.

Související obsah

• Služba migrace
• Známé problémy a omezení