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. Pokud chcete získat další informace, vyberte předběžné ověření .

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í waly (zapisují hlavičkové protokoly). 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čuje se 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á na výstup výše uvedené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í ve velikosti, takže odhad požadovaného úložiště předem je obezřetný.

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

Č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 a dokončení všech kontrol můžete migraci a aplikaci provést přímou migraci, abyste se vyhnuli časovému 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 udržujte provoz v průběhu migrace nízký.

Většina neprodních serverů (vývoj, UAT, testování, příprava) se migruje pomocí offline migrací. Vzhledem k tomu, že tyto servery mají méně dat než produkční servery, migrace se dokončí rychle. 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. Vzhledem k mnoha faktorům, 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ší způsob, jak získat dobrý odhad na dobu nutnou k migraci produkčního databázového serveru, je provést obnovení produkčního serveru k určitému bodu v čase a spustit offline migraci na tomto nově obnoveném serveru.

• Migrace vyrovnávací paměti – Po dokončení výše uvedené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é, můžete zvážit další testování pomocí serveru PITR. U většinyserverůch

• 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. Zákazníci můžou používat opensourcové nástroje nebo nástroje třetích stran nebo můžou 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, indexy)

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

  Poznámka:

  Velikost databází musí být správná metrika pro ověření. Zdrojová instance může mít bloudné nebo mrtvé řazené kolekce členů, což může navýšit velikost zdrojové instance. Je zcela normální mít rozdíly mezi zdrojovými instancemi a cílovými servery. Pokud v prvních třech krocích ověření dojde k problému, znamená to problém s migrací.

• Migrace nastavení serveru – Všechny vlastní parametry serveru, pravidla brány firewall (pokud je k dispozici), značky a výstrahy se musí ručně zkopírovat 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 zásahu, 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 uvádí dobu potřebnou k provedení migrací pro databáze různých velikostí pomocí služby migration Service. Migrace se provedla pomocí flexibilního serveru se skladovou jednotkou – Standard_D4ds_v4 (4 jádra, 16 GB paměti, 128 GB disku a 500 iOps)

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

Poznámka:

Výše uvedená čí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é

Pokud chcete provádět rychlejší migrace, vyberte pro flexibilní server vyšší skladovou položku. Flexibilní server Azure Database for PostgreSQL podporuje škálování výpočetních prostředků a IOPS téměř bez výpadků, aby bylo možné skladovou položku 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

Pro cíl se doporučuje výkonná skladová položka, 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ý a vytvoří kritické body. Proto rozdělíme velké tabulky na menší bloky dat, které se pak migrují paralelně. Tato funkce platí pro tabulky s více než 1 000000 řazenými kolekcemi členů (10 m). Rozdělení tabulky na menší bloky dat je možné, pokud je splněna jedna z následujících podmínek.

1. Tabulka musí mít sloupec s jednoduchým (ne složeným) primárním klíčem nebo jedinečným indexem typu int nebo významného int.

   Poznámka:

   V případě přístupů č. 2 nebo #3 musí uživatel 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, pokud uživatel bude pokračovat změnami.

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

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

3. Pokud tabulka neobsahuje jednoduchý primární klíč nebo velký int nebo 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. Spuštění příkazu ALTER vyžaduje zámek v tabulce.

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

Pokud jsou splněny některé z výše uvedených podmínek, tabulka se migruje paralelně v několika oddílech, což by mělo poskytovat výrazný nárůst rychlosti migrace.

Jak to funguje

• Služba migrace vyhledá maximální a minimální celočíselnou hodnotu primárního nebo jedinečného indexu tabulky, která se musí rozdělit a migrovat paralelně.
• Pokud je rozdíl mezi minimální a maximální hodnotou větší než 1 0000000 (10 m), rozdělí se tabulka 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 int nebo významného int.
• Tabulka obsahuje nejméně 1 00000000 řádků (10 m), aby rozdíl mezi minimální a maximální hodnotou primárního klíče byl větší než 1 00000000 (10 m).
• 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 mrtvé řádky a haldy tabulky, což zajišťuje efektivní využití úložiště. Důležitější je, že pomáhá zajistit rychlejší migraci, protože doba potřebná k migraci je funkce velikosti databáze.

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

• Standardní vakuum

VACUUM your_table;

• Vakuum s funkcí Analyzovat

VACUUM ANALYZE your_table;

• Agresivní vakuum pro těžké zápisy tabulek

VACUUM FULL your_table;

V tomto příkladu nahraďte your_table skutečným názvem tabulky. Příkaz VACUUM bez funkce FULL efektivně uvolní místo a 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 předpoklady, o kterých musí studenti vědět, než budou pokračovat v kurzu nebo modulu. Tyto podmínky můžou zahrnovat konkrétní verze softwaru, hardwarové požadavky nebo další nástroje, které jsou nezbytné pro úspěšné 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í. Kromě toho se doporučuje mít primární klíč ve všech tabulkách databáze, u kterých probíhá online migrace. Pokud chybí primární klíč, může nedostatek způsobit, že se během migrace projeví pouze operace vložení, 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íč.

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 postgres_fdw obálky cizích 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 neaktivních uložených dat pomocí služby Migration Service.
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 má 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 nebude 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 takovém případě můžete udělit migration user oprávnění k zavření všech aktivních připojení k databázi nebo ručnímu zavření připojení před opakováním migrace.

Související obsah

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